Date: Fri, 23 Feb 2001 23:58:44 -0700 From: Warner Losh <imp@harmony.village.org> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.ORG Subject: Re: Today's panic :-) Message-ID: <200102240658.f1O6wiW85748@harmony.village.org> In-Reply-To: Your message of "Sat, 24 Feb 2001 17:41:40 %2B1100." <Pine.BSF.4.21.0102241719140.26925-100000@besplex.bde.org> References: <Pine.BSF.4.21.0102241719140.26925-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0102241719140.26925-100000@besplex.bde.org> 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 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?200102240658.f1O6wiW85748>