:> This argument is exactly why I added the 'disable acpi' option in the boot
:> loader menu. Of course, we STILL need to get good debugging information
:> from you as to why you get a Trap 9 when ACPI is disabled. This is the
:> more important issue.
:
:This is actually a known issue on Intel motherboards. Somehow we broke
:something in our bios32 code. 4.x works fine using the BIOS to enumerate
:PNP BIOS devices, but 5.x (including 5.0 and 5.1) get a GPF (Trap 9)
:with the code segment set to 0x58 trying to enumerate the last PNPBIOS
:device. Somehow the BIOS routine jumps off into lala land where it
:eventually traps. I dumped the BIOS and dissassembled and tried to walk
:it to figure out how it was breaking but couldn't see anything obvious.
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
I have a motherboard that even 4.x doesn't work on... same
deal, GPF while enumerating PNP devices. It died on
the 6th device or something like that. I went so far as
to 'fix' DDB's disassembler (in DFly) to properly decode the
code segment (instead of double faulting on a 'bad' EIP in DDB)
and properly show 16 bit instructions, and I set break points and
single-stepped through.
It died in the same place every time, during an attempt
to issue a write to a CS: prefixed memory address. But I
suspect a bad branch or indirect-jump table lookup.
I finally gave up but if I were to do it again I would
attach a serial console and record the single-step session all the
way through two device number iterations... the one prior to
the one that failed, and the one that failed, then I'd
compare the output for the successful device iteration verses
the failure to figure out where they diverge.
That's what I suggest... don't play around, just connect the
serial console, fix DDB's disassembler (you can pop the changes
that I made in DFly, they should be the same), single step
through two iterations, and compare.
If you figure out what is causing the problem I'd love an
email. I suspect it is a mapping overlap somewhere due to
the page 0 map. I just can't think of anything else it might
be.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
