Hard hang with powerd

Maxim Maximov mcsi at mcsi.pp.ru
Wed Sep 28 12:34:17 PDT 2005


Nate Lawson wrote:
> Maxim Maximov wrote:
> 
>> Bruno Ducrot wrote:
>>
>>> On Tue, Sep 20, 2005 at 06:04:40PM +0400, Maxim Maximov wrote:
>>>
>>>> Bruno Ducrot wrote:
>>>>
>>>>> The 2 logical CPUs need to set the same MSRs at the same time,
>>>>> but if the second one is forced to be idle, I'm not sure if p4tcc will
>>>>> work fine.
>>>>>
>>>>> Therefore, I'm wondering if this hard hang happens with a SMP kernel
>>>>> and hyperthreading is enabled, or if this happens with a UP kernel.
>>>>
>>>>
>>>> Yes, kernel is SMP one.
>>>>
>>>> # sysctl machdep.hyperthreading_allowed
>>>> machdep.hyperthreading_allowed: 1
>>>>
>>>
>>> It's weird.  Could you please try with a kernel without SMP for
>>> testing purpose?
>>>
>>
>> It's fine. Now I'm running UP kernel with 'powerd -v'
> 
> 
> Maxim, can you try some debugging things to figure out where the hang is 
> happening?  First, add printfs of 1, 2, 3, 4, etc. throughout 
> sys/i386/cpufreq/p4tcc.c in p4tcc_set().  Then recompile the SMP kernel 
> and boot single user (to save an fsck) and change some settings via 
> sysctl dev.cpu.0.freq=xxx until you can get a hang.  See what numbers 
> were printed and where it hung.  It should go through all the numbers 
> twice when there is no hang since we set a value on cpu0 and cpu1.

I did that. I seeded printfs from 1 to 7 throughout the function.

OS dies when making these steps:

1. 751 -> 375
2. 748 -> 374
(from boot to boot, freq numbers always differ on my notebook)

In the first case numbers printed were: 1234567. However, in the second 
hang the numbers printed were: 12345671234567.

> 
> Also, see if you can break to the debugger (ctrl-alt-esc) from console 
> when it is hung.  I'm guessing no.

You're right.

-- 
Maxim Maximov


More information about the freebsd-acpi mailing list