Kernel Bug Tracker – Bug 6689
AGP bus mastering inhibiting CPU power saving states???
Last modified: 2007-12-30 22:11:17 UTC
Most recent kernel where this bug did not occur:
Hardware Environment: Thinkpad X31
Software Environment: Debian Unstable, Kernel 2.6.16
More a question, maybe a bug:
I have noticed that loading the radeon dri module in xorg prevents the CPU from
entering C3 power saving state. I filed a bug report (see
The developer Michel D
This is a chipset question. What chipset does the X31 have?
Got lspci -vv output?
Created attachment 8313 [details]
lspci -vv output
Do you need any more info?
Created attachment 8314 [details]
lspci -vv output (corrected)
Correction (the last output did not include all infos as it was done as user)
can you try loading the radeon module with no_wb=1 before starting X, and seeing
do you still get C3 inhibited?
not sure if that is in 2.6.16, but 2.6.17 has it.
I have done that without success. See
What about the question if AGP bus mastering should have an effect on CPU power
saving states at all? If Michel is right, AGP bus mastering shouldn't stop the
CPU from entering power saving states at all. Is that correct?
So, does nobody really know the answer to this question or is it just lacking
I know that power saving is not really a high priority at the moment, but still
it's awful to see that you get 4-5 h battery time when running under windows but
only 2-3 hours under linux on many laptop systems.
Sure, entering C3 is just one of many power saving components but it does add
its part to it. So an answer to the question, whether C3 should be inhibited by
AGP bus mastering or not would be quite useful. (at least it makes a change from
ca. 2h15m to 2h45m on my setup, which is not negligble)
Any input to this?
See my posting on freedesktop.org bugzilla entry above. I suspect that the power increase is due to radeon (and other DRI modules) generating vertical blanking interrupts constantly even when nobody cares about receiving them.
Any update from your side? This area no longer suffers no interest... Has the problem been resolved for you?
thanks for asking.
Actually, nothing has changed. But we all know that linux is not really outstanding in power saving issues. In this respect, this is just one of the underlying problems. And all of these are very difficult to resolve.
Furthermore, I guess, there aren't very many users of an ATI radeon r100 left nowadays. There are also more bugs in the driver that remain unsolved (e.g. http://bugzilla.kernel.org/show_bug.cgi?id=6626 ).
I'm for myself simply living with that now and may decide to buy a new laptop one or another day (then with a different graphics chip).
P.S.: Last kernel tested was 2.6.21. I will update to 2.6.23 in the near future. If anything changes I will report (but I don't expect it).
Please paste the contents of /proc/acpi/processor/*/power
for the 3D and non-3D cases. Best if you can make them
under similar scenarios -- such as shortly after reboot into that config.
The "bus master activity" bitmask will tell us if the
chipset is telling the OS about bus master activity.
What do you see in /proc/interrupts for the 3D vs non-3D cases?
does the rate of interrupts for a device go up for 3D?
Perhaps you can run powertop to identify the C-state residency
and the interrupt sources and rates?
The HW guys filled me in on this one...
Yes, theoretically it is possible to do non-snooped AGP/memory transactions
while in C3 w/o waking the processor. However, the processor+chipset
at hand does not distinguish between snooped and non-snooped AGP
transactions for the purpose of notifying the processor of AGP activity.
So any AGP/memory activity will indeed keep the processor out of C3.
The HW guys expressed surprise that just loading the driver
caused constant activity that disables C3. To me this suggests
that there may be room for software optimization to reduce
activity, increase C3 residency, and save power.
I think the ACPI C3 question is answered, so this bug is closed.
You may want to take up this issue with the graphics folks
to see if they can optimize their software for power.