Bug #3553
open
savecore panicked my system.
0%
Description
Hi all,
On a system running oi151_a7, after I panicked it with saving core dumps to rpool/dump enabled, I rebooted to find, to my surprise, that savecore reported "bad magic number: 0".
I ran zfs set volsize=128G rpool/dump and ran savecore again [mostly out of absentmindedness].
I was then greeted by a lovely backtrace and, yes, a panic.
At least it should be easy to trigger, I suppose - write a panic to your dump device, grow the dump device, run savecore, BOOM.
Assuming that on reboot it gives me back the dump in /var/crash [and not an infinite panic loop], I'll post a link or the dump itself here.
Related issues
Updated by Rich Ercolani over 10 years ago
Neat, on reboot, I got bad magic number 0.
Guess I won't be posting the panic.
Updated by Rich Lowe over 10 years ago
- Category set to zfs - Zettabyte File System
setting dump_plat_mincpu=0 in /etc/system may help get you a dump.
Even if it doesn't, adding '-k' to the kernel command line will stop in the debugger, rather than rebooting, so you can get an idea of where and why we crashed.
I would presume that we were crashing in a purely zvol-related manner, rather than anything specifically savecore-y
Updated by Rich Ercolani over 10 years ago
I have dump_plat_mincpu=0 set; it didn't help.
The system didn't hang - it thought it had dumped successfully, and rebooted on its own.
I'll boot with -k when I have a second and try to replicate it.
Updated by Rich Lowe over 10 years ago
if I increase the size of the dump device, and then 'reboot -d', we sometimes panic while dumping, and/or fail to dump (with a message I didn't manage to read all of).
I can't seem to reproduce problems just running savecore.
Of course, resizing the dump device between the dump occurring and savecore being run will make the dump unreadable -- we rely on a terminal header at the end of the dump device, which resizing the volume will make it no longer at the end.
Updated by Christopher Siden over 10 years ago
George Wilson fixed a problem we saw at Delphix a while back were the dump device code does not properly handle resizing the dump zvol. I opened a separate bug (#3557) for that problem since I can't confirm it will fix the issue seen here, but George thinks they may be the same issue. I'll work to get George's changes out for review soon.
Updated by Christopher Siden over 10 years ago
Can you see if you can still reproduce the problem after the integration of '3557 dumpvp_size is not updated correctly when a dump zvol's size is changed'?
Updated by Yuri Pankov over 6 years ago
- Status changed from New to Feedback
- Assignee set to Rich Ercolani