From owner-freebsd-current Sun Jul 26 22:02:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA10187 for freebsd-current-outgoing; Sun, 26 Jul 1998 22:02:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zone.baldcom.net (green@zone.BALDCOM.NET [205.232.46.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA10178 for ; Sun, 26 Jul 1998 22:02:40 -0700 (PDT) (envelope-from green@zone.baldcom.net) Received: from localhost (green@localhost) by zone.baldcom.net (8.8.8/8.8.7) with SMTP id BAA06574; Mon, 27 Jul 1998 01:02:03 -0400 (EDT) Date: Mon, 27 Jul 1998 01:02:03 -0400 (EDT) From: Brian Feldman To: Jonathan Lemon cc: freebsd-current@FreeBSD.ORG Subject: Re: More doscmd adventures/lockups In-Reply-To: <19980723150547.60718@right.PCS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alright, I've tested this a lot, and it fixes the lockups. Why don't you commit it? It might be a gross workaround, but it does the Right Thing. Cheers, Brian Feldman green@unixhelp.org On Thu, 23 Jul 1998, Jonathan Lemon wrote: > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message