System is going down when compiling FreeBSD

Hi.

I have a copy of the "FreeBSD 9.1-RELEASE" SVN repository, and when I want to compile it with this command: make -j5 buildworld buildkernel my laptop is going down! My laptop is "Acer Aspire 5520" (CPU: AMD X2, RAM: 3GB DDR3). (Also my laptop is going down without using parallel jobs).
 
prp-e said:
An instant poweroff.

That's usually a result of an overheating CPU. It's the thermal protection that kicks in and shuts off the computer.
 
Ha ha! I can't change my laptop now, and I can't buy a new system. I need to use the same laptop for compiling FreeBSD. I guess kldunload apci can help me.
 
SirDice said:
That's usually a result of an overheating CPU. It's the thermal protection that kicks in and shuts off the computer.
I've experienced similar things (and heard of others with the same problem): when compiling something big (e.g. world or a large port) on my netbook sometimes the system just instantly cuts power.

In some cases disabling the console screensaver helped. Whether that was due to a bug in syscons(4) or due to the screensaver just pushing the temperature over the edge I do not know.

When syscons(4) is not a factor, perhaps it would help to whip up a script that monitors CPU temperature (make sure coretemp(4) is loaded (do # kldload coretemp if necessary) and then periodically do # sysctl -a | grep temperature) and suspends compilation processes for a while when the temperature gets beyond a certain treshold.
 
Ok. I'll test, and I hope that my laptop won't poweroff when I compile FreeBSD on it :).
 
You can force your CPU to run on a lower frequency by stopping powerd and setting sysctl dev.cpu.0.freq=<some frequency>. This would greatly reduce the temperature of your CPU while keep the compiler running.
 
Apart from all the valuable pieces of advice that have already been provided, you could also try compiling in single user mode. Not with just # shutdown now, which reverts the current session to single user mode, but to boot from it, like
Code:
# nextboot -o "-s" -k kernel
# reboot
After that you can follow the handbook's canonical way of rebuilding world. This will have minimal stress on your hardware. Also, when you build, try not using the -j flag. Instead, consider using devel/ccache to hasten the world building process. Details are in this how-to.
 
Sudden reboot when starting a CPU intensive job can also point to problems with current, such problems are related to overheating because more heat means more resistance on the wires leading to voltage dropping. Some laptops are not exactly designed to be used like desktop machines that continously run a task keeping the CPU 100% busy for extended periods and that might be the case here as well.
 
If the laptop is not very new, make sure you've tried to blow hard into the cooling output opening. Sometimes it evokes a significant cloud of dust from the cooling subsystem. :)
 
mav@ said:
If the laptop is not very new, make sure you've tried to blow hard into the cooling output opening. Sometimes it evokes a significant cloud of dust from the cooling subsystem. :)
I've cleaned my laptop's fan, and I use an external fan.
 
If the problem is overheating, take a look at the powerd man page. I have an Acer Aspire 4730Z, dual core Pentium laptop.

I have the following in /etc/rc.conf:
Code:
powerd_enable="YES"
powerd_flags="-a hiadaptive -b adaptive -M 1666"
This seems to keep it from overheating during upgrades of large ports.

I believe the value for "-M" should be selected from the output of sysctl dev.cpu.0.freq_levels. (Someone please correct me if that's not right). The output will be in pairs like: xxxx/yyyyy
Code:
dev.cpu.0.freq_levels: 2400/35000 2000/28000 1600/22000 1200/16000 800/14000
The -M value should be one of the xxxx values. Lower values decrease the likelihood of overheating. If I'd seen the above values, for example, I'd have tried setting it to 2000 first, then 1600, etc.
 
Have you established that it actually is the CPU overheating?

Could be some other hardware problem - I'd try to isolate and stress the CPU with something like stressprime or a distributed.netclient - something that will hammer the CPU and leave the rest of the machine mostly alone (small amount of RAM use and little disk use).

If the machine is fine running something like that, it may well NOT be your CPU overheating and causing the problem. It may be some other system component or a driver/firmware bug, etc.
 
My problem was solved by using sysctl dev.cpu.0.freq=1000, as fact, I turned 1900 (original frequency) to 1000. Of curse, It took 12 hours for compiling world and kernel.
 
Back
Top