Re: kern.hz=1000 causes random poweroff on laptop

Hi,
I don't think this is overheating either because it will generally lock 
up within a minute or so, but perhaps it is possible that some part gets 
to hot in that time frame. If so it is not something acpi is monitoring 
because it reports temperatures substantially lower than the PSV limit. 
Below is what acpi reports at 100 hz and idle:

hw.acpi.thermal.tz0.temperature: 46.9C
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.passive_cooling: 1
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: 79.9C
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 94.9C


I can leave the machine at the boot prompt without any problems for a 
long time (I know that does not put much stress on the machine :-)), but 
within 30-60 seconds of getting to a single user shell prompt, it is 
dead as a duck at hz=1000.

Is is possible that it is a power converter issue, where the higher 
frequency requires enough current to make the converter start going 
belly up?

Also with older kernels, it seems they sometime fails in a similar 
fashion (hz=100), when I have a cardbus card (not a pcmcia) active. In 
these scenarios though, the machine has typically been running for hours 
or days, so it might have been something completely different.

I have for a long time suspected that the deep irq chain for irq9, might 
have had something to do with these types of problems. On this machine 
you have :
<cbb_intr>
<fxp_intr>
<uhci_intr>
<nm_intr>
<InterruptWrapper>
<intpm_intr>

This list is is from a trace I did a couple of years ago, so the names 
might be different, but the depth of the chain hasn't changed.

Lars

Sam Leffler wrote:
> Dag-Erling Smørgrav wrote:
>> Lars Fredriksen <lars_at_odin-corporation.com> writes:
>>> I have a laptop sony z505rx, that if booted with kern.hz as 1000, 
>>> will power off within a minute or two of booting.
>>
>> sounds like overheating.
>
> I've noticed on several of my laptops that they run way hotter with 
> freebsd than other systems (linux, windows).  Most are newer models 
> that have either acpi issues or lack speedstep support.  But I suspect 
> there's something else going on in the basic system.  I find it hard 
> to believe the clock rate is the cause of this extra work but haven't 
> dug into it (I hoped judicious use of hwpmc would pinpoint what's 
> going on).
>
>     Sam
>
> !DSPAM:444a7550956491607598332!
>
>