Solved Problems with getting a crash dump

Hello, I am currently using FreeBSD 14.0-CURRENT and I found a bug that triggers a kernel panic. I wanted to make a kernel crash dump to further investigate the issue, but after a few tries I still did not manage to do it.
I started by following the instructions in the FreeBSD Handbook. I check that /dev/nvd0p2.eli is an active swap device and I configured it to be used as a dump device like this:
Bash:
# dumpon -v /dev/nvd0p2.eli
# sysctl debug.kdb.panic=1
Then I booted into single user mode to extract the core dumb:
Bash:
# savecore -vC /dev/nvd0p2
checking for kernel dump on device /dev/nvd0p2
mediasize = 2147483648 bytes
sectorsize = 512 bytes
magic mismatch on last dump header on /dev/nvd0p2
No dump exists
A you can see the core dump was not written to the device.
/dev/nvd0p2.eli is only 2gb in size and is an encrypted swap device, so I thought that:
1) Maybe the size of the device is to small even for a minidump.
2) /dev/nvd0p2.eli is only available after I enable it using swapon, but the handbook states the I should first extract the dump, before I use the device as swap again.

Because of those complications I decided to make use of an external 8gb USB drive as my dump device.
Bash:
# gpart create -s gpt /dev/da0
# gpart add -t freebsd-swap /dev/da0
# swapoff -a
# swapon /dev/da0p1
# dumpon -v /dev/da0p1
kernel dumps on priority: device
0: da0p1
I have 8gb of RAM so an 8gb dump device should be big enough for a minidump (I guess?). I used sysctl debug.kdb.panic=1 to crash the kernel and rebooted the system. I also waited for 10 minutes to ensure the the kernel finishes writing the core dump to the device.

Bash:
# savecore -vC /dev/da0p1
checking for kernel dump on device /dev/da0p1
mediasize = 7744741376 bytes
sectorsize = 512 bytes
magic mismatch on last dump header on /dev/da0p1
No dump exists
As you can see I still did not manage to get a kernel crash dump. Any ideas?
PS yes kern.coredump is set to 1.
 
This works for me:

Code:
% sysrc dumpdev
dumpdev: /dev/ada0p2
% lsblk ada0
DEVICE         MAJ:MIN SIZE TYPE                                          LABEL MOUNT
ada0             0:124 932G GPT                                               - -
  ada0p1         0:126 260M efi                                    gpt/efiboot0 -
  <FREE>         -:-   1.0M -                                                 - -
  ada0p2         0:128  16G freebsd-swap                              gpt/swap0 SWAP
  ada0p2.eli     1:40   16G freebsd-swap                                      - SWAP
  ada0p3         0:130 915G freebsd-zfs                                gpt/zfs0 <ZFS>
  ada0p3.eli     0:136 915G -                                                 - -
  <FREE>         -:-   708K -                                                 - -
%

NB late:

Code:
% grep /dev/ada0p2.eli /etc/fstab
/dev/ada0p2.eli none                    swap       sw,late                    0     0
%
 
AFAIK, setting dumpdev in /etc/rc.conf is the same as running dumpon. /etc/rc.d/dumpon confirms this.

My USB drive is not in fstab so it does not activate as a swap device at all without running swapon on it manually. I don't think adding it to /etc/fstab with the late will help in this case.
 
So, did you see anything interesting on console after sysctl debug.kdb.panic=1 ?
Any error messages perhaps?
 
So, did you see anything interesting on console after sysctl debug.kdb.panic=1 ?
Any error messages perhaps?
I did't notice anything abnormal. This is a picture of the output.

IMG_20211108_163313.jpeg


Sorry about that, I though that the development section was an exception to that rule.
 
Normally you should see "Dumping XXX out of ZZZ MB: ..."
Thanks for the reply. I figured out that drm-kmod (i915kms.ko) was making KDB fail for some reason. When I tried crashing the kernel without the driver loaded the crash dump was written correctly to the dump device.
IMG_20211109_215830.jpg

Now I just need to work out why does KDB have problems with drm-kmod on my machine.
 
OK, I finally managed to solve the issue. For some reason when I get a panic while i915kms is active I am unable to write continue in KDB. After I added debug.debugger_on_panic=0 to /etc/sysctl.conf the kernel automaticaly starts writing the crash dump and I do not have to write anything manually.

IMG_20211109_230340.jpg
 
drm-kmod on my machine.

pkg query '%o %v %R' drm-kmod drm-current-kmod drm-devel-kmod gpu-firmware-kmod ; date ; uptime ; uname -aKU

… like this:

Bash:
# dumpon -v /dev/nvd0p2.eli
# sysctl debug.kdb.panic=1

Then I booted …

Did you also continue before the boot?



drm-kmod (i915kms.ko) was making KDB fail for some reason. …

FWIW: here, without loading i915kms, no such problem with radeonkms.

Code:
graphics/drm-kmod g20190710_1 FreeBSD
graphics/drm-current-kmod 5.4.144.g20211012 FreeBSD
graphics/gpu-firmware-kmod g20210330 unknown-repository
Wed 10 Nov 2021 06:47:15 GMT
 6:47a.m.  up 19 mins, 5 users, load averages: 0.48, 1.59, 1.46
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #114 main-n250511-5f73b3338ee: Sat Nov  6 21:15:23 GMT 2021     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64 1400040 1400040
%

Note to self: this, now, is truly graphics/drm-current-kmod at 5.4.144.g20211012 (I very recently ceased my test of the non-ported fix relating to 5.5⋯.).
 
Maybe not enough, depending on use of swap.

From gpart list ada0:

Code:
…
2. Name: ada0p2
   Mediasize: 17179869184 (16G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
…

<https://convertlive.com/u/convert/bytes/to/megabytes#17179869184>

17179869184 Bytes = 16384 Megabytes

Is it coincidence that this dump is only very slightly (119 MB) smaller?

Code:
root@mowa219-gjp4-8570p-freebsd:~ # grep Dumping /var/crash/core.txt.7
Dumping 3352 out of 16265 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Dumping 3352 out of 16265 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
root@mowa219-gjp4-8570p-freebsd:~ #

Or, does the size of a dump never exceed the size of the given device?

Code:
% sysctl hw.physmem hw.usermem
hw.physmem: 17055141888
hw.usermem: 13856260096
%

13856260096 Bytes = 13214.36 Megabytes
13856260096 Bytes = 12.9046 Gigabytes
 
Back
Top