Bug #1391

aac(4) can't produce/save crashdumps

Added by archimedes.gaviola over 7 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:swildner% Done:


Target version:-



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

# /etc/sysctl.conf

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

db> call dumpsys

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



#1 Updated by alexh almost 7 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.

Alex Hornung

#2 Updated by swildner almost 6 years ago


#3 Updated by swildner over 5 years ago

I've synched the driver with FreeBSD

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

#4 Updated by swildner over 5 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.

Also available in: Atom PDF