Update: I changed the topic title to more accurately portray the issue. I’ve also deleted misleading comments that were based on initial assumptions.
I have a similar issue, but with a ten years old Compaq laptop. In the Process Controller Deskbar replicant, you have the following settings:
- Low latency / energy saver.
Switching to “energy saver” apparently halps (at least in my case).
1 Like
Ok. I left it jam away @ -j1 (and with ProcessController’s Power saving on) while I slept last night. I awoke to the laptop off and the thermal shutdown message at boot. Jam made lots of progress in the build, but I’m still experiencing this.
I should try building some ports without jam to double check to make sure this is a jam issue.
I’m considering renaming this topic: Haiku is too fast for my computer. Please tone it down a bit please. 
If you enter in the BIOS setup, there are an option like “fan always on” or something like that?
I guess that some laptops had their fans controlled by software. Problably Haiku lacks this kind of driver.
Yes. That has been set the whole time. My fan throttles according to CPU load, even in Haiku. Testing with Power saving doesn’t seem to matter. I tried it with -j4 and it still overheats within a minute or two.
Well, that jam uses your CPU to the max is a feature, not a bug. That your hardware can’t handle that is to blame on the manufacturer setting a CPU speed higher than reasonable for their design, or maybe on lack of cleaning of the vents, fans, etc, and replacing thermal paste to keep the cooling system working.
There isn’t much we can do if using the CPU at 100% ends up overheating the machine. Blame the hardware for not being designed for that.
This even occurs with -j1. So it isn’t just at 100% load. And only occurs in jam. Other build systems don’t have this issue, even when using -j4, such as with haikuporter, scons, etc.
Perhaps some hardware maintenance on my end is in order. It just seems weird that other high CPU usage tasks don’t produce this. This lock up is similar to the one I reported with shutdown. It seems the thermal overload occurs during the lock up, and isn’t causing the lockup. I initially thought it was thermal overload causing this, but further testing is proving otherwise. Refer to #14718 (System freezes on shutdown, but reboot works fine.) – Haiku
Tested again today. From a cold boot up, I opened a terminal and ran jam -j1 from the base of the the haiku tree to pick up where it left off after the last lockup. Temperatures remained low to normal for about 20 minutes until it locks up, then the build locks up, GUI locks up, fan kicks in high, and then temperatures rapidly rise. It isn’t jam causing the overheat as I initially assumed. The lockup is causing the overheat. Running full speed just makes it occur quicker. It is not any particular point in the build. I can reboot and it will continue where it left off, then it will lock up again later in the build. This does not happen when using other build systems on the same install.
I’ve had my machines run hot before, but not overheat (unless I’ve blocked the vents). Are the vents clear all the way through? Sometimes the outer vents can be clear, but the gap in between the CPU and the heat sink can get fine dust in there. An EliteBook 8440 I used to have ran hot; I brushed and sucked out the dust, and it ran easily 10-15 C cooler than before.
Also, is the heat sink on properly? If the laptop is old, definitely re-tighten it. And also is the thermal paste good? Also definitely be sure you’ve got ample memory and a large enough processor cache to do a compile.
On the software side, maybe try doing -j5 and see how this works. In any case, hope that something fixes this. Don’t cook your machine too much; I lost one of my best machines that way. Seriously.
It does it only building with Haiku’s build system. Even with -j1. I can build in the ports tree all day long at full throttle on -j4. It actually doesn’t get hot until it locks up. This and one other lock up in haiku are the only time it ever overheats. See the link to the trac ticket above in my reply to PulkoMandy. It has 8gb ram. Not sure what the cache is, but I’m sure it’s plenty. It’s also got a secondary cooling fan pad that it lives on. In any case, I’m in the middle of a tear down and cleaning in prep for keyboard replacement. I’ll make sure it isn’t plugged up and also clean and regrease the CPU and heatsink while I’m at it. This thing rocks. My friend was about to throw this HP pavilion G6 in the trash because some keys don’t work. AMD quad-core. I hope this fixes it.
Repaste the CPU…cheap oem thermal paste goes bad. Use Arctic MX4 is nearly foolproof just a pea sized drop. It’s carbon based, doesn’t go bad for 7+ years or so supposedly and is non conductive so if you get messy accidentally just clean it up no worries about shorting anything with silver compounds.
dealt with this the other day at work, had a laptop fan going full blast and the cpu was stuck at 800Mhz… 
Probably Haiku ports doesnt’ crash as it runs configure scripts between doing actual work… then does a few min at most of compiling then back to configure scripts which are slow… not very cpu intensive.
I’ve got some thermaltake grease laying around that’s fairly fresh. I’m going to use that. Is hasn’t let me down yet. Does building with autoconf, scons, etc have the same rest period that haiku porter has? I don’t always work with recipes. The behavior of the crash is actually similar to a different crash that I’m experiencing. Both seem to have the crash coming first, then overheating due to the crash.
1 Like
Ohh… the Pavilion G6. Those and the Vista/7 era notebooks around that time, like the dv6, weren’t the best machines, imho. Shut downs and power issues did happen due to heat problems; later designs fixed it. I had a friend that had a dv6 with that problem, and I had a G6 once myself (I use Mac, but also use HP for Haiku & Gnu/Linux).
I have two issues so far with lock ups. One happens upon system shutdown (only shutdown, not reboot) only in Haiku. The other is building Haiku, only in Haiku. In both cases the lockup happens first before I get a rise to dangerous temps. I’ll report more after the clean out and regrease. But I don’t think that will solve either issue. Before I do that, I’m going to build haiku in Linux to see if it is reproducible there.
This may be a KDL then, as there is no cpuidle in KDL and so fans spin up pretty quickly. Try using VESA; it could be the KDL is just not displaying properly. (Or if it’s an app_server hang or something else, try dropping into KDL using the keyboard shortcut – Alt+PrntScrn+D – and then take a picture of the last page of output of the “syslog” command from there.)
1 Like
Last night, I tried building Haiku on Linux, same machine. Jam -j4 worked fine there. Build exited “normally” after a couple hours with a build error, but no lock up.
As far as I can tell, I’m using VESA. Preferences->Screen reports as such. I tried under several VESA resolutions. It’s a total UI lock. No keyboard response. Alt-Prntscn-d does nothing. I even tried typing ‘reboot’ at it to see if perhaps it was a non-displayed kdl. Still nothing, just a total lock.
OK. Try using Alt+PrintScrn+D before the lockup and see if it works at all; it may not, and then of course it won’t work during the lockup either. (You may need to press it multiple times for it to work.) But if it does, then it not working during the lockup is indicative of a larger problem.
Try doing a hard reboot by pressing the button on your machine and then using the bootloader to view/save the syslog from the previous session. This may show whatever the problem is.
1 Like
I’ll try that. Alt-Prntscn-d works normally, just not during these lockups.
I’ll record a few syslogs via bootloader. The more I test, I’ve started getting several thermal shutdowns during jam -4 (instant power off with message on reboot.) This is still only in Haiku. Also, -j2 and -j1 still produce the normal lockup.
It’s definitely time a for clean and repaste in the cooling system. I’m still convinced this isn’t 100% of the problem as it doesn’t happen in Linux, and can be reproduced using -j1 and -j2.
So, I’ll do a bit more testing and recording the syslogs, then do my hardware maintenance, then some more testing and recording syslogs.
I’m not seeing any options in the bootloader [shift] menu for this. Is it the “Display current boot loader log”? Enable debug syslog is already active. What am I missing?
Yes, it’s “Display current boot loader log.”