From owner-freebsd-current Fri Feb 23 22:58:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id F02CB37B65D for ; Fri, 23 Feb 2001 22:58:47 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1O6wiW85748; Fri, 23 Feb 2001 23:58:44 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102240658.f1O6wiW85748@harmony.village.org> To: Bruce Evans Subject: Re: Today's panic :-) Cc: current@FreeBSD.ORG In-reply-to: Your message of "Sat, 24 Feb 2001 17:41:40 +1100." References: Date: Fri, 23 Feb 2001 23:58:44 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message 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