:> On Sun, Aug 29, 1999 at 12:43:13PM -0700, Parag Patel wrote:
:> >
:> > -----ddb crash output-----
:> >
:> > Fatal trap 12: page fault while in kernel mode
:> > mp_lock = 03000003; cpuid = 3; lapic.id = 02000000
:> > fault virtual address = 0x0
:> > fault code = supervisor read, page not present
:> > instruction pointer = 0x8:0x0
:> > stack pointer = 0x10:0xd5730b08
:> > frame pointer = 0x10:0xd5730b4c
:> > code segment = base 0x0, limit 0xfffff, type 0x1b
:> > = DPL 0, pres 1, def32 1, gran 1
:> > processor eflags = interrupt enabled, resume, IOPL = 0
:> > current process = 376 (cpio)
:> > interrupt mask = bio <- SMP: XXX
:> > kernel: type 12 trap, code=0
:> > Stopped at 0:
:> [...]
:>
:> This looks similar to the panics I got since some days.
:
:How similar? The trap above is extremely bad; it looks like a return
:on a corrupted stack or a jump through a null function vector.
:
:Make very sure that your vinum kld is in sync with your kernel.
This looks like an indirect call through a NULL function pointer.
The stack looks intact ... look at the sp verses the frame pointer.
If the 'trace' command is resulting in a panic, perhaps it is because
there is no new stack frame. Giving the trace command an argument
will help. I forget how the arguments to 'trace' work under DDB
though.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
