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.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
