Information regarding C3 cpu state and bus mastering activity

Information regarding C3 cpu state and bus mastering activity

[Marco Calviani]

Hi acpi-devel list,
   I have a problem regarding C3 states and usb. When i'm plugging in any
usb devices, the my busmaster activity starts couting preventing the
cpu to go to C3 state. Obviously if i unload all usb-related modules,
C3 state goes in, my battery lives longer and the laptop stays quiter;
unfortunately i need an usb-mouse (and possibly also an external USB drive.
I've read somewhere that this is a specific ACPI standard behaviuor
but i'm asking if this can be modified in some way, i.d. is it
possible, with some workarounds, to enter C3 state also with the usb
modules?

PS: i'm using a Travelmate 8005 laptop with a 1.8GHz dothan centrino
and debian sid. i'm running kernel 2.6.12.6

Thank you very much for your interest,
Marco Calviani


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Janosch Machowinski]

Marco Calviani wrote:
> Hi acpi-devel list,
>    I have a problem regarding C3 states and usb. When i'm plugging in any
> usb devices, the my busmaster activity starts couting preventing the
> cpu to go to C3 state. Obviously if i unload all usb-related modules,
> C3 state goes in, my battery lives longer and the laptop stays quiter;
> unfortunately i need an usb-mouse (and possibly also an external USB drive.
> I've read somewhere that this is a specific ACPI standard behaviuor
> but i'm asking if this can be modified in some way, i.d. is it
> possible, with some workarounds, to enter C3 state also with the usb
> modules?
No this is not Possibe. In C3 the processor disables his cache. If you 
have busmaster activity, there are direct writes into the cache (if I 
remeber right). So if you allow C3 and Busmaster, you will get into some 
serious truble and loose data.
> 
> PS: i'm using a Travelmate 8005 laptop with a 1.8GHz dothan centrino
> and debian sid. i'm running kernel 2.6.12.6
> 
> Thank you very much for your interest,
> Marco Calviani
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id\x16865&opÌk
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Phillip Susi]

I'm kind of confused as to why this is a problem myself.  Yes, the CPU 
cache does not snoop the busmaster activity and so the cache can become 
out of sync with ram, but isn't it the job of the driver that initiates 
the dma transfer to invalidate those cache lines once the transfer is 
complete to bring the cache back into sync?

Janosch Machowinski wrote:
> 
> No this is not Possibe. In C3 the processor disables his cache. If you 
> have busmaster activity, there are direct writes into the cache (if I 
> remeber right). So if you allow C3 and Busmaster, you will get into some 
> serious truble and loose data.
> 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Marco Calviani]

Hi list,

2005/12/12, Janosch Machowinski <scotch-cGBD8117FJM@public.gmane.org>:

> No this is not Possibe. In C3 the processor disables his cache. If you
> have busmaster activity, there are direct writes into the cache (if I
> remeber right). So if you allow C3 and Busmaster, you will get into some
> serious truble and loose data.

Is this an hardware limitation or a software one?
If i understood well this occur because the active bus polling that is
required to maintain communication with usb devices deny the CPU from
switching to C3, and even if there are no usb device connected but the
modules are loaded the polling prevent the switch.
Will it be possible to increase the polling time, so that maybe the
CPU can enter that state?

Regards,
Marco Calviani


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Janosch Machowinski]

Phillip Susi wrote:
> I'm kind of confused as to why this is a problem myself.  Yes, the CPU 
> cache does not snoop the busmaster activity and so the cache can become 
> out of sync with ram, but isn't it the job of the driver that initiates 
> the dma transfer to invalidate those cache lines once the transfer is 
> complete to bring the cache back into sync?

Normally a cache should be completely hidden from the system, so a 
driver can never determine the actually state of the cache. Only way to 
sync the cache is to completely flush it.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Janosch Machowinski]

