r36542 Kernel Panics on Boot

[mbrumbelow]

hrev36542 kernel panics on DELL Inspiron & HP laptops. Works fine on desktop system. Include screenshots of the two different systems.

[mbrumbelow]

Screenshot of HP laptop

[mbrumbelow]

Screenshot of DELL laptop

[tqh]

Looks like two different issues, the HP one is ACPI related.

[tqh]

Oops, wrote in wrong area. Additional info:

The Dell one I'm not so sure, could you try disabling ACPI at boot. ( ​http://www.haiku-os.org/docs/userguide/en/bootloader.html )

[mbrumbelow]

Both boot with ACPI turned off.

[tqh]

Looks like it panics while initializing the embedded controller. It is waiting for a signal and there is nothing in run queue. Should it really panic? If you can you should be able to type "continue" in these kdls.

[mbrumbelow]

Typing "continue" keeps me in kdl for both machines.

[tqh]

According to deadyak we should have an idle thread to switch to, but doesn't seem to be the case.

[tqh]

Are you building for trunk or are these alpha2 images?

[mbrumbelow]

They are alpha2 images.

[tqh]

Ingo, from what I can tell it should use reschedule_no_op, not reschedule. And the idle_threads should already exist. Do you have any idea what might be goind on?

I think we could make acpi_embedded_controller use polling this early if needed, but I'd like to know what is going on. (See ​http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/bus_managers/acpi/acpi_embedded_controller.cpp#L674 )

[bonefish]

Replying to tqh:

Ingo, from what I can tell it should use reschedule_no_op, not reschedule. And the idle_threads should already exist. Do you have any idea what might be goind on?

The early kernel initialization is basically single threaded and performed by what will later become "idle thread 1" (there's a very small amount of per-CPU initialization happening on off-boot CPUs, too). Interrupts are disabled, which imposes several restrictions on the code executed. E.g. locking primitives can be used as long as it is guaranteed that they do not wait. Mutexes, recursive_locks, and rw_locks are fine, since no other thread has been running at that point. Anything that causes the idle thread to wait (snooze(), not yet triggered condition variables) is a problem though. My guess is that the ACPI code is doing something like this.

I'll add a panic() in scheduler_reschedule_no_op(), triggered when the calling thread is not continuing to run. It will fail early and thus help to identify the perpetrator.

In the meantime the output of the KDL command "threads" would be helpful.

[bonefish]

Replying to bonefish:

I'll add a panic() in scheduler_reschedule_no_op(), triggered when the calling thread is not continuing to run. It will fail early and thus help to identify the perpetrator.

Done in hrev36560 (trunk).

[tqh]

Added some code to let acpi_embedded_controller poll instead on bootup in hrev36565. I think it should help. It's only available in builds from trunk atm.

[mbrumbelow]

Still panics on DELL with trunk build hrev36564, included "threads" command as requested.

[tqh]

Ah, I think that image will help a lot. Does it work on the other machine now?

I guess we are not allowed to snooze during boot. I think we can switch to use a spinlock while booting. Similar to what is done in hrev36565 for the embedded controller.

[bonefish]

Replying to tqh:

Ah, I think that image will help a lot. Does it work on the other machine now?

I guess we are not allowed to snooze during boot. I think we can switch to use a spinlock while booting. Similar to what is done in hrev36565 for the embedded controller.

Yep, you can spin() instead of snooze().

[mbrumbelow]

Still panics on HP with trunk build hrev36564, included "threads" command as requested.

[mbrumbelow]

The good news is unlike before, the stack traces are now consistent.

[tqh]

Trying to avoid using snooze and use spinlocks instead in hrev36569.

[mbrumbelow]

Updated build to hrev36571 and it works on all machines. Syslog is clean, no error or warning conditions. Please close.

[tqh]

I meant to say spin not spinlocks, sorry for the confusion, it is not synchronization primitive. mbrumbelow thanks for the fast response.