DragonFly kernel List (threaded) for 2003-11
Re: AMD64 impressions (Re: AMD64 box)
:Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
:> I love this K8V motherboard! Well, except for PNPBIOS not working due
:> to bugs in their BIOS.
:I don't have one of the Asus K8V boards. Can you tell me the version of
:the BIOS you have, and describe in details the BIOS bugs you're seeing?
:I know who to pass this onto.
:-- David (obrien@xxxxxxxx)
Yah, in setup's MAIN/SYSTEM-INFORMATION it reports:
Build Date: 08/21/03
If I enable options PNPBIOS on either FreeBSD-4.x or DragonFly (I haven't
tried 5.x but I don't see any differences in the code between 5.x and 4.x
that I haven't already tried applying to DFly), and disable
'device acpica', the failure occurs in the BIOS during the PNP device
I would not classify it as a critical failure since the PNP scan will
not be done if kernel is built with the ACPI device, but it appears to
be a bug in the BIOS's PNP code so it's probably worth following up.
The failure always occurs at exactly the same place. A boot -v:
pnpbios: 17 devices, largest 194 bytes
(scans handle's 0-4)
pnp_get_devnode cd=5 nxt=6 size=37 handle=5 devid=0303d041 type=090000, attrib=0003
PNP0303: adding irq mask 0x2
PNP0303: adding io range 0x60-0x60, size=0x1, align=0x1
PNP0303: adding io range 0x64-0x64, size=0x1, align=0x1
pnpbios: handle 5 device ID PNP0303 (0303d041)
(traps while trying to scan handle 6)
Fatal trap 9: general protection fault while in kernel mode:
Instruction pointer = 0x58:125c
stack pointer = 0x10:0xf80
frame pointer = 0x10:0x0
code segment = base 0xc00f0000, limit 0xffff, type 0x1B
= DPL 0, pres 1, def32 0, gran 0
Stopped at: 0xc00f125c: movb $0,%cs:0x128c
I modified DDB to properly decode the code segment base address and
to display the 16 bit instructions more correctly, and I single stepped
through two PNPBIOS calls, the one for handle 5 which worked, and the
one for handle 6 which failed.
As far as I can tell everything looked good except that the PNPBIOS
code decided to execute a write with a code segment prefix a little
bit after copying out the record to our supplied buffer. It is the
write using %cs that causes the general protection fault.