Robert Watson wrote: > > On Sun, 2 Oct 2005, Koen Martens wrote: > >> kernel trap 12 with interrupts disabled >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 06 >> fault virtual address = 0x24 >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc051c253 >> stack pointer = 0x10:0xe93efb3c >> frame pointer = 0x10:0xe93efb50 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 6092 (postgres) >> >> And that, that is all.. No ddb> no 'dumping xxxxMB', just that. So >> basically, i fear this is a non-debugable problem, since putting in >> witness and such slows the kernel to a point where the panic does not >> occur anymore (at least, not in the 4 weeks i've been running the box >> with witness & invariants). Clueless :) > > > This looks like a NULL pointer dereference in kernel code. Probably, > this is not a locking problem, so running without WITNESS to debug > this should be OK. Are you using a serial console? If not, you might > find that it increases the reliability of entering DDB. If this box > is an SMP box, you may also want to add options KDB_STOP_NMI to your > kernel config. > > Using gdb, could you work out what function 0xc051c253 is, and where > in the function. You should be able to run gdb on your kernel.debug > (or kernel on 7.x), and use "l *0xc051c253" to generate a pointer to > the line and snippet, which will give us a substantial hint about what > is happening.
Sorry for not getting back on this timely, have had rather a busy period (lousy excuse, i know). Anyway, I have currently downgraded the machine to a 5.3-RELEASE-p22 kernel, which seems to have solved the problem. There are no panics anymore (it has been two weeks since the downgrade). Makes me a bit warry about upgrading anything to 6.x :) Anyway, i did get into the ddb prompt on one of the last panics, and put some of the resources online: http://www.sonologic.nl/fbsd/ As you can see, i was pretty clueless about what to do, and just traced about everything that was not swapped out.. Did not put the core dump online, as i don't feel like sharing that with the world. Available upon request though for those who want to get a crack at this. I don't have a copy of the kernel.debug lying around, for which I apologise. I cannot however upgrade to 5.4 again, we've had enought trouble with this machine and the user load on that machine has increased to a point where i cannot afford these random panics anymore. I don't have the spare identical hardware lying around at this point to copy the entire setup for testing purposes.. What i will try when i find some time is doing incremental upgrades from 5.3-RELEASE-p22 to 5.4-RELEASE-p6, step by step, to see what patchlevel introduces the problem. Best, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
