I noticed my XPress200M is doing 120 wakeups/s on my laptop. I'm using XOrg 7.3/1.4.1~git20071119, radeon 6.7.196 and Mesa 7.1~20070824. DRI and Composite are enabled (but Xorg is the only client according to /dev/dri/card0). The kernel is 184.108.40.206 and I'm not using dual-heal, only the laptop's panel. However, I do have several devices defined in xorg.conf (since I used to have a CRT), but only the panel is referenced in the current screen layout "Single LVDS" (see attached).
I just found out that xrandr reported VGA-0 on unknown connector. I used xrandr to disable it and the wakeups went down to 0. Which allowed the CPU to reach state C3. Then I set it back to auto and the wakeup count went again up to 60. I set it back off, but it stayed in 60 and the CPU doesn't reach state C3 anymore. This seems buggy. Also, I have nothing plugged to VGA-0, so it should be off by default, right?
XPRESS support is generally buggy as it was added by trial and error. Hopefully that will change soon. In any case, please attach your xorg log, config, and xrandr output.
Created attachment 13050 [details]
XRandr output before --off/after --auto
Created attachment 13051 [details]
XRandr output after --off
Created attachment 13052 [details]
Created attachment 13053 [details]
Created attachment 13058 [details]
Simplified X.org configuration
Created attachment 13059 [details]
X.org log for simplified configuration
I found out that when X is restarted I get no interrupts from the card and 3D works alright. However, it goes up to 120 as soon as I switch back and forth from the Linux (text) console, so I guess switching to the console is what triggers this problem.
I tried turning off DynamycClocks to no avail. I also tried enabling framebuffer on the console, but radeonfb caused so much trouble (crashes, frozen computer, garbage on the screet, etc.) that I didn't even get to test if it helped the issue.
Also, I can't seem to get the interrupt back to 60Hz ―it's either 0 or 120 now― so that apparently was just another buggy case.
*** This bug has been marked as a duplicate of bug 13610 ***