Boris Popov wrote:
> On Sun, 10 Sep 2000, John Baldwin wrote:
>
> > > I think the random dev kicks in at this point
> > >
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 1; lapic.id = 0c000000
> > > fault virtual address = 0x2c
> > > fault code = supervisor read, page not present
> > > instruction pointer = 0x8:0xc014f280
> > > stack pointer = 0x10:0xc9a74f84
> > > frame pointer = 0x10:0xc9a74f9c
> > > code segment = base 0x0, limit 0xfffff, type 0x1b
> > > = DPL 0, pres 1,def 32 1,gran 1
> > > processor flags = interrupt enabled, resume, IOPL = 0
> > > current process = 2 (random)
> > > trap number = 12
> > > panic: page fault
> > > cpuid = 1; lapic.id = 0x000000
> > > boot() called on cpu#1
> > >
> > > syncing disks.......
> > >
> > > The machine then is frozen and needs a reset to work again
> > > the debugger is unavailable
> >
> > ddb works fine here with this new trap, but I can't get remote gdb to work
> > to save my life. I think that remote gdb must not like me or something.
>
> Yes, after trap is occured ddb works. But it is impossible to
> continue from ddb because after typing 'c<enter>' machine becomes frozen.
> The same thing occur after any other panic (this is with SMP kernel).
It only does this in cases when the sched_lock is held by the CPU that traps.
If the trapping CPU does not hold sched_lock when it faults, then you can
do continue and steps as normal. I _think_ that maybe having the debugger
release sched_lock when it enters the debugger and acquire it on the way out
would work, but I'm not sure, and I haven't explored all the interactions of
that yet.
> --
> Boris Popov
> http://www.butya.kz/~bp/
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
