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