Marco Calviani wrote:
> Is this an hardware limitation or a software one?
> If i understood well this occur because the active bus polling that is
> required to maintain communication with usb devices deny the CPU from
> switching to C3, and even if there are no usb device connected but the
> modules are loaded the polling prevent the switch.
> Will it be possible to increase the polling time, so that maybe the
> CPU can enter that state?
> 
Okay, I read through this stuff once again. I would say, that busmaster 
activity is a direct write into memory. While the processor is in C3, it 
can not keep it's cache in sync with the memory. So there are two 
solutions to this problem for uniprocessor systems:
1. Either you flush the cache before entering C3. This takes a relative 
long period of time (according to ACPI 3.0 spec) so it should not be the 
prefered method.
2. Disable the busmaster. The kernel looks at the current busmaster 
activity and then chooses if it wants to disable busmaster and enter C3.

After reading through the spec again, I would revoke my first comment 
and say that with a bit of policytuning you could enter C3 even with a 
USB mouse plugged in.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Marco Calviani]

Hi Janosh,
  first of all thanks for your interest in this issue

> Okay, I read through this stuff once again. I would say, that busmaster
> activity is a direct write into memory. While the processor is in C3, it
> can not keep it's cache in sync with the memory. So there are two
> solutions to this problem for uniprocessor systems:
> 1. Either you flush the cache before entering C3. This takes a relative
> long period of time (according to ACPI 3.0 spec) so it should not be the
> prefered method.
> 2. Disable the busmaster. The kernel looks at the current busmaster
> activity and then chooses if it wants to disable busmaster and enter C3.

What are the possible consequences of disabling the busmaster? Does
this affects also other box component (i.d. i've read somewhere that
the busmaster is related to DMA access)?

And how is it possible to do so?



Many thanks in advance,
Marco Calviani


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Phillip Susi]

Caching is never _completely_ hidden from the kernel.  I am not as 
familiar with the internals of the linux kernel as I am with NT, but I 
imagine it would have to be similar.  On NT drivers issuing hardware DMA 
transfers must call functions in the HAL to facilitate the process.  On 
Intel platforms, the hardware generally maintains cache coherency across 
multiple processors and bus masters, but this is not true on all 
platforms.  Many non Intel platforms' caches do not support bus snooping 
( as indeed, there may not even BE a bus that is shared between all 
processors and bus masters and memory modules ) so it is up to the HAL 
functions to make sure the caches stay coherent by flushing the pages 
being written to the device prior to the DMA starting, and invalidating 
the pages being read after the DMA completes.


Seeing as how Linux is supported on an even wider range of even more 
exotic systems ( think NUMA ), I have to believe that it has similar 
features.  Maybe it is just that the implementations of these support 
functions on Intel platforms is defined to be a NOOP because it is 
assumed that the hardware will always maintain coherency, but it seems 
there is at least one time where this is not the case ( entering C3 ).

If this code is just disabled on Intel platforms, maybe it could be 
reworked so that it maintains a list of all DMA transactions that are 
currently in progress, then before entering C3, all the pages involved 
in DMA writes would be flushed, and when exiting from C3, all the pages 
involved in DMA reads would be invalidated.

It sounds like you were talking about flushing and invalidating the 
ENTIRE cache when entering/exiting from C3.  That would slow things down 
quite a bit, but doing it only to the pages that are actually involved 
in active DMA transfers should be fine.


Janosch Machowinski wrote:
> 
> Normally a cache should be completely hidden from the system, so a 
> driver can never determine the actually state of the cache. Only way to 
> sync the cache is to completely flush it.
> 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Marco Calviani]

Hi again,

> 2. Disable the busmaster. The kernel looks at the current busmaster
> activity and then chooses if it wants to disable busmaster and enter C3.

Maybe i'm completely out of target but what about, as said here by
Nate Lawson http://lists.freebsd.org/pipermail/freebsd-acpi/2004-November/000835.html
, to "power down the USB host controller when idle"?

Regards,
Marco Calviani


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[phutchis-CWA4WttNNZF54TAoqtyWWQ]

> Maybe i'm completely out of target but what about, as said here by
> Nate Lawson http://lists.freebsd.org/pipermail/freebsd-acpi/2004-November/000835.html
> , to "power down the USB host controller when idle"?

Might be OK, provided the USB host controller *can* be powered down
*and* we won't need to wake up due to someone touching the USB mouse
or keyboard :)


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Pavel Machek]

On Ne 11-12-05 21:10:53, Marco Calviani wrote:
> Hi acpi-devel list,
>    I have a problem regarding C3 states and usb. When i'm plugging in any
> usb devices, the my busmaster activity starts couting preventing the
> cpu to go to C3 state. Obviously if i unload all usb-related modules,
> C3 state goes in, my battery lives longer and the laptop stays quiter;
> unfortunately i need an usb-mouse (and possibly also an external USB drive.
> I've read somewhere that this is a specific ACPI standard behaviuor
> but i'm asking if this can be modified in some way, i.d. is it
> possible, with some workarounds, to enter C3 state also with the usb
> modules?

Fix USB to send mouse into runtime-sleep state. That will allow C3 to
be used as long as you are not actively moving the mouse.
								Pavel
-- 
Thanks, Sharp!


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Marco Calviani]

Hi list,

2005/12/13, phutchis-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org <phutchis-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>:

> Might be OK, provided the USB host controller *can* be powered down
> *and* we won't need to wake up due to someone touching the USB mouse
> or keyboard :)

Well, in my case the keyboard is not the problem since i'm running a laptop....
Do you know how is possible to power down the usb controller?

I was googling on this problem and i've found a page from Microsoft
support center that describe the same problem (for W2K and ME) on that
OS  http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q297045&
They provide this "solution" (as i anticipated some mails ago): "To
resolve this problem, increase the USB polling interval from one ms to
five ms. Then, the processor can enter a C3 power-saving state during
its inactivity and extend the battery life of the computer. To
increase this polling interval, add a registry entry that is dependent
upon the operating system"

Any hint on how to implement this, and do you think that this can
provide some help?

Best regards,
Marco Calviani


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Information regarding C3 cpu state and bus mastering activity

[Erik Slagter]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

On Tue, 2005-12-13 at 15:06 +0100, Pavel Machek wrote:
> On Ne 11-12-05 21:10:53, Marco Calviani wrote:
> > Hi acpi-devel list,
> >    I have a problem regarding C3 states and usb. When i'm plugging in any
> > usb devices, the my busmaster activity starts couting preventing the
> > cpu to go to C3 state. Obviously if i unload all usb-related modules,
> > C3 state goes in, my battery lives longer and the laptop stays quiter;
> > unfortunately i need an usb-mouse (and possibly also an external USB drive.
> > I've read somewhere that this is a specific ACPI standard behaviuor
> > but i'm asking if this can be modified in some way, i.d. is it
> > possible, with some workarounds, to enter C3 state also with the usb
> > modules?
> 
> Fix USB to send mouse into runtime-sleep state. That will allow C3 to
> be used as long as you are not actively moving the mouse.

Weird. I have a usb mouse (amongst others) connected and I have this:

active state:            C4
max_cstate:              C8
bus master activity:     10180000
states:
    C1:                  type[C1] promotion[C2] demotion[--] latency[001] usage[00000010]
    C2:                  type[C2] promotion[C3] demotion[C1] latency[001] usage[145683351]
    C3:                  type[C3] promotion[C4] demotion[C2] latency[085] usage[31777840]
   *C4:                  type[C3] promotion[--] demotion[C3] latency[185] usage[66550298]

So, is this phenomenon specific to a certain hardware layout?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]

Re: Information regarding C3 cpu state and bus mastering activity

[Marco Calviani]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

Hi Pavel and list,


> Fix USB to send mouse into runtime-sleep state. That will allow C3 to
> be used as long as you are not actively moving the mouse.
>                                                                 Pavel



thanks for this hint: however i'm not an acpi neither an usb driver
programmer. Could you provide me, as far as you know, any suggestion on how
to implement this fix you are indicating me?

Best regards,
Marco Calviani

[-- Attachment #2: Type: text/html, Size: 970 bytes --]