Re: So then, is fxp working OK again?

From: Conrad Sabatier <conrads_at_cox.net>
Date: Sat, 05 Apr 2003 10:42:48 -0600 (CST)
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