Bug #397

Dragonfly 1.6 - Fatal trap 12

Added by CCdrom over 7 years ago. Updated over 4 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Hi,

i'm trying to install Dragonfly-BSD (dfly-1.6.0_REL.iso) with GENERIC kernel on
my laptop (details at the end of this email). But everytime i boot from the
installation media i get a kernel panic like this (in verbose mode):
---------------
cbb1: <TI1225 PCI-Cardbus Bridge> at device 10.1 on pci0
cardbus1.cbb1.pci0.pcib0.legacypci0.nexus.0.root0
cardbus1: <CardBus bus> [tentatitive] on cbb1
cardbus1: <CardBus bus> [attached!] on cbb1
pccard1.cbb1.pci0.pcib0.legacypci0.nexus0.root0
pccard1: <16-bit PCCard bus> [tentative] on cbb1
pccard1: <16-bit PCCard bus> [attached!] on cbb1
pci_cfgintr_unique: hard-routed to irq 10

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xeb761
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc00eb647
stack pointer = 0x10:0xc0758a00
frame pointer = 0x10:0xc0758a00
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def 32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
current threat = pri 12

kernel: type 12 trap, code=0
Stopped at 0xc00eb647: cmpb %cs:0x1(%esi),%bl
---------------
I searched a lot of forums (post in some forums about this problem), read the
mailing list, and have done a lot of things to solve this problem, but nothing
helps:
---------------
- Unplug all Devices
- Boot with ACPI enabled, Boot in Single user modus, Boot in save Mode
- Boot from floppy-images
- Update system bios
- Disable IDE drives, PS/2, floppy, com ports, lpt port, disable dma (Don't
have a chance to configure the IRQ's ACPI in the bios)
- Set "Enable power saving" in bios results in a hanging freebsd (calibrating
clocks)
- Disable "Enable PnP OS Support" in Bios
- Set the following sysctl- variables at the bootloader:
set hw.pcic.intr_path=1 (tip from Ted Mittelstaedt, its the same machine as
my) http://72.14.221.104/search?q=cache:rxUdywqIYDcJ:ftp4.de.freebsd.org/pub/
FreeBSD/gnats/gnats/i386/33574+0xc00eb637&hl=de&gl=de&ct=clnk&cd=1)
set hw.pcic.irq=0

set hw.pci.allow_unsupported_io_range=1
set hw.pci_disable_bios_route=1 (http://leaf.dragonflybsd.org/mailarchive/
kernel/2004-03/msg00328.html)
---------------
There was no solution. Windows 2000 Professional, OpenBSD 4.0, NetBSD 3.1 and
Knoppix 3.9 are working fine. Memtest86 und Windows memory Diagnostic doesn't
report any erros. The machine works very stable.
I get nearly the same error installing FreeBSD 6.2/5.4. Here ist the screen
from FreeBSD 6.2:
---------------
kbd1 at kbdmux0
cpu0 on motherboard
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> pcibus 0 on motherboard
pir0: <PCI Interrupt Routing Table: 8 Entries> on motherboard
$PIR: BIOS IRQ 11 for 0.14.INTA is not valid for link 0x60
pci0: <PCI bus> on pcib0

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xeb761
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc00eb647
stack pointer = 0x28:0xc10209e0
frame pointer = 0x28:0xc10209e0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def 32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
Uptime: 1s
Automatic reboot in 15 Seconds - press a key on the console to abort
---------------
Here are the details to my machine:
---------------
- Gericom Overdose Polo-5100C (sold as "Network", a branding of Media-Markt,
store in europe)
- 433Mhz Intel Celeron
- Intel 440 BX Chip
- SystemSoft Bios from 18. May 1999 (latest)
- 128MB Total Memory
- 20GB HDD with Windows 2000 and currently OpenBSD installed on it.
- S3 Graphics VIRGE-MX
- ESS 1969 Sound
- Floppy, Cdrom, USB-Port, 2xPCMCIA, COM, lpt, PS/2
---------------
I'm sorry for my english and hope you can help me - I don't wan't to run
OpenBSD on it.

Dirk Koenig

History

#1 Updated by corecode over 7 years ago

could you enter "trace" at the debugger prompt and paste the output (if you have to transcribe it manually, the function names should be enough for the beginning)?

cheers
simon

#2 Updated by CCdrom over 7 years ago

Hi,

here is the complete output of "trace":
---------------
db> trace
kernbase(1,c06ffacc,ff800000,a0b,50) at 0xc00eb647
_end(cb9d08c4,c4f6ec8b,81067540,ffffe5,e67f2400) at 0xc06ffa70
db>
---------------
Dirk
-----Ursprüngliche Nachricht-----
Von: DragonFly issue tracker <>
Gesendet: 06.12.06 21:39:42
An:
Betreff: [issue397] Dragonfly 1.6 - Fatal trap 12

Simon 'corecode' Schubert <> added the comment:

could you enter "trace" at the debugger prompt and paste the output (if you have to transcribe it manually, the function names should be enough for the beginning)?

cheers
simon

----------
status: unread -> chatting

_______________________________________________________
DragonFly issue tracker <>
<http://bugs.dragonflybsd.org/issue397>
_______________________________________________________

#3 Updated by civilizd over 7 years ago

I got the very same problem, when i was trying to boot dragonfly 1.6
CD on my friend's laptop.
This is strange, because on mine it works without any problems.
(booting from the same disc)

Only difference is that when i boot with ACPI enabled, the system
"just hangs" (but this seems to be due to ACPI)
Vita

O ASCII Ribbon Campaign
/ \ -no HTML in e-mail
-no proprietary attachments in e-mail

#4 Updated by corecode over 7 years ago

this looks like BIOS code to me. for some reason it is mapped at 0xc00eb000, but %esi is (of course) 0xeb761. it is missing 0xc0000000 bytes :) maybe the bios needs to be mapped into a lower memory area?

cheers
simon

#5 Updated by dillon over 7 years ago

:Dirk König wrote:
:> Fatal trap 12: page fault while in kernel mode
:> fault virtual address = 0xeb761
:> fault code = supervisor read, page not present
:> instruction pointer = 0x8:0xc00eb647
:> stack pointer = 0x10:0xc0758a00
:> frame pointer = 0x10:0xc0758a00
:> code segment = base 0x0, limit 0xfffff, type 0x1b
:> = DPL 0, pres 1, def 32 1, gran 1
:> processor eflags = interrupt enabled, resume, IOPL = 0
:> current process = 0 (swapper)
:> current threat = pri 12
:>
:> kernel: type 12 trap, code=0
:> Stopped at 0xc00eb647: cmpb %cs:0x1(%esi),%bl
:
:this looks like BIOS code to me. for some reason it is mapped at 0xc00eb000, but %esi is (of course) 0xeb761. it is missing 0xc0000000 bytes :) maybe the bios needs to be mapped into a lower memory area?
:
:cheers
: simon

That is very odd. It is the BIOS area. When it makes a BIOS call the
BIOS is limited to VM86 mode so it doesn't see the full pc, just the
16 bit version (and it runs segment-relative of course).

But the elfags and segment registers are not indicating that it was
running in VM86 mode, so the kernel wasn't *trying* to run BIOS code
at that time.

The failure is somewhere else and it would probably take some sleuthing
on the kernel stack to find it.

-Matt
Matthew Dillon
<>

#6 Updated by CCdrom over 7 years ago

I have the latest System-Bios on my Laptop, there is no newer version available.

> maybe the bios needs to be mapped into a lower memory area?
How could I do this ?

#7 Updated by dillon over 7 years ago

:Dirk König <> added the comment:
:
:I have the latest System-Bios on my Laptop, there is no newer version available.
:
:> maybe the bios needs to be mapped into a lower memory area?
:How could I do this ?
:

That has nothing to do with it. The confusion is over the kernel's
KVA representation of the BIOS. The BIOS sees a VM86 segment address,
not that high address. It should be just fine.

I looked in the mail archives and didn't see a 'trace' from the DDB
prompt. That's the first step... we need to identify where it is
crashing.

Then you need to test with and without ACPI, and if this is a SMP box
then with and without SMP.

-Matt
Matthew Dillon
<>

#8 Updated by alexh about 5 years ago

Did this happen again? Did anyone else experience this? Can this be closed or is
it still relevant?

#9 Updated by alexh over 4 years ago

nobody seems to care anymore, it's 3 years old, no one has ever reported it again.
closing this.

Cheers,
Alex Hornung

Also available in: Atom PDF