Bug #1391
closed
aac(4) can't produce/save crashdumps
0%
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).
- /etc/rc.conf
...
dumpdev=/dev/aacd0s1b # swap device
dumpdir=/home/crash
...
- /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
Updated by alexh over 14 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
Updated by swildner over 13 years ago
I've synched the driver with FreeBSD
(e9ae7f4fcc6d7bd3cead63918d847460a06582d5).
Archimedes, if you still have the machine, please test.
Updated by swildner about 13 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.