Thanks everyone, the explanation was pretty simple - the _CST package generated for model 6ex does not fit this exact CPU (6e8), as soon as stuff under CONFIG_ACPI_PROCESSOR has been loaded, system dies, sometimes with visible screen mess. Workaround for now is to use processor.nocst=1 and for Windows to use UP boot.
For now, I may simply disable the _CST entirely leaving only frequency scaling options, though this is far from being appropriate for the public port.
From git logs it looks like configuring the clockgen was needed for the
x60/t60 port for deeper c-states to work. I'd try to dump the clockgen configuration on smbus with block operations ('i2cdump #smbus 0x69 s') and configure it using block write operations either in romstage (look at thinkpad x201 romstage.c) or in ramstage like is done for the x60 (might need some tweaking).
Kind regards
From git logs it looks like configuring the clockgen was needed for the x60/t60 port for deeper c-states to work. I'd try to dump the clockgen configuration on smbus with block operations ('i2cdump #smbus 0x69 s') and configure it using block write operations either in romstage (look at thinkpad x201 romstage.c) or in ramstage like is done for the x60 (might need some tweaking).
I see, thanks. Previously write to i2c-0/0x69 has been stuck at romstage, so I kicked it out without looking at the log and therefore not getting reasons why is was there at first place, Now it is obvious that C3 is not working correctly without fixing up clock generator. Previously, also, I blamed incorrect _CST package generation from copy-paste from T60 for a moment - state descriptions has been enumerated as 0x1/0x2/0x2 while vendor BIOS has sequentially enumerated descriptions, still wondering what was the reason to do so.
-
Andrey Korolyov -
Arthur Heymans