On Wednesday, 8. December 2004 12:54, Robert Watson wrote: > On Wed, 8 Dec 2004, Michael Nottebrock wrote: > > On Wednesday, 8. December 2004 12:20, Robert Watson wrote: > > > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog > > > > triggers a panic, no crashdump is taken although dumps are enabled. > > > > What could be causing this? > > > > > > If you drop to the debugger by using the debug.kdb.enter sysctl, and do > > > "call doadump", followed by a reset, does a dump get generated > > > successfully? > > > > I don't have kdb enabled in my kernel configuration at all... > > I'm guessing it might be useful at this point, if possible :-).
Useful for what exactly? I'm mainly interested in getting this machine to auto-reboot after a (watchdog-triggered) panic, crashdumps are a bonus. At the moment, it will just hang on a panic (even if I do not enable crashdumps in rc.conf, it won't reset), and since it's usually running X, it will just stand there while the CRTs burn in. If you think you can get a clue as to why it wouldn't crashdump or reset by something I can do in kdb, I will enable it ... > Do you > have a serial console on the box, or could you set one up? Nope, this is the only machine with a keyboard and a monitor attached. > > > > I.e., are they completely broken on your system, or is this > > > somehow a property of the particular hang you're seeing. > > > > See my other mail, a different (non-watchdog) panic didn't trigger a dump > > either. I even had the panic message in dmesg: > > > > kernel trap 12 with interrupts disabled > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x14c > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xc0521397 > > stack pointer = 0x10:0xe9794b84 > > frame pointer = 0x10:0xe9794b90 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = resume, IOPL = 0 > > current process = 1281 (beep-media-player) > > trap number = 12 > > panic: page fault > > This is a NULL pointer dereference; you can use addr2line or gdb on your > kernel.debug to turn it into a line number even without a core. That > might well be worth doing, as we might be able to debug that even without > getting dumping working on the box. It's a SCHED_ULE + PREEMPTION triggered panic, probably there's no point in investigating it at this point, as _ULE has been demoted to abandonware :-(. > Syncing on panic is, in general, probably not going to make it work better > than not. I guess there's no chance the box has an NMI button? Right. I just enabled it for the SW_WATCHDOG experiments (which made me discover that this machine would just get stuck on panics in the first place), I already turned it off again. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
pgpk0pV9DnNCX.pgp
Description: PGP signature
