El 28/10/12 05:33, Chris Wilson escribió:
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
It seems to be fixed in 3.7-rc3.
_______________________________________________
[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]
