On 24-Feb-01 Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Bruce
> Evans writes:
>: It seems to be another trap while holding sched_lock.  This should be
>: fatal, but the problem is only detected because trap() enables
>: interrupts.  Then an interrupt causes bad things to happen.  Unfortunately,
>: the above omits the critical information: the instruction at sw1b+0x6b.
>: There is no instruction at that address here.  It is apparently just an
>: access to a swapped-out page for the new process.  I can't see how this
>: ever worked.  The page must be faulted in, but this can't be done while
>: sched_lock is held (not to mention after we have committed to switching
>: contexts).
> sw1b+0x6b is ltr %si
> I note that this doesn't happen when the disks are clean on boot, but
> does happen when they are dirty.  The kernel is as of a cvsup 3pm MST
> today.  The kernel from 1am last night doesn't seem to have this
> problem.

Other people have reported this and I can't reproduce this.  The one case I
managed to track down so far involved proc0 having pcb_ext bogusly set,
resulting in cpu_switch() setting up a bogus GDT entry for a TSS and thus
generating a GPF which is the trap you see.  The enable_intr() in trap() then
sends things downhill fast.  I'm not sure yet why processes are having pcb_ext
bogusly set.  Hmm.  Make sure you have rev 1.35 or later of pcb.h.  Also,
try build a kernel from scratch from fresh sources..

> Warner


John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/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

Reply via email to