Re: Can't load speedstep-centrino on IBM x336?

["Darrick J. Wong" <djwong@us.ibm.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3670 bytes --]

Venkatesh,

It turns out that RHEL4 wasn't calling the SMM to tell it that the OS
would handle the p-state transitions.  Thus, the status register trap
never got set up, which is why I kept reading 0xFFFF.  RHEL4 also
obliterates the value of PSTATE_CNT if the FADT revision is 1.0, so I
sent RH a backport of mainline's cpufreq, which only obliterates
PSTATE_CNT if acpi=strict and also makes that call to SMM.  With that
patch, DBS works great.

However, I am curious about the removal of the status register check in
acpi_cpufreq--how slow is reading that status register?  It seems to me
that it's a rather good idea to check that the operation actually
succeeded, instead of assuming that it does and changing the reported
clock speed as if it did, because any failures that happen will be
silent; we could only tell if the switch succeeded for sure by running
CPU benchmarks.  But, perhaps there's a justification for removing it
that I simply don't know about?

Anyway, thanks for your help with debugging this issue!

--Darrick

Pallipadi, Venkatesh wrote:
>  
> 
> 
>>-----Original Message-----
>>From: Darrick J. Wong [mailto:djwong@us.ibm.com] 
>>
>>Hmm... ok then, mainline is working.  Thanks for the data!
>>
>>Unfortunately, RHEL4 U2's "acpi" (it's based on 2.6.9) module doesn't
>>work--it prints the "Looking..." message and then "Transition failed."
>>when it doesn't find the value it's looking for (0x0E1E) and 
>>gets 0xFFFF
> 
> 
> When using SYSTEM_IO, The acpi driver does the IO call with proper
> parameters to change the frequency. BIOS then comes in and does the
> actual P-state transition in SMM mode (after the cordination across
> logical CPUs). After the transition, BIOS is supposed to export the
> result in another IO port, which OS tries to read and verify. This
> verification was removed in the latest base kernel, but is present in
> 2.6.9 (and RHEL4).
> 
> So, the problem here may be:
> 1) BIOS is not doing the transition. Hence when OS tries to verify by
> readon the status IO port, it sees the transition has failed.
> 2) BIOS is doing the transition, but not reflecting the status in status
> IO port or reporting some error there. Hence again OS fails to see the
> change.
> 3) Some other bug in the OS driver.
> 
> Having seen various bugs in different BIOSes related to this, and I am
> kind of confident that this also ia a bug in BIOS and not a OS issue.
> Can you please check with the BIOS folks on how exactly they are doing
> these transitions in SMM. You can also let me know if you need any more
> details about the driver itself.
> 
> Thanks,
> Venki 
> 
> 
>>instead.  Do you have any suggestions?  (If you're not familiar with
>>RHEL4, that's fine too.)
>>
>>--D
>>
>>Venkatesh Pallipadi wrote:
>>
>>>On Mon, Oct 24, 2005 at 11:18:19PM -0700, Darrick J. Wong wrote:
>>>
>>>
>>>>Ok, I tried acpi-cpufreq and tried to change the frequency 
> 
>>from 3.6GHz
> 
>>>>to 2.8.  scaling_cur_freq says I'm at 2800MHz, but 
>>
>>/proc/cpuinfo still
>>
>>>>says 3600.  In dmesg, I see "Writing 0x00000e1e to port 
>>
>>0x0800" at the
>>
>>>>very end of the log, but I don't see "Looking for 0x00000e1e 
> 
>>from port
> 
>>>>0x0804" like I think I should.  I don't see "Invalid port width..."
>>>>either--it's as if we fell out of the function.
>>>>
>>>
>>>
>>>If scaling_cur_freq shows you the right freq, then things 
>>
>>should be working.
>>
>>>We recently removed "Looking for * from port" in the common path.
>>>
>>>What /proc/cpuinfo shows kind of depends on other things. I 
>>
>>had this patch 
>>
>>>in my queue that fixes things with /proc/cpuinfo. This 
>>
>>should help here..
>>
>>>Thanks,
>>>Venki
>>
> 

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq