Project

General

Profile

Bug #3553

savecore panicked my system.

Added by Rich Ercolani over 7 years ago. Updated over 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
zfs - Zettabyte File System
Start date:
2013-02-12
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

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

Related to illumos gate - Bug #3554: resizing dump device while dumping panics systemNew2013-02-12

Actions
Related to illumos gate - Bug #3557: dumpvp_size is not updated correctly when a dump zvol's size is changedClosed2013-02-13

Actions

History

#1

Updated by Rich Ercolani over 7 years ago

Neat, on reboot, I got bad magic number 0.

Guess I won't be posting the panic.

#2

Updated by Rich Lowe over 7 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

#3

Updated by Rich Ercolani over 7 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.

#4

Updated by Rich Lowe over 7 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.

#5

Updated by Christopher Siden over 7 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.

#6

Updated by Christopher Siden over 7 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'?

#7

Updated by Yuri Pankov over 3 years ago

  • Status changed from New to Feedback
  • Assignee set to Rich Ercolani

Also available in: Atom PDF