Random stalls in graphical apps with Intel G41 Chipset and linux-3.7-rc2 x86_64

[Chris Wilson]

On Fri, 26 Oct 2012 11:31:49 -0500, Alex Villací­s Lasso <a_villacis at palosanto.com> 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