vm86 problem in -CURRENT

[Kazutaka YOKOTA]

I am trying to track down a vm86 problem in -CURRENT.  The trouble is
that this is an intermittent problem and is not always reproducible.

The last one I managed to capture was:

==
VESA: set_mode(): 24(18) - 259(103)
VESA: about to set a VESA mode...


Fatal trap 12: page fault while in vm86 mode
cpuid = 1; lapic.id = 0100
fault virtual address   = 0xc638b
fault code  = user read, page not present
instruction pointer = 0xc000:0x638b
stack pointer   = 0x0:0xf9c
frame pointer   = 0x0:0xfdc
code segment= base 0x2, limit 0x504eb, type 0x0
= DPL 0, pres 0, def32 0, gran 0
processor eflags= interrupt enabled, resume, vm86, IOPL = 0
current process = 444 (logo_saver)
kernel: type 12 trap, code=0
Stopped at  0x638b:

Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address   = 0x638b
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc02c0ad0
stack pointer   = 0x10:0xc91a8e44
frame pointer   = 0x10:0xc91a8e48
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 444 (logo_saver)
 kernel: type 12 trap, code=0
db trace


Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address   = 0x638b
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc02c0ad0
stack pointer   = 0x10:0xc91a8d68
frame pointer   = 0x10:0xc91a8d6c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 444 (logo_saver)
kernel: type 12 trap, code=0
db
==

This was generated when I ran a small test program which tried to
switch to the VESA 800x600 256 color mode via syscons ioctl.  This
ioctl leads to vm86_intcall() to call the VESA video BIOS.  (I had a
report from a -CURRENT user that setting a VESA mode by `vidcontrol
VESA_800x600' bombed his system too.)  My test program and vidcontrol
has no trouble in RELENG_4 (and RELENG_3).

The trap was generated inside the VESA video BIOS ROM. The instruction
in question was:
repe stosw es(edi)
where es and edi were set to 0xa000 and 0x0 respectively immediately
before the above instruction.  (The video BIOS was trying to clear the
video ram.)

As far as I understand, the entire 1M bytes of lower physical memory
is supposed to be mapped when vm86_intcall() is run.  Apparently
0xc, where the video BIOS ROM resides, is mapped OK.  But, somehow
0xa, where the video ram is, went missing.  As I wrote before,
this test program sometimes runs fine, sometimes does not.

Where in the kernel should I investigate further?

Kazu


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: vm86 problem in -CURRENT

[Jonathan Lemon]

In article 
local.mail.freebsd-current/[EMAIL PROTECTED] you 
write:
As far as I understand, the entire 1M bytes of lower physical memory
is supposed to be mapped when vm86_intcall() is run.  Apparently
0xc, where the video BIOS ROM resides, is mapped OK.  But, somehow
0xa, where the video ram is, went missing.  As I wrote before,
this test program sometimes runs fine, sometimes does not.


When you make a vm86 call from the kernel, it uses a private page
table (located at vm86paddr) in order to map the pages.  The details
of the layout can be found in i386/i386/vm86.c.

This page table is initially populated in locore.s, and contains 
only page 0 + the ISA hole (0xa - 0x10).  If getmemsize()
detects that there is a hole between basemem and ISA memory, the pages
in this hole will additionally be mapped into the vm86 space.

If you're getting a page fault while trying to access 0xa, then
it would seem that the entries in the vm86 page table are incorrect.
You can check this by examining the page table located at vm86paddr.
-- 
Jonathan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message