Re: ACPI problems with this morning's -CURRENT

(To recap: I'm having ACPI problems on a DFI CD70-SC, with both 5.1-R and
5-CURRENT.  Booting GENERIC doesn't show any problems, however, so there's a
good chance it's a misconfiguration issue.)

Thus spake Damian Gerow (damian_at_sentex.net) [15/09/03 17:34]:
> It's attached.  There's no APM in there.  I did some more testing -- GENERIC
> works for the -CURRENT date I stated before, and 5.1-R.  As soon as I
> compile my own kernel, it breaks.
> 
> I'm working on compiling this with debugging, so I can take a closer look at
> what's going on.

Okay, here's a backtrace with debugging.  Unfortunately, when dropped to the
debugging prompt, I don't know what to do.  Attached is the kernel config I
used to generate this on 5.1-R, I can re-do this on -CURRENT if need be.

Here's a snippet of boot, and the stack backtrace:

    ...
    Preloaded elf kernel "/boot/kernel/kernel" at 0xc04b8000
    Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04b81f4
    ...
    real memory  = 536870912 (512 MB)
    avail memory = 516313088 (492 MB)
    panic: pmap_mapdev: Couldn't allocate kernel virtual memory
    Stack backtrace:
    backtrace(c035b0cc,c03baea0,c0372994,c04dabbc,100) at backtrace+0x17
    panic(c0372994,c036f000,0,0,0) at panic+0x93
    pmap_mapdev(1fff3000,c036ec14,c04dac48,c04dabcc,c048e880) at pmap_mapdev+0x4b
    AcpiOsMapMemory(1fff3000,0,c036ec14,c04dabbc,c04dabc4) at AcpiOsMapMemory+0x1e
    AcpiTbGetThisTable(c04dac48,c04dac00,c04dac58,c04dac48,c04dac48) at AcpiTbGetThisTable+0xf0
    AcpiTbGetTableBody(c04dac48,c04dac00,c04dac58,c0387ebc,c036ec14) at AcpiTbGetTableBody+0x4c
    AcpiTbGetTable(c04dac48,c04dac58,9,1fff3000,0) at AcpiTbGetTable+0x38
    AcpiTbGetTableRsdt(c04daca0,c04daca0,c04dacb4,1,f6010) at AcpiTbGetTableRsdt+0x23
    AcpiLoadTables(c04a8bc0,c04a49ac,0,0,0) at AcpiLoadTables+0xa6
    acpi_identify(c04a7528,c151cb00,c0379a14,c1506190,c151cb00) at acpi_identify+0xb4
    DEVICE_IDENTIFY(c04a7528,c151cb00,c151cb00,c151cb00,c04dad18) at DEVICE_IDENTIFY+0x50
    bus_generic_probe(c151cb00,c3fcc098,c04dad34,c01da1b8,c151cb00) at bus_generic_probe+0x2e
    nexus_attach(c151cb00,c3fcc098,c0379a1c,c151cb00,c151d000) at nexus_attach+0x14
    DEVICE_ATTACH(c151cb00,c151cb00,0,c14ea5d8,1) at DEVICE_ATTACH+0x48
    device_probe_and_attach(c151cb00,c14ea5d8,c04dad80,c0321635,c151d000) at device_probe_and_attach+0x7d
    root_bus_configure(c151d000,c0371fdc,0,c04dad98,c01960a5) at root_bus_configure+0x28
    configure(0,4d7000,4d7c00,4d7000,0) at configure+0x35
    mi_startup() at mi_startup+0xb5
    being() at begin+0x2c
    Debugger("panic")
    Stopped at    Debugger+0x54:    xchgl   %ebx,in_Debugger.0
    db> print
    c01c08b0
    db> show pcpu
    cpuid = 0
    curthread = 0xc03b4640: pid 0 "swapper"
    curpcb = 0
    fpcurthread = none
    idlethread = 0xc151f850: pid 11 "idle"
    currentldt = 0x28
    db> show map
    Task map 0xc01c08b0: pmap=0x4de80574, nentries=604293056, version=742228750


    Fatal trap 12: page fault while in kernel mode
    fault virtual address   = 0x4c70500
    fault code              = supervisor read, page not present
    instruction pointer     = 0x8:0xc02f3a40
    stack pointer           = 0x10: 0xc04da940
    frame pointer           = 0x10: 0xc04da960
    code segment            = base 0x0, limit 0xfffff, type 0x1b
                            = DPL 0, pres 1, def32 1, gran 1
    processor eflags        = resume, IOPL = 0
    current process         = 0 (swapper)
    kernel: type 12 trap, code=0
    Stopped at   Debugger+0x54:   xchgl   %ebx,in_Debugger.0
    db>

Given that I caused a panic while in the debugger, and that I don't know
what I'm looking for, I stopped here.  (Further 'show map's didn't result in
a panic, however.)

Note that if I /don't/ boot with ACPI, I can boot just fine, with no power
management.