On 05-Apr-2003 Maxime Henrion wrote: > Conrad Sabatier wrote: >> >> <groan> Still no go. I'm still getting a panic in bus_dmamem_alloc(). >> Here's the info I copied down by hand: >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x24 >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc0301639 >> stack pointer = 0x10:0xc053bd34 >> frame pointer = 0x10: 0xc053bd48 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL=0 >> current process = 0() >> kernel: type 12 trap, code = 0 >> Stopped at bus_dmamen_alloc+0x9 movl 0x24(%edx),%eax >> db>trace >> bus_dmamem_alloc(0, c04a8aa0, 1, c04a965c, ffffffff) at >> bus_dmamen_alloc+0x9 >> acpi_alloc_wakeup_handler(0, 532000, 532020, 532000, 0) >> at acpi_alloc_wakeup_handler+0xa9 >> mi_startup() at mi_startup+0x99 >> begin() at begin+0x2c >> db> >> >> Incidentally, I've been getting acpi initialization failures in the last >> umpteen kernels I've been through, but without panicing the machine. > > Could you post a complete stack trace? There's no fxp functions in this > (incomplete) trace. Are you sure the problem you're having now is fxp > related ? I think you're right. I built a GENERIC kernel, rebooted without the acpi module, and it's working fine. Finally, I was able to get acpidump to work properly, and created a new /boot/acpi_dsdt.aml file. About to attempt a normal boot now. Will let you know. -- Conrad Sabatier <conrads_at_cox.net> - "In Unix veritas"Received on Sat Apr 05 2003 - 06:37:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:02 UTC