https://bugzilla.kernel.org/show_bug.cgi?id=10561
Len Brown <l...@kernel.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |l...@kernel.org
Summary|Funky HPET + processor.ko + |p4_clockmod: repeated
|p4_clockmod.ko = repeated |lockups - classmate PC
|lockups - classmate PC |
--- Comment #18 from Len Brown <l...@kernel.org> 2011-01-18 05:58:29 ---
re: comment #9
> You mean "option processor max_cstate=1" (the other notation is for builtins).
> When probing processor I got a message about it being limited to max C-state
> 1.
> It also caused the time/tsc problem (below) to go away so I got no "tsc
> unstable" message and it didn't lock up.
> However, unlike booting with hpet=disable, in this case it kept using tsc,
> rather than use acpi_pm.
> If I'm not mistaken, it also means the processor can't sleep... so it's not
> very power-efficient.
Actually this is probably fine. It will give you C1E,
which is likely 90+ % of the value of C2, and it will
not disable the use of the TSC as a timesource.
I'd be interested if you can detect a battery life
difference between booting with max_cstate=1 and without.
But this business of the HPET and the TSC is not directly
related to the actual failure, as in comment #13 you stated
that this can happen when using acpi_pm as the clocksource,
eliminating HPET and TSC from the picture. The problem is
with p4_clockmod.
I'd be interested if you can measure any benefit from using
p4_clockmod. My recommendation would be to simply not use it.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
