From owner-freebsd-current Thu Jul 23 13:06:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22874 for freebsd-current-outgoing; Thu, 23 Jul 1998 13:06:52 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22816 for ; Thu, 23 Jul 1998 13:06:43 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id PAA14490; Thu, 23 Jul 1998 15:06:20 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id PAA19992; Thu, 23 Jul 1998 15:05:48 -0500 Message-ID: <19980723150547.60718@right.PCS> Date: Thu, 23 Jul 1998 15:05:47 -0500 From: Jonathan Lemon To: Brian Feldman Cc: freebsd-current@FreeBSD.ORG Subject: Re: More doscmd adventures/lockups References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: ; from Brian Feldman on Jul 07, 1998 at 02:14:41PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 07, 1998 at 02:14:41PM -0400, Brian Feldman wrote: > Yessiree, doscmd has ways of locking me up without a panic. I'll explore > what happened this time: I was using my 5[0-2][0-8]mb dos drive in bochs, > installing MS-DOS 6.22. I tried using doscmd to boot it, doscmd -bx... > after Starting msdos... the whole computer froze, I waited a few minutes, > and hit reset when I was sure it was locked up solid. To recap: bochs was > loading dos on the drive, on disk 2 by now, and doscmd -bx tried to boot > the drive; this was standard access, no vn(4) problems. Sigh. I've spent the last few weeks trying to track this down, but to no avail. It doesn't _appear_ to be a doscmd specific bug, but rather a problem with the cpl settings. What I'm seeing here is that when the kernel enters vm86 mode, it has cpl == 0, which is all well and good. When an interrupt occurs, and the kernel is entered via one of the INTR() entry points, it seems that cpl != 0. I don't know how this is possible, but that is what I seem to be observing. This cpl is then restored in _doreti right before returning to either user mode, or vm86 mode, which means that we are running in non-kernel mode with AST's blocked. Attached is a gross workaround for the problem that fixes it on my box. Let me know if it also fixes the lockups that you are having. -- Jonathan Index: ipl.s =================================================================== RCS file: /tuna/ncvs/src/sys/i386/isa/ipl.s,v retrieving revision 1.21 diff -u -r1.21 ipl.s --- ipl.s 1998/03/23 19:52:59 1.21 +++ ipl.s 1998/07/23 19:55:53 @@ -169,9 +169,11 @@ * When the cpl problem is solved, this code can disappear. */ ICPL_LOCK - cmpl $0,_cpl + cmpl $0,_cpl /* cpl == 0, skip it */ je 1f - testl $PSL_VM,TF_EFLAGS(%esp) + testl $PSL_VM,TF_EFLAGS(%esp) /* going to VM86 mode? */ + jne doreti_stop + testb $SEL_RPL_MASK,TRAPF_CS_OFF(%esp) /* to user mode? */ je 1f doreti_stop: movl $0,_cpl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message