-------- Original-Nachricht -------- > Datum: Mon, 09 Nov 2009 18:46:43 +0100 > Von: Clemens zeidler <clemens.zeidler@xxxxxxxxxxxxxx> > the sc looks very useless for me if it says something for you please tell > me how to extract the info! I hope the following is enough of the sc (I > had to copy it by hand), if not please also tell me what is important for > you or how to dive deeper into the sc. > > invoke_command_trampoline__FPv() > arch_debug_call_with_fault_handler() > debug_call_with_fault_handler() > . > . > . > panic() > page_fault_exeption_FP6iframe() > int_bottom_user() The interesting part (where the page fault actually happened) would come after this point. It is however already a bit weird that the page fault goes through int_bottom_user(), although the panic message says that interrupts were disabled. > By using dprintf I found the crash position. It crashed when ACPI try to > create a dpc queue with new_dpc_queue, when calling spawn_kernel_thread. > > > On Mon, 09 Nov 2009 09:37:51 +0100, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> > > wrote: > > > Clemens zeidler <clemens.zeidler@xxxxxxxxxxxxxx> wrote: > >> I'm just working on IRQ routing using ACPI. I put the code to readout > >> the > >> routing table and reassign the irq's in arch_int_init_post_vm. The > >> problem > >> is that there is crash when I try to get the ACPI module: > >> > >> PANIC: page fault, but interrupts were disabled. touching address > >> 0x0000000c from eip 0x80058c22 Apparently a NULL pointer. eip 0x80058c22 refers to the somewhere in the kernel proper. If the stack trace is broken for some reason (which might be a bug that should be fixed), then you can at least look up the address with the "ls" command. Looking at the objdump will help to understand what pointer that would be. CU, Ingo