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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
