From owner-freebsd-current Sun Mar 16 20:34:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA19093 for current-outgoing; Sun, 16 Mar 1997 20:34:05 -0800 (PST) Received: from sumatra.americantv.com (sumatra.americantv.com [199.184.181.250]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19081 for ; Sun, 16 Mar 1997 20:33:55 -0800 (PST) Received: from right.PCS (right.pcs. [148.105.10.31]) by sumatra.americantv.com (8.7.6/8.7.3) with ESMTP id WAA16192; Sun, 16 Mar 1997 22:37:29 -0600 (CST) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id EAA11328; Mon, 17 Mar 1997 04:34:15 GMT Message-ID: <19970316223415.24505@right.PCS> Date: Sun, 16 Mar 1997 22:34:15 -0600 From: Jonathan Lemon To: Sean Eric Fagan Cc: current@FreeBSD.org Subject: Re: Gotcha in moving to post 4.4 lite2 merge ``world''. References: <199703160024.QAA13864@kithrup.com>; <199703161933.LAA09028@kithrup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199703161933.LAA09028@kithrup.com>; from Sean Eric Fagan on Mar 03, 1997 at 11:33:52AM -0800 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mar 03, 1997 at 11:33:52AM -0800, Sean Eric Fagan wrote: > 3. As jlemon points out himself, it can lock up the system. (Not > completely lock up, but only interrupt-driven services run. And, sadly, X > is not interrupt driven. :() We're not sure what's going on here; my > suspicion is an infinite loop in the kernel, doscmd getting a cli passed > through, and/or we're somehow bypassing the normal code path that allows the > kernel to switch processes. What's happening (in the test case I'm working on) is that the vm86() process is going into an infinite loop, and somehow or the other, an AST interrupt is not being generated. Interrupts are enabled, the kernel is getting called, the AST flag in _ipending is set, but when _doreti gets hit, it just jumps back into vm86 mode instead of calling trap(). Right now, I can recover by writing a garbage %ds on the frame, and forcing a call into trap() via a doreti fault. Any feedback or ideas on how this could happen are happily accepted. -- Jonathan