From owner-freebsd-current Wed Jul 18 2:48:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (Postfix) with ESMTP id 8DCB337B403 for ; Wed, 18 Jul 2001 02:48:37 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from nantai.utsunomiya-u.ac.jp by nasu.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/26Jan01-1134AM) id f6I9mYc183741; Wed, 18 Jul 2001 18:48:34 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp by nantai.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/30Jan01-0241PM) id f6I9mYl402739; Wed, 18 Jul 2001 18:48:34 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:cprb06PBUWEEf1VJfMJq9XFqxhlud5XG@zodiac.mech.utsunomiya-u.ac.jp [160.12.43.7]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id SAA13935; Wed, 18 Jul 2001 18:58:10 +0900 (JST) Message-Id: <200107180958.SAA13935@zodiac.mech.utsunomiya-u.ac.jp> To: freebsd-current@freebsd.org Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: vm86 problem in -CURRENT Date: Wed, 18 Jul 2001 18:58:09 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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