[Bug 14771] "ondemand" never raises frequency on an Intel Core2 Due (T9900) in a recent Dell E6500

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.kernel.org/show_bug.cgi?id=14771





--- Comment #19 from Thomas Renninger <trenn@xxxxxxx>  2010-06-25 11:00:06 ---
> Mike, I looked at the output of your acpidump.  It looks as if there is no
> "_PCT" section in your ACPI Bios
Robert: I expect you are on the wrong track.

Mike's acpidump does not include any cpufreq ACPI info because this the SSDT
tables are most likely loaded at runtime which acpidump cannot collect (e.g.
you do not see a _PSS func as well, but this info probably got retrieved
(compare with output of description), also the acpi-cpufreq would not load at
all in this case).

You can retrieve the missing tables by:
acpidump --addr 0xDF450957 --len 0x2C3 >IST0.dat
acpidump --addr 0xDF450C1A --len 0x1D7 >IST1.dat
acpidump --addr 0xDF450DF1 --len 0x5C6 >CST0.dat
acpidump --addr 0xDF4513B7 --len 0x8D >CST1.dat

iasl -d [IC]ST[01].dat
will then disassemble them.

You find that by:
grep -i load *
SSDT.dsl:                    Load (IST0, HI0)
SSDT.dsl:                    Load (CST0, HC0)
SSDT.dsl:                Load (CST1, HC1)
SSDT.dsl:                Load (IST1, HI1)
and looking up the address/length in the SSDT object in the SSDT, above load
params are pointing to:
Name (SSDT, Package (0x0C)
        {
            "BspIst  ", 
            0xDF450957, 
            0x000002C3, 
            "ApIst   ", 
            0xDF450C1A, 
            0x000001D7, 
            "BspCst  ", 
            0xDF450DF1, 
            0x000005C6, 
            "ApCst   ", 
            0xDF4513B7, 
            0x0000008D
        })

Eventually checking for shared_type reveals something. Intel processors could
show quite some nondeterministic behavior if it's HW_ALL (Jean Delvare showed
em some quite weird behavior where frequency followed cpufreq settings in
general (not like here), but individual cores where randomly set up or down).
A quick check would be whether, these differ:
/sys/devices/system/cpu/cpu0/cpufreq/{affected_cpus,related_cpus}
A more intrusive one is to check in the _PSD.
IMO it would be best to export the shared type readable to userspace, because
it's hard to retrieve and in HW_ALL case, current CPU frequency of cores could
be rather confusing and I expect it will cause some further grieve and bug
reports in the future. Eventually this could get exported by creating
/sys/../cpu0/cpufreq/shared_type which would only get filled by acpi-cpufreq.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux