Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Sep 2000 21:39:28 -0700 (PDT)
From:      John Baldwin <jhb@pike.osd.bsdi.com>
To:        Boris Popov <bp@butya.kz>
Cc:        Manfred Antar <null@pozo.com>, current@FreeBSD.ORG
Subject:   Re: New Fatal trap in Current SMP (random.dev changes ??)
Message-ID:  <200009110439.VAA32934@pike.osd.bsdi.com>
In-Reply-To: <Pine.BSF.4.10.10009111134358.26670-100000@lion.butya.kz> from Boris Popov at "Sep 11, 2000 11:37:34 am"

next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@bsdi.com> -- 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009110439.VAA32934>