>>>>> "maj" == Maidak Alexander J <maidakalexand...@johndeere.com> writes:
maj> If you're having issues with a disk contoller or disk IO maj> driver its highly likely that a savecore to disk after the maj> panic will fail. I'm not sure how to work around this not in Solaris, but as a concept for solving the problem: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kdump/kdump.txt;h=3f4bc840da8b7c068076dd057216e846e098db9f;hb=4a6908a3a050aacc9c3a2f36b276b46c0629ad91 They load a second kernel into a reserved spot of RAM, like 64MB or so, and forget about it. After a crash, they boot the second kernel. The second kernel runs using the reserved area of RAM as its working space, not touching any other memory, as if you were running on a very old machine with tiny RAM. It reprobes all the hardware, and then performs the dump. I don't know if it actually works, but the approach is appropriate if you are trying to debug the storage stack. You could even have a main kernel which crashes while taking an ordinary coredump, and then use the backup dumping-kernel to coredump the main kernel in mid-coredump---a dump of a dumping kernel. I think some Solaris developers were discussing putting coredump features into Xen, so the host could take the dump (or, maybe even something better than a dump---for example, if you built host/target debugging features into Xen for debugging running kernels, then you could just force a breakpoint in the guest instead of panic. Since Xen can hibernate domU's onto disk (it can, right?), you can treat the hibernated Xen-specific representation of the domU as the-dump, groveling through the ``dump'' with the same host/target tools you could use on a running kernel without any special dump support in the debugger itself). IIRC NetBSD developers discussed the same idea years ago but neither implementation exists.
pgpsmSOamFWH7.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
