In message <[EMAIL PROTECTED]> Bruce Evans 
: 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


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to