On Thu, 2008-08-28 at 14:24 +0100, Johannes Engel wrote:
> Hi guys,
> since I do not quite know who is the culprit for that problem, I want to
> ask here first before filing a bug report. Maybe one of you has got an
> idea how to deal with that.
> The problem is as follows:
> Using kernel 2.6.27-rc* with the GEM extensions from Eric's
> drm-gem-merge branch as of today and after resuming from suspend to RAM
> the xserver eats up about 80% of the cpu load on my DualCore system.
> X.org modular is from git master as well as mesa, libdrm (branch
> modesetting-gem) and xf86-video-intel (master after merge of modesetting).
> None of the logs shows anything irregular.
> I am using an intel 945GM.
> Any recommendations how to track that behaviour? OProfile?
Yeah. I generally use sysprof for better visualization (though it's
kind of a mess with current kernels. Apparently the new in-kernel
sysprof module is not actually for any version of sysprof that exists,
so you use a branch from svn and get a bunch of error messages but a
mostly-correct profile), but if you can convince oprofile to work then
I would expect that you're running into something like the idle ioctl
from the x server (the old-style idle call with the spinning, since we
haven't totally moved to GEM in the 2d driver yet) is spinning then
timing out then the server's restarting it, or something. In that case
we need to find what broke with chip state reset between suspend/resume.
intel_reg_dumper before and after may help there, though we really need
a more verbose version for debugging this sort of stuff. Another
possibility is that we're not idling the chip correctly before suspend,
particularly if you're not VT switching (sometimes Linux systems I've
seen fail at this), in which case you might have a pile of junk in the
ring at resume time.
Overall, while my 3 regular-use machines have been suspend/resuming fine
as far as graphics go, we probably want tighter integration of
suspend/resume into GEM.