So then, is fxp working OK again?
Conrad Sabatier
conrads at cox.net
Sat Apr 5 08:37:45 PST 2003
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"
More information about the freebsd-current
mailing list