http://bugzilla.kernel.org/show_bug.cgi?id=13389
Summary: Warning 'Invalid throttling state, reset' gets
displayed when it should not be
Product: ACPI
Version: 2.5
Kernel Version: 2.6.30-rc6
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: BIOS
AssignedTo: acpi_b...@kernel-bugs.osdl.org
ReportedBy: elen...@planet.nl
CC: len.br...@intel.com,
acpi-bugzilla@lists.sourceforge.net,
rui.zh...@intel.com, r...@sisk.pl,
maciej.rute...@gmail.com, yakui.z...@intel.com,
theholyet...@googlemail.com
Regression: Yes
Created an attachment (id=21559)
--> (http://bugzilla.kernel.org/attachment.cgi?id=21559)
Dubug patch and debug output
As suggested by Rafael Wysocki I'm filing a new bug to track the possible
regression introduced in 2.6.30-rc6 with commit 4973b22a: 'ACPI processor:
reset the throttling state once it's invalid'.
The prior discussion about this can be found starting at comment #23 of
http://bugzilla.kernel.org/show_bug.cgi?id=13259, the BR that resulted in the
patch to be added. I've added the same people in CC.
Attached a debug patch and the resulting output. This shows a few things.
1) The value of pr->throttling.state after boot is 100% correct for my system
and proc is able to show correct state because of that.
2) The "invalid state" returned by acpi_throttling_rdmsr() is 2, which indeed
does not match any of the values of tx->control. However, it also does not seem
like a completely random value.
3) The reset that is being done when the warning triggers is bogus for my case
because in acpi_processor_set_throttling_ptc() it is ignored due to the
following test:
if (state == pr->throttling.state)
return 0;
4) After the status _is_ set by really changing the state, the value returned
by acpi_throttling_rdmsr() does start to match tx->control.
Questions:
- Does the ACPI spec actually demand that the value read through
acpi_throttling_rdmsr() should be "correct" after system boot?
- Given that in my case all other data is consistent, is it really the right
thing to do to test that value against tx->control at that point?
Conclusions:
- Even if the value returned from acpi_throttling_rdmsr() is wrong, the
inconsistency seems minor enough that the kernel should just ignore it.
- My case is fundamentally different from the original BR: while for the broken
case the reset _does_ fix a problem, for my system the reset is bogus (even
structurally broken?) because it does not get recognized as a status change and
thus is skipped.
If additional debugging info is needed, please feel free to ask.
Cheers,
FJP
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
