Re: cpufreq longhaul locks up

[Rafał Bilski <rafalbilski@interia.pl>]

>> I found one line which wasn't were it should be. Probably this will not 
>> fix Your problem with powersave governor, but it is a bit related. 
>> Looks like Longhaul isn't skipping frequency transtition when it is asked 
>> to set f which is already set. Now after first transition it will not 
>> try to set same frequency again. Second part contains some magic 
>> because I don't have CN400 datasheet. It is NDA protected :-( Should 
>> print You one byte in hex and will try to set one register. I don't 
>> know if anything will change but it is worth testing.
> 
> Did not help unfortunately. The output the printk line generated was
>   longhaul: 0x0
> 
> (Strangely enough, %#02x with glibc outputs "00", not "0x0".
> And I would have expected "0x00". Subtleties of the kernel 
> printk/glibc?)
:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. 
Would be good to check if PLL really can go downto x4,0. Can You 
limit minimal CPU multiplier to 5,0 and check if is stable? If it 
is check 4,5.
Please send me below part of Your dmesg too:
CPU: After generic identify, caps: 0381b83f 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b93f 00000000 00000000 00000000 00000000 000000dd 00000000

"dd" is very important here.
> Jan
Rafał



----------------------------------------------------------------------
Kasia Cichopek eksponuje biust  
>>> http://link.interia.pl/f1a6f

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/