Project

General

Profile

Actions

Bug #1391

closed

aac(4) can't produce/save crashdumps

Added by archimedes.gaviola over 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hi,

This issue is related to
http://leaf.dragonflybsd.org/mailarchive/bugs/2005-12/msg00047.html on
problem no. 2 but this is using an aac(4) RAID controller. This issue
is tested on an IBM x3650 machine with manually-generated panic
through ctrl-alt-escape method and an actual fatal trap error
(debugging an ixgb device driver).

  1. /etc/rc.conf
    ...
    dumpdev=/dev/aacd0s1b # swap device
    dumpdir=/home/crash
    ...
  1. /etc/sysctl.conf
    kern.sync_on_panic=0

With ctrl-alt-escape, calling a dumpsys will just hang my system.

db> call dumpsys

dumping to dev #aacd/0x20001, blockno 10486216
dump 3071

Thanks,
Archimedes

Actions #1

Updated by alexh almost 12 years ago

While introducing the whole new dumping infrastructure, I also disabled
dumping on aac(4). This at least avoids unexpected results by giving a
warning/error message, but the aac_dump stuff still needs to be ported from a
current FreeBSD.
If anyone wants to do this, I can provide some help and/or guidance if needed;
although it should be rather straightforward.

Cheers,
Alex Hornung

Actions #2

Updated by swildner almost 11 years ago

grab

Actions #3

Updated by swildner over 10 years ago

I've synched the driver with FreeBSD
(e9ae7f4fcc6d7bd3cead63918d847460a06582d5).

Archimedes, if you still have the machine, please test.

Actions #4

Updated by swildner over 10 years ago

I'm closing this one. Dumping works here with aac(4) after the upgrade.

If there's still problems, feel free to reopen.

Actions

Also available in: Atom PDF