On Fri, 26 Oct 2012 11:31:49 -0500, Alex VillacÃÂs Lasso <[email protected]> wrote: > I am testing linux-3.7-rc2 in Fedora 16 x86_64 in a workstation at my day > job. My kernel configuration is attached. My graphics chipset shows up in > lspci as follows: > > 00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset > Integrated Graphics Controller [8086:2e32] (rev 03) (prog-if 00 [VGA > controller]) > Subsystem: Intel Corporation Device [8086:d612] > Flags: bus master, fast devsel, latency 0, IRQ 43 > Memory at d0000000 (64-bit, non-prefetchable) [size=4M] > Memory at c0000000 (64-bit, prefetchable) [size=256M] > I/O ports at f140 [size=8] > Expansion ROM at <unassigned> [disabled] > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > Capabilities: [d0] Power Management version 2 > Kernel driver in use: i915 > Kernel modules: i915 > > All the tests were made with the default KMS enabled, as setup by the distro. > > With the distro-supplied linux-3.6.2-1, I have no problems at all with > graphics. Likewise with vanilla kernel 3.6.0. > > With 3.7-rc1 onwards, and also 3.7-rc2, my workstation seems to boot normally > and I can login into Gnome Shell. However, after a while, some random > graphical client with which I am interacting stops responding. This stall is > of random length - sometimes it > lasts a fraction of a second, or any interval up to a few minutes. It seems > that anything that causes the app to try to draw to the screen might cause > the stall, even something as simple as switching to the app. So far, I have > seen stalls while using the > following apps: firefox, thunderbird, eclipse, gnome-terminal, and even > gnome-shell itself. When gnome-shell is affected, the entire desktop freezes, > and becomes unusable. However, in all cases (even gnome-shell stalls), the > mouse cursor can be moved, and > I can switch into other consoles with Ctrl-Alt-Fn very easily. When I switch > to a console, I can run top, and it shows me that the stalled application is > apparently burning CPU time at 99%, but the corresponding CPU is busy in > "system" time, not "user" time.
It doesn't look to be a driver or application issue. The common pattern seems to be that the writev used for sending the requests to X is stalling. As X11 and its clients is likely to be the most frequent such user of those interfaces on your system, it is likely to trigger any such bug more frequently. Since it is spinning in the kernel, can you look at the /proc/`pidof affected-process`/stack and see where it is spinning? -Chris -- Chris Wilson, Intel Open Source Technology Centre
_______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: [email protected]
