Re: cpufreq est and Enhanced Sleep (Cx) States for Intel Core and above

Adam McDougall wrote:
> On Mon, Feb 12, 2007 at 10:53:24PM -0500, Stephane E. Potvin wrote:
> 
>   Adam McDougall wrote:
>   > On Wed, Dec 13, 2006 at 12:14:55PM -0500, Stephane E. Potvin wrote:
>   > 
>   >   Adam McDougall wrote:
>   >   >On Sat, Dec 09, 2006 at 07:29:23PM -0500, Adam McDougall wrote:
>   >   >
>   >   >  Another thing I wish could work is the Enhanced cpu Sleep States;
>   >   >  this Dell Latitude D820 laptop only sees C1 although the document
>   >   >  above indicates it should probably support 4 unique states.  Is 
>   >   >  there a way I can debug and/or fix this?  I can post dumps of the
>   >   >  acpi stuff and/or verbose boot logs if it would be helpful.  
>   >   >  
>   >   >  Thanks
>   >   >  _______________________________________________
>   >   >
>   >   >I am attaching my asl and dsdt acpi dumps incase someone knows for
>   >   >something to look for as for why it thinks I only have C1, unless 
>   >   >its related to the speed control problem above.  
>   >   >
>   >   Hi Adam,
>   >   
>   >   It's only finding the C1 state for various reasons that you'll find 
>   >   described in some details in the following email that I send to the acpi 
>   >   mailing list in June this year. The major reason being that the acpi cpu 
>   >   driver does not support well multiprocessor systems.
>   >   
>   >   http://docs.freebsd.org/cgi/getmsg.cgi?fetch=116103+0+archive/2006/freebsd-acpi/20060611.freebsd-acpi
>   >   
>   >   The email also included a patch to add support for multiprocessor 
>   >   systems to the acpi cpu driver. I've not updated the patch since then so 
>   >   it might or might not apply cleanly to a recent current.
>   >   
>   >   Steph
>   > 
>   > I didn't get around to trying that patch, but I have tried -current 
>   > after code was committed, including as late as Feb 11.  It seems to work,
>   > but if both of my cpus are allowed to enter C3 state, my laptop
>   > clock stops advancing (unless you are causing activity) and the performance
>   > gets very choppy, including mouse cursor halting for a second or two, etc.
>   > Typing or moving the mouse seems to nudge the system into crawling along,
>   > but if I leave it alone, timing loops stall.  I could do a while loop with
>   > a sleep on the command line and time just doesn't advance on its own, and
>   > the clock in Gnome would halt.  My laptop is using the Hpet timer, but it
>   > doesn't seem to make a difference if I use sysctl to try ACPI-fast or i8254.
>   >
>   
>   
>   Could you try the attached patch on your system? It adds a crude check
>   to make sure that the system is not sleeping for more than 1/hz secs.
>   The acpi_cpu driver should back off to a lower Cx state if it does.
>   
>   Steph
> 
> I just tried it, it did not print anything but actually the laptop got alot slower.
> The mouse pretty much stopped moving almost at all, and the computer itself was 
> practically completely unresponsive unless I gave the touchpad a workout. 
> 
> I tried with and without boot -v, wasn't sure if it was needed.
> 
> I also compiled my kernel with the default HZ before and after applying the patch,
> I remembered I had been using HZ=100.

Odd... The timer used to get the sleep time should not be affected by Cx 
state (it should be running as long as the system is in the run state). 
The detection logic for the long sleep could also be wrong. In either 
cases, I was not expecting the system to become more sluggish.

Could you please send me the hw.acpi.* and dev.cpu.* sysctl trees and 
your asl?

Steph