Re: AMD64 impressions (Re: AMD64 box)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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:

    AMIBIOS
    Version:	08.00.09
    Build Date:	08/21/03
    ID:		K8V__047

    System Memory:
    Size:	1024MB

    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
    scan.  

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>