Opened 6 years ago
Last modified 4 years ago
#14718 new bug
System freezes on shutdown, but reboot works fine.
Reported by: | bullfrog | Owned by: | yongcong |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/Power | Version: | R1/beta1 |
Keywords: | Cc: | tqh | |
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description
Beta1, 64bit, most recent system update. My HP Pavilion G6 laptop freezes at shutdown time at the dialog after applications quit, no mouse, no keyboard, no shutdown. This behavior happens with both Power Off from the shutdown menu, and shutdown from the terminal. "shutdown -q" results in instant freeze, loss of keyboard and mouse. If I let the system run at this point, it overheats and goes into thermal shutdown, even with my extra cooling fans running. This is the only time I get overheating on this box, on any operating system. I tried a Beta1 32bit on the system, same issue.
Rebooting works excellent, no freezes, quick reboot.
Attachments (1)
Change History (16)
comment:1 by , 6 years ago
Cc: | added |
---|---|
Component: | - General → Drivers/Power |
Owner: | changed from | to
comment:3 by , 6 years ago
comment:4 by , 6 years ago
Only solved for one scenario, which was a different machine than as posted. The bug as posted is still present for the machine I originally posted about.
comment:5 by , 6 years ago
Blocking: | 14887 added |
---|
comment:6 by , 6 years ago
Usually, the thermal dissipation is compromised or you have a hardware defect in the CPU/motherboard. Professionally cleaning and updating the BIOS can solve a few problems, but a elusive hardware (CPU) defect might be the real issue. Thermal shutdown usually means something is wrong in cooling or a hardware error.
comment:7 by , 6 years ago
As I mentioned in https://dev.haiku-os.org/ticket/14954#comment:5 this is more likely a problem with the machine firmware and Haiku not implementing quirks for broken hardware. It also not likely to happen as we don't have resources or hardware to fix these.
comment:8 by , 6 years ago
Blocking: | 14887 removed |
---|
Also this is very unlikely to block #14887 in any way.
comment:9 by , 6 years ago
bullfrog, please retest with a recent nightly. My changes to interrupt asserts and locking may prevent some deadlocks here.
comment:11 by , 4 years ago
Good day,
This issue I'm experiencing too on my Sony Laptop:
~> uname -a Haiku raven 1 hrev55018 Mar 26 2021 06:40:59 x86_64 x86_64 Haiku
Shutting down always stalls at the end with the screen showing the background color and the dialog window that tells users that all processes are being shut down, screen stays like that, and processor is still throttling. Then nothing happens and have to force shutdown.
Attached is listdev.
Any other test you need, let me know.
Regards,
RR
comment:13 by , 4 years ago
There might be several different issues here, First is application hanging, second is drivers locking upp and third failure to shutdown. I recommend disabling drivers and see if shutdown starts working.
If it is shutdown, it is most likely due to old ACPI versions required shutdown on boot CPU. This is probably bullfrog's case since it is an older HP. We did shutdown on boot CPU for some time, but due to another problem with CPU intercommuncation causing lockups randomly on all hw, we stopped that. I don't think there is a one solution fits all, so aim is to work on modern hw. If someone has time and energy to develop quirks for older machines it would be nice.
Most problems have been with apps or drivers though.
comment:14 by , 4 years ago
Here is shutdown code, git history should have old boot CPU example: https://github.com/haiku/haiku/blob/560961ee2a8044537147b4cebdbfd0de13ccaa58/src/system/kernel/arch/x86/arch_cpu.cpp#L133
Update: I found one more instance where this same type of thermal overload occurs in Haiku. Whenever I'm building within the Haiku tree (using jam), I get an identical type of system lockup, resulting in same thermal shutdown. This doesn't occur when building ports and such with build systems other than jam. Using -j4 or -j2 results in a lockup within a couple minutes. Using -j1 seems to delay it for about an hour, but does eventually occur. I'm not sure if that warrants a separate ticket.