From owner-freebsd-current Sat Feb 24 15:56:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 542A137B69B for ; Sat, 24 Feb 2001 15:56:04 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f1ONu4181817; Sat, 24 Feb 2001 15:56:04 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200102240658.f1O6wiW85748@harmony.village.org> Date: Sat, 24 Feb 2001 15:55:42 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: Today's panic :-) Cc: current@FreeBSD.org, Bruce Evans Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24-Feb-01 Warner Losh wrote: > 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. 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 -- 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message