Bug #1391

aac(4) can't produce/save crashdumps

Added by archimedes.gaviola almost 4 years ago. Updated over 2 years ago.

Status:Closed Start date:
Priority:Normal Due date:
Assignee:swildner % Done:

0%
Category:-
Target version:-

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

Related todos

History

#1
Updated by alexh over 3 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

#2
Updated by swildner over 2 years ago

grab

#3
Updated by swildner over 2 years ago

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

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

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