Date: Wed, 18 Jul 2001 18:58:09 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: freebsd-current@freebsd.org Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: vm86 problem in -CURRENT Message-ID: <200107180958.SAA13935@zodiac.mech.utsunomiya-u.ac.jp>
next in thread | raw e-mail | index | archive | help
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 = 01000000
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 0x20000, 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 = 01000000
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 0xfffff, 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 = 01000000
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 0xfffff, 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
0xc0000, where the video BIOS ROM resides, is mapped OK. But, somehow
0xa0000, 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107180958.SAA13935>