Menu
▾
▴
acpi-devel
|
From: Marco C. <mar...@gm...> - 2005-12-11 20:10:57
|
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 |
|
From: Janosch M. <sc...@tz...> - 2005-12-12 00:33:16
|
Marco Calviani wrote: > Hi acpi-devel list, > I have a problem regarding C3 states and usb. When i'm plugging in a= ny > 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 dr= ive. > 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=20 have busmaster activity, there are direct writes into the cache (if I=20 remeber right). So if you allow C3 and Busmaster, you will get into some=20 serious truble and loose data. >=20 > 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 >=20 > Thank you very much for your interest, > Marco Calviani >=20 >=20 > ------------------------------------------------------- > 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=16865&op=CCk > _______________________________________________ > Acpi-devel mailing list > Acp...@li... > https://lists.sourceforge.net/lists/listinfo/acpi-devel |
|
From: Phillip S. <ps...@cf...> - 2005-12-12 03:42:22
|
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. > |
|
From: Janosch M. <sc...@tz...> - 2005-12-12 12:47:43
|
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. |
|
From: Phillip S. <ps...@cf...> - 2005-12-12 16:07:28
|
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. > |
|
From: Marco C. <mar...@gm...> - 2005-12-12 09:22:13
|
Hi list, 2005/12/12, Janosch Machowinski <sc...@tz...>: > 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 |
|
From: Janosch M. <sc...@tz...> - 2005-12-12 12:51:55
|
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. |
|
From: Marco C. <mar...@gm...> - 2005-12-12 16:02:52
|
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 |
|
From: Marco C. <mar...@gm...> - 2005-12-12 16:10:48
|
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/0= 00835.html , to "power down the USB host controller when idle"? Regards, Marco Calviani |
|
From: <phu...@wi...> - 2005-12-13 02:08:23
|
> 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 :) |
|
From: Marco C. <mar...@gm...> - 2005-12-13 20:55:06
|
Hi list, 2005/12/13, phu...@wi... <phu...@wi...>: > 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=3DKB;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 |
|
From: Pavel M. <pa...@uc...> - 2005-12-14 11:43:48
|
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! |
|
From: Erik S. <er...@sl...> - 2005-12-14 11:58:35
Attachments:
smime.p7s
|
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 a=
ny
> > 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 dr=
ive.
> > 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?
>=20
> 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] u=
sage[00000010]
C2: type[C2] promotion[C3] demotion[C1] latency[001] u=
sage[145683351]
C3: type[C3] promotion[C4] demotion[C2] latency[085] u=
sage[31777840]
*C4: type[C3] promotion[--] demotion[C3] latency[185] u=
sage[66550298]
So, is this phenomenon specific to a certain hardware layout?
|
|
From: Marco C. <mar...@gm...> - 2005-12-14 21:29:09
|
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 |
Thanks for helping keep SourceForge clean.
X