From owner-freebsd-current Tue Aug 3 11: 4:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 97CDE152E1 for ; Tue, 3 Aug 1999 11:04:08 -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 NAA26197; Tue, 3 Aug 1999 13:03:29 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.8.5/8.6.4) id NAA08991; Tue, 3 Aug 1999 13:03:27 -0500 (CDT) Message-ID: <19990803130326.56771@right.PCS> Date: Tue, 3 Aug 1999 13:03:26 -0500 From: Jonathan Lemon To: Mike Smith Cc: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: APM related panic References: <19990803105845.19595@right.PCS> <199908031657.JAA03722@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199908031657.JAA03722@dingo.cdrom.com>; from Mike Smith on Aug 08, 1999 at 09:57:10AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Aug 08, 1999 at 09:57:10AM -0700, Mike Smith wrote: > > > > Fatal trap 9: general protection fault while in kernel mode > > > > instruction pointer = 0x48:0x8034 > > > > stack pointer = 0x10:0xc0279e98 > > > > frame pointer = 0x10:0x67890000 > > > > code segment = base 0xc00f0000, limit 0xffff, type 0x1b > > > > = DPL 0, pres 1, def32 1, gran 0 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > > Why is IOPL zero? I've also noted that making a bios16 call also > > > results in IOPL being zero (I have more that I want to take up with you > > > on that at some stage, since it's got me stumped, but one thing at a > > > time). > > > > The IOPL should be zero, in order to virtualize interrupts. If it's > > more than zero, the BIOS code can turn off interrupts, which isn't > > something we want to do. > > Ok. I'm presuming then that we have a tss in place that allows I/O > operations? That was my major concern... Nevermind, I was thinking of vm86 mode. In vm86 mode, the IOPL doesn't have anything to do with I/O, and we use the I/O permission bitmaps. There isn't an I/O bitmap for the kernel (only user processes), so the kernel isn't able to make vm86 I/O calls at this point. This could be fixed, but I haven't seen the need for it yet. However, this is 16-bit protected mode, which (other than the addressing size) is exactly the same as 32-bit kernel mode. Thus the IOPL doesn't really matter, since all the bios selectors are set up with kernel privs (in ring 0). -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message