Project

General

Profile

Bug #1391

aac(4) can't produce/save crashdumps

Added by archimedes.gaviola over 7 years ago. Updated almost 6 years ago.

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

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

History

#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.

Cheers,
Alex Hornung

#2 Updated by swildner about 6 years ago

grab

#3 Updated by swildner almost 6 years ago

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

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

#4 Updated by swildner almost 6 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