From owner-freebsd-current Tue Aug 3 8:59:46 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 E4281152D4; Tue, 3 Aug 1999 08:59:35 -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 KAA25560; Tue, 3 Aug 1999 10:58:49 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.8.5/8.6.4) id KAA17356; Tue, 3 Aug 1999 10:58:46 -0500 (CDT) Message-ID: <19990803105845.19595@right.PCS> Date: Tue, 3 Aug 1999 10:58:45 -0500 From: Jonathan Lemon To: Mike Smith Cc: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: APM related panic References: <37A22819.DD36695B@altavista.net> <199908020520.WAA01521@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199908020520.WAA01521@dingo.cdrom.com>; from Mike Smith on Aug 08, 1999 at 10:20:38PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Aug 08, 1999 at 10:20:38PM -0700, Mike Smith wrote: > > Jonathan; just some context, this is with your old 16-bit-protmode > patches, spiffed up for -current, which I committed late last week. Heh. I had just about forgotten about this patchset. I was somwehat under the impression it wasn't needed any more, what with the capabilities of the new loader. > > apm: CS_limit=0x0, DS_limit=0x0 > > These limits look pretty suspect, although the code segment below looks > OK. Yea, I see the later commits that force it to 0xffff; that is probably for the best, rather than trusting the BIOS. > > 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. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message