|
Description
felix.engemann
2012-07-25 09:10:01 UTC
There has been a GPU hang, please mount debugfs and attach /sys/kernel/debug/dri/0/i915_error_state. Created attachment 64650 [details]
i915_error_state from Ubuntu 12.04 live CD
So it dies on the very first UXA render batch buffer. Either we program some state incorrectly for HD2500, or we are missing some chicken bits in the kernel. Can you check whether SNA dies in the same way? Chris, i will try to do an alternate install of Ubuntu 12.04 in order to change rendering in xorg.conf Created attachment 64665 [details]
i915_error_state from Ubuntu 12.04 (SNA activated)
sna rendering activated by:
Section "Device"
Identifier "card0"
Driver "intel"
Option "AccelMethod" "sna"
EndSection
in /etc/X11/xorg.conf.d/20-intel.conf
Hope I did that correct?! Anyway X Server won't start ...
Created attachment 64666 [details]
Xorg.0.log from Ubuntu 12.04 (SNA activated)
Created attachment 64667 [details]
dmesg from Ubuntu 12.04 (SNA activated)
Ok, that driver is too old to have SNA enabled, so it is just using UXA and hitting the same hang. Ok. That is what I suspected ... Sorry .. Looking for a PPA with newer drivers. Will post again .. Created attachment 64668 [details]
i915_error_state from Ubuntu 12.04 xorg-edgers (SNA activated)
Created attachment 64669 [details]
Xorg.0.log from Ubuntu 12.04 (xorg-edgers) (SNA activated)
Created attachment 64671 [details]
dmesg from Ubuntu 12.04 xorg-edgers (SNA activated)
Hi Chris, this time SNA is activated - but X Server still crashes badly. Xorg.0.log says: [ 15.400] (II) intel(0): SNA initialized with IvyBridge backend Please note that the xorg-edgers PPA also pulls in a whole new kernel (3.5.x) + xorg stack (X Server 1.12.3) to Ubuntu 12.04. Slightly different, it didn't die immediately on the first render batch. However, very early on and in similar circumstances. That rules out an easy approach of just comparing and contrasting the UXA/SNA batches, I will have to look harder at the code instead. Ok thx Chris, ... If you have anything I could test for you, just let me know. The HD2500 isn't as comman as the HD4000 I'm afraid. I think it's strange that the HD2500 is working on much older X Server 1.10 with Kernel 3.1 ... Does 3.1 even recognise IVB? Could you please attach the old Xorg.log? Maybe support for IVB is backported by OpenSuse kernel developers?! I don't know. Installing OpenSuse 12.1 right now on yet another disk. Will post Xorg.0.log of working configuration. Created attachment 64673 [details]
Xorg.0.log from OpenSuse 12.1 (X Server 1.10, Kernel 3.1) WORKING
Hi Chris, attached is the Xorg.log from my only working configuration (OpenSuse 12.1 plain installation / X-Server 1.10 / Kernel 3.1)
Ok, now can we do a little experimentation? Can you update the kernel on the OpenSuse box? Does that explode. Then can you update the ddx, and see if that explodes with either kernel? If you can compile the kernel/ddx from source for OpenSuse that will help for the next phase... :) Sure we can do some experimentation ... 1) I already tried Kernel 3.4.4 (not self compiled) from OpenSuse Repo (http://download.opensuse.org/repositories/Kernel:/stable/standard/) Nothing exploded ... things got even better. I even got rid of some "hangcheck timer elapsed" messages. 2) I'm willing to compile Kernel / DDX. So if you could give me some advice which version of drivers I should compile respectively which combination of Kernel / ddx ... Ok, to catch up to Ubuntu we should check kernel-3.5 to be sure. But it looks like the hunt is on for a bug in the ddx (hopefully, as it tends to be a little easier to bisect). So if you grab xf86-video-intel from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel (git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel) and run ./autogen.sh --prefix=/usr and install (you can overwrite the installed driver with the package manager later) and see if that triggers the hang. ok will try that Chris. First I have to set up some sane build environment on that OpenSuse box ... argh ... Did I tell you, that I'm normally trying to avoid everything which has Suse in its name ... :) Still git-cloning http://cgit.freedesktop.org/xorg/driver/xf86-video-intel Guess this will take same time for the initial clone ... Will report back in a few hours ... Ok build environment ready now. Installed some tools and xorg-*-devel packages to sort some errors out. But I have still some problems running autogen on xf86-video-intel (libdrm > 2.4.29 requested): checking sys/sysinfo.h usability... yes checking sys/sysinfo.h presence... yes checking for sys/sysinfo.h... yes checking whether to include SNA support... yes checking whether to include UXA support... yes checking for DRMINTEL... no configure: error: Package requirements (libdrm_intel >= 2.4.29) were not met: Requested 'libdrm_intel >= 2.4.29' but version of libdrm is 2.4.26 Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables DRMINTEL_CFLAGS and DRMINTEL_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. ------------------------------------------------------------------------------- Where can I get appropriate libdrm. And how can I tell autogen.sh to use the right one. libdrm is available from git://anongit.freedesktop.org/mesa/drm (http://cgit.freedesktop.org/mesa/drm) and if you compile and install it in the usual fashion, the rest of the build will pick it up. Ok next error i couldn't sort out. autogen.sh in xf86-video-intel works now. But make fails:
CC intel_xvmc.lo
In file included from intel_xvmc.h:43:0,
from intel_xvmc.c:27:
/usr/local/include/xf86drm.h:40:17: fatal error: drm.h: No such file or directory
compilation terminated.
make[4]: *** [intel_xvmc.lo] Fehler 1
make[4]: Leaving directory `/home/engemann/DDX/xf86-video-intel/src/xvmc'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/home/engemann/DDX/xf86-video-intel/src/xvmc'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/engemann/DDX/xf86-video-intel/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/engemann/DDX/xf86-video-intel'
make: *** [all] Fehler 2
-----------------------------------------------
But: There is a /usr/include/libdrm/drm.h
I exported CPPFLAGS:
export CPPFLAGS="-I/usr/include/libdrm/"
with no success
Ok forget about the last post. Simply added a wrong --prefix while configuring libdrm. But still getting errors building the drivers:
/usr/include/X11/fonts/fontproto.h:61:12: note: previous declaration of 'StoreFontClientFont' was here
CC libfb_la-fbimage.lo
In file included from /usr/include/xorg/privates.h:145:0,
from /usr/include/xorg/gcstruct.h:59,
from fb.h:36,
from fbimage.c:26:
/usr/include/xorg/dix.h:527:22: warning: redundant redeclaration of 'ffs' [-Wredundant-decls]
CC libfb_la-fbline.lo
In file included from /usr/include/xorg/privates.h:145:0,
from /usr/include/xorg/gcstruct.h:59,
from fb.h:36,
from fbline.c:24:
/usr/include/xorg/dix.h:527:22: warning: redundant redeclaration of 'ffs' [-Wredundant-decls]
fbline.c: In function 'fbZeroLine':
fbline.c:63:10: warning: declaration of 'y1' shadows a global declaration [-Wshadow]
CC libfb_la-fbpict.lo
In file included from /usr/include/xorg/privates.h:145:0,
from /usr/include/xorg/gcstruct.h:59,
from fb.h:36,
from fbpict.c:28:
/usr/include/xorg/dix.h:527:22: warning: redundant redeclaration of 'ffs' [-Wredundant-decls]
In file included from /usr/include/xorg/picturestr.h:28:0,
from fbpict.c:30:
/usr/include/xorg/glyphstr.h:100:1: warning: redundant redeclaration of 'FindGlyphHashSet' [-Wredundant-decls]
/usr/include/xorg/glyphstr.h:94:1: note: previous declaration of 'FindGlyphHashSet' was here
fbpict.c: In function 'sfbComposite':
fbpict.c:49:2: error: too few arguments to function 'miCompositeSourceValidate'
/usr/include/xorg/mipict.h:84:1: note: declared here
fbpict.c:51:3: error: too few arguments to function 'miCompositeSourceValidate'
/usr/include/xorg/mipict.h:84:1: note: declared here
make[4]: *** [libfb_la-fbpict.lo] Fehler 1
make[4]: Leaving directory `/home/engemann/DDX/xf86-video-intel/src/sna/fb'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/home/engemann/DDX/xf86-video-intel/src/sna'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/engemann/DDX/xf86-video-intel/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/engemann/DDX/xf86-video-intel'
make: *** [all] Fehler 2
Created attachment 64690 [details] [review] Compile against 1.10 This patch should do the trick temporarily. Thx. Finally I made it. I compiled and installed git drivers, restarted X - and it blew the whole thing up. X Server is starting first - but Image is horribly distorted and heavily artefacted. Made my way to the console with CTRL-ALT-FX because the whole UI is hanging .. attaching Xorg.0.log and i915_error_state now Created attachment 64691 [details]
Xorg.0.log from OpenSuse 12.1 (X Server 1.10, Kernel 3.1) git drivers
Created attachment 64692 [details]
i915_error_state from OpenSuse 12.1 (X Server 1.10, Kernel 3.1) git drivers
I get the feeling that's a different hang. Does the current set of kernel & drivers hang immediately boot like the original bug? Yes seems different to me too. Drivers on Ubuntu 12.04 did hang immediate. Now X seems to start but screen is horribly distorted. It goes from a black screen to horribly distorted every few seconds. So something between intel drivers on Ubuntu 12.04 till now changed. But not for the better .... Working drivers for HD2500 on OpenSuse 12.1 got messed up. So lets tackle the ddx on OpenSuse issue and see if that leads to the wider issue. If you 'cd xf86-video-intel && git checkout 2.16.0' compile, install and check if that works. Hopefully that should build the working suse driver from before. Then the hunt begins... git bisect start git bisect good 2.16.0 git bisect bad master Compile, install, test. If it works, say git bisect good, otherwise git bisect bad, and lets hope it leads to the culprit/victim... Hi Chris, yes self compiled 2.16.0 works as expected. No distortions, no hangs, nice clean i915_error_state .. I never did a bisect before, so I can't say what git bisect start git bisect good 2.16.0 git bisect bad master will do exactly ... Shouldn't I check out next version, compile, install, test until bug appears, so that we know which version broke ? So ok I see - this is what git bisect start git bisect good 2.16.0 git bisect bad master does. [ 27.885] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 27.885] (II) Module intel: vendor="X.Org Foundation" [ 27.885] compiled for 1.10.4, module version = 2.17.0 2.17.0 seems to introduce the bug. Same distorted screen as 2.20.1 I can post Xorg.0.log and i915_error_state if necessary. Ok, the git bisection should hopefully narrow down to which commit actually broke things. cd xf86-video-intel git bisect start # tell git to prepare for bisection git bisect good 2.16.0 # last known good, one end point git bisect bad 2.17.0 # first known bad, the other end point git will then pick a commit roughly half-way between the two for you to compile and test. Then after you say git bisect good or git bisect bad (depending on whether the test passed or failed) it will choose another commit for your to test, roughly between the two new endpoints. Eventually it will whittle down to the most likely suspect. Meanwhile I can review all the patches that went into 2.17.0. cd xf86-video-intel git bisect start git bisect good 2.16.0 git bisect bad 2.17.0 compile, install - same thing > git bisect bad Bisecting: 102 revisions left to test after this (roughly 7 steps) [c6acf1325833b8679ef09ab74f0cb0fd82a8cd92] sna/accel: Micro-optimise sna_fill_spans_blt ./autogen.sh --prefix=/usr && make && make install -> same thing > git bisect bad Bisecting: 51 revisions left to test after this (roughly 6 steps) [84a7c11a8134dfd040d2f90bb1e0670aa2c89962] sna/video: Stop advertising unsupported Xv attributes ./autogen.sh --prefix=/usr && make && make install -> WORKS! Does this help? Can I further narrow down if i now do "git bisect good" until it fails again ? Ok I just continued bisecting ... > git bisect good Bisecting: 25 revisions left to test after this (roughly 5 steps) [61764af13aa3c770d19d51c8ad198cab8a5866f1] sna/dri: Bump DRI2INFOREC_VERSION ./autogen.sh --prefix=/usr && make && make install -> WORKS! >git bisect good Bisecting: 12 revisions left to test after this (roughly 4 steps) [4fd46b8bb7e7a104a0afa0e5dee92993e043ef57] sna/glyphs: Add glyphs directly onto a client temporary buffer ./autogen.sh --prefix=/usr && make && make install -> FAILS >git bisect bad Bisecting: 6 revisions left to test after this (roughly 3 steps) [6bbb88af096e054877409a54d0e0a4ccf5ee317e] Fix incorrect maximum PS thread count on IvyBridge ./autogen.sh --prefix=/usr && make && make install -> FAILS >git bisect bad Bisecting: 2 revisions left to test after this (roughly 2 steps) [c68856f34653ac3e7af900dfbba41a108ffe119e] sna/accel: Only skip undamaging the GPU for reads ./autogen.sh --prefix=/usr && make && make install -> WORKS! >git bisect good Bisecting: 0 revisions left to test after this (roughly 1 step) [7f7f95abbf57e6e71f6a30d917f97c2f2bd6cea9] sna/accel: Use the PolyFillRect to handle tiled spans -> WORKS! >git bisect good 6bbb88af096e054877409a54d0e0a4ccf5ee317e is the first bad commit commit 6bbb88af096e054877409a54d0e0a4ccf5ee317e Author: Kenneth Graunke <kenneth@whitecape.org> Date: Sat Sep 24 09:27:33 2011 +0100 Fix incorrect maximum PS thread count on IvyBridge I mistakenly set GEN7_PS_MAX_THREAD_SHIFT to 23; it's actually 24 on Ivybridge. Not only did this halve our thread count, it caused us to write 1 into a bit 23, which is marked as MBZ (must be zero). Furthermore, it made us write an even number into this field, which is apparently not allowed. Apparently we were just lucky it worked. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> :040000 040000 15f01b78a0d0224a8ac73b0aec0740ed782bcb87 00ea8e4e6c877d1699849b63398c9603f04bd678 M src Created attachment 64705 [details] [review] Reduce max thread count to 42 Scary. Can you please try this patch to reduce the max thread count? Can you please tell me the output of "intel_reg_read 0x7008"? (intel_reg_read is part of intel-gpu-tools, http://cgit.freedesktop.org/xorg/app/intel-gpu-tools) > intel_reg_read 0x7008 Couldn't map MMIO region: No such file or directory This was before applying patch attached above. Before I apply your patch I will first checkout 2.17.0 right ? > git checkout 2.17.0 to be sure the bug is in ? Try sudo intel_reg_read 0x7008 You can first try the patch against 2.17.0 (might need some fuzzing, it's just changing the value 86 to 42 next to GEN7_PS_MAX_THREADS_SHIFT) to confirm your bisection and then try against master to confirm that it is at least one of the issues involved... Ok, your patch worked!
> cd xf86-video-intel
> git checkout 2.17.0
-> Applying your patch
-> configure, compile, install
-> No distortions no hang on 2.17.0
intel_reg_read 0x7008
was already run as root ... Maybe wrong version ?! I just executed the version which was already installed on that OpenSuse box.
Your patch also worked on master! What I did: > git stash > git checkout master -> applied patches for build against 1.10 and Reduce max thread count to 42 -> configure / compile / install [ 27.882] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 27.882] (II) Module intel: vendor="X.Org Foundation" [ 27.882] compiled for 1.10.4, module version = 2.20.1 [ 27.882] Module class: X.Org Video Driver [ 27.882] ABI class: X.Org Video Driver, version 10.0 No glitches / no hangs / everything seems to work. Don't know if this makes sense!? > intel_reg_read 0x7008 (as root) Couldn't map MMIO region: No such file or directory Created attachment 64710 [details] [review] Allocate some scratch space for gen7 Another idea... Can you please apply this patch and test SNA? Ok
> git stash
> git checkout master
-> patching with following patches
- Compile against 1.10
- Allocate some scratch space for gen7
-> configuring, compiling, installing
UXA fails with same distortaion
SNA fails with similar but not same distortions. Screen doesn't periodically turns black. Distortions seems less. But gets obvious when moving a window. Especially content of window gets distorted.
Attaching i915_error_state
Created attachment 64711 [details]
i915_error_state from Patch "Allocate some scratch space for gen7"
Created attachment 64712 [details] [review] Reduce WM count for IVB GT1 (sna) So this is the equivalent patch for SNA. Drop the failed scratch space idea and please try this instead. Thanks! Created attachment 64713 [details] [review] Allocate some scratch space for gen7 Drat. I had my arguments reversed (thanks for the error-state!) can you try the compile + scratch space again for a quick test? (In reply to comment #49) > Created attachment 64712 [details] [review] [review] > Reduce WM count for IVB GT1 (sna) > > So this is the equivalent patch for SNA. Drop the failed scratch space idea and > please try this instead. Thanks! So first this patch "Reducing WM count". This one ALMOST solves the issue for SNA. There are minor glitches (only on the window decorator of one window I have open). But no hangs. /sys/kernel/debug/dri/0/i915_error_state is empty. (In reply to comment #50) > Created attachment 64713 [details] [review] [review] > Allocate some scratch space for gen7 > > Drat. I had my arguments reversed (thanks for the error-state!) can you try the > compile + scratch space again for a quick test? Ok. All previously applied patches dropped. (git stash) Applied build 1.10 patch and this one. Tested on SNA. Everything seems to work (no distortions, no glitches) ... But Xorg.0.log is saying: [ 37.421] (EE) intel(0): Detected a hung GPU, disabling acceleration. [ 37.421] (EE) intel(0): When reporting this, please include i915_error_state from debugfs and the full dmesg. Attaching i915_error_state Created attachment 64714 [details]
i915_error_state from Patch "64713: Allocate some scratch space for gen7"
Uuuups. Just ran glxgears. X restarted and all distortions and glitches are back ... (In reply to comment #52) > (In reply to comment #50) > > Created attachment 64713 [details] [review] [review] [review] > > Allocate some scratch space for gen7 > > > > Drat. I had my arguments reversed (thanks for the error-state!) can you try the > > compile + scratch space again for a quick test? > > Ok. All previously applied patches dropped. (git stash) Applied build 1.10 > patch and this one. > > Tested on SNA. Everything seems to work (no distortions, no glitches) ... But > Xorg.0.log is saying: > > > [ 37.421] (EE) intel(0): Detected a hung GPU, disabling acceleration. > [ 37.421] (EE) intel(0): When reporting this, please include > i915_error_state from debugfs and the full dmesg. > > Attaching i915_error_state Hmm, do you have the log file for the glxgears X crash? Also are you able to test the reduce WM thread patches on the Ubuntu system as well? Also do you mind grabbing a photo of the residual corruption after the SNA thread reduction? Does it persist with an uptodate kernel? Does it go away if we reduce the 42 threads to 8? Yes I can try WM reducing Patch on Ubuntu 12.04 if you want. Will take a while until build environment is set up ... Just to clear things up. The patch we talked about in the last comments is a different ... (Allocate some scratch space for gen7) The WM reducing patches solves the issue under UXA and almost solves it under SNA (glitches on window decorator - which could be another issue maybe kwin) But no hangs. (In reply to comment #56) > Also are you able to test the reduce WM thread patches on the Ubuntu system as > well? I can reproduce this issue. Which log do you need? (In reply to comment #55) > Hmm, do you have the log file for the glxgears X crash? Right, I suspect the issue with SNA and the reduced thread count is going to be a missing cache flush in the kernel, hence the interest in seeing if an updated kernel fixes things. And of course wishing to confirm that this is the same issue as befell Ubuntu. Don't worry too much about reproducing the glxgears, just look in /var/log/kdm.log for a recent crash. I'm quite confident that the cause was indirect GLX asserting due to a GPU hang. I wish it wouldn't since it kills X... Created attachment 64721 [details]
kdm.log (64713: Allocate some scratch space for gen7) running glxgears
(In reply to comment #57) > Also do you mind grabbing a photo of the residual corruption after the SNA > thread reduction? Does it persist with an uptodate kernel? Does it go away if > we reduce the 42 threads to 8? Attaching screenshot for SNA + WM Reduce Patch. uname -a Linux linux-kwrd 3.1.10-1.16-desktop #1 SMP PREEMPT Wed Jun 27 05:21:40 UTC 2012 (d016078) x86_64 x86_64 x86_64 GNU/Linux Will now try newer Kernel - then reduce threads further Created attachment 64722 [details]
Glitches 64712: Reduce WM count for IVB GT1 (sna) with Kernel 3.1
What an odd set of glitches. At least they look to be a separate issue! Can you please run "addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0xc6560 0xc7d32" on that Suse build? Yes very odd. Linux linux-kwrd 3.4.5-1-desktop #1 SMP PREEMPT Wed Jul 18 09:09:22 UTC 2012 (cf1edf7) x86_64 x86_64 x86_64 GNU/Linux does not fix them. (In reply to comment #64) > What an odd set of glitches. At least they look to be a separate issue! > > Can you please run "addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so > 0xc6560 0xc7d32" on that Suse build? addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0xc6560 0xc7d32 /home/engemann/DDX/xf86-video-intel/src/sna/sna_damage.h:156 /home/engemann/DDX/xf86-video-intel/src/sna/sna_dri.c:1653 (In reply to comment #57) > Also do you mind grabbing a photo of the residual corruption after the SNA > thread reduction? Does it persist with an uptodate kernel? Does it go away if > we reduce the 42 threads to 8? Next Test. In src/sna/gen7_render.c changed: static const struct gt_info ivb_0152_info = { .max_vs_threads = 36, .max_gs_threads = 36, .max_wm_threads = (42-1) << GEN7_PS_MAX_THREADS_SHIFT, .urb = { 128, 512, 192 }, }; TO: static const struct gt_info ivb_0152_info = { .max_vs_threads = 36, .max_gs_threads = 36, .max_wm_threads = (8-1) << GEN7_PS_MAX_THREADS_SHIFT, .urb = { 128, 512, 192 }, }; -> Same glitches as before. Remeber first WM Patch: - Reduce max thread count to 42 is not applied here. On all SNA tests only: - Reduce WM count for IVB GT1 (sna) was applied As another datapoint do you see the same corruption under SNA and KDE on the GT2 device? Also what effects do you have active for kwin? (And please excuse the noise) Can you paste what lines you have for /home/engemann/DDX/xf86-video-intel/src/sna/sna_damage.h:156 /home/engemann/DDX/xf86-video-intel/src/sna/sna_dri.c:1653 as I'm being left baffled. :) (In reply to comment #69) > Also what effects do you have active for kwin? Pretty much standard XRandr effects. If I deactivate kwin effects. Distortions are little less but similar. See attachment Created attachment 64726 [details]
Distortions SNA (without kwin effects)
(In reply to comment #70) > (And please excuse the noise) > > Can you paste what lines you have for > > /home/engemann/DDX/xf86-video-intel/src/sna/sna_damage.h:156 > /home/engemann/DDX/xf86-video-intel/src/sna/sna_dri.c:1653 > > as I'm being left baffled. :) > /home/engemann/DDX/xf86-video-intel/src/sna/sna_damage.h:156 151 fastcall struct sna_damage *_sna_damage_subtract(struct sna_damage *damage, 152 RegionPtr region); 153 static inline void sna_damage_subtract(struct sna_damage **damage, 154 RegionPtr region) 155 { 156 *damage = _sna_damage_subtract(DAMAGE_PTR(*damage), region); 157 assert(*damage == NULL || (*damage)->mode != DAMAGE_ALL); 158 } 159 > /home/engemann/DDX/xf86-video-intel/src/sna/sna_dri.c:1653 1634 sna_dri_immediate_blit(struct sna *sna, 1635 DrawablePtr draw, 1636 struct sna_dri_frame_event *info) 1637 { 1638 drmVBlank vbl; 1639 1640 DBG(("%s: emitting immediate blit, throttling client\n", __FUNCTION__)); 1641 VG_CLEAR(vbl); 1642 1643 if ((sna->flags & SNA_NO_WAIT) == 0) { 1644 info->type = DRI2_SWAP_THROTTLE; 1645 if (sna_dri_window_get_chain((WindowPtr)draw) == info) { 1646 DBG(("%s: no pending blit, starting chain\n", 1647 __FUNCTION__)); 1648 1649 info->bo = sna_dri_copy_to_front(sna, draw, NULL, 1650 get_private(info->front)->bo, 1651 get_private(info->back)->bo, 1652 true); 1653 DRI2SwapComplete(info->client, draw, 0, 0, 0, 1654 DRI2_BLIT_COMPLETE, 1655 info->event_complete, 1656 info->event_data); 1657 (In reply to comment #68) > As another datapoint do you see the same corruption under SNA and KDE on the > GT2 device? Sorry can't test a HD4000 at the moment. The one I had for testing is already sold since yesterday. All I can say is that on this device Ubuntu 12.04 worked out of the box (no glitches, all effects, etc ...) But we had some nasty System Freezes: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/993187 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/999910 But seemed to be fixed with Kernel 3.4.4 .. hopefully ... At least no customer complaint about Freezes since Kernel 3.4.4 Next Test HD4000 CPU (i5 3475S) will arrive shortly. Then I can test SNA distortions ... We are a small company from germany selling mini-PCs with Ubuntu preinstalled (www.cirrus7.com). We started selling our Ivy Bridge model shortly. So first shock was constant freezes under Ubuntu in first tests ... Second shock was HD2500 did not work at all ... So we stopped selling all HD2500 models ... It came as a bit of shock to us as well... Many thanks for your efforts! (In reply to comment #75) > It came as a bit of shock to us as well... Many thanks for your efforts! No problem .. It's in my own interest that the problems get sorted out ... :) I'm setting up a Ubuntu 12.04 build environment now to confirm WM count patches under Ubuntu Xorg stack. This will take some hours. Will report back ... Ok, spotted how we could end up with an invalid pointer there after the GPU hangs, and hopefully corrected it. Now all that remains is verifying the fix for the GPU hang, and making progress on the flushing front. I've looked at kde4 on the i7-3720qm I have here and bingo... Ok, should be able to find out what's causing that. And lo, the corruption is gone: commit 7f3fdef98c1ab2fa27439c3be9810b7a934017ce Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 26 15:39:05 2012 +0100 sna/gen7: IVB requires a complete pipeline stall when changing blend modes Similar to how SandyBridge behaves, I had hoped that with IvyBridge they would have made the pipelined operation actually pipelined, but alas. Now this is strange .... - installed Ubuntu 12.04 - git cloned xf86-video-intel -> patched with "Reduce max thread count to 42" and "Reduce WM count for IVB GT1 (sna)" - configured, build, installed -> Under UXA same symptom as unpatched X Server wont start properly -> Under SNA same thing So WM count patches does not fix the issue on Ubuntu 12.04. Same patches worked for - X Server 1.10 (OpenSuse 12.1) - Kernel 3.1 / 3.4.4 (OpenSuse 12.1) Now same patched does not work for - XServer 1.11 (Ubuntu 12.04) - Kernel 3.2 (Ubuntu 12.04) Will attach Xorg.0.log and i915_error_state from last test (SNA with WM count patch) Created attachment 64744 [details]
Xorg.0.log from Ubuntu 12.04 (git compiled + SNA activated + WM count patch)
Created attachment 64745 [details]
i915_error_state from Ubuntu 12.04 (git compiled + SNA activated + WM count patch)
Oj, we are now into mesa territory, so we have overcome the instant death upon starting X only to die a little later as mesa (libGL) encounters the same issue. Can you prepare to build mesa, and perhaps test X without using a 3D compositor (e.g. unity2d or kde or gnome-classic) on ubuntu? The mesa patch is
diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965
index de8b66c..7a70612 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -240,7 +240,7 @@ brwCreateContext(int api,
/* WM maximum threads is number of EUs times number of threads per EU. */
if (intel->gen >= 7) {
if (intel->gt == 1) {
- brw->max_wm_threads = 86;
+ brw->max_wm_threads = 42;
brw->max_vs_threads = 36;
brw->max_gs_threads = 36;
brw->urb.size = 128;
good point! unity3d dies right away unity2d however works! No corruption and no errors in i915_error_state so far. (under SNA and with WM count patches applied) will prepare for compiling mesa now ... (In reply to comment #82) > Oj, we are now into mesa territory, so we have overcome the instant death upon > starting X only to die a little later as mesa (libGL) encounters the same > issue. > > Can you prepare to build mesa, and perhaps test X without using a 3D compositor > (e.g. unity2d or kde or gnome-classic) on ubuntu? (In reply to comment #83) > The mesa patch is > > diff --git a/src/mesa/drivers/dri/i965/brw_context.c > b/src/mesa/drivers/dri/i965 > index de8b66c..7a70612 100644 > --- a/src/mesa/drivers/dri/i965/brw_context.c > +++ b/src/mesa/drivers/dri/i965/brw_context.c > @@ -240,7 +240,7 @@ brwCreateContext(int api, > /* WM maximum threads is number of EUs times number of threads per EU. */ > if (intel->gen >= 7) { > if (intel->gt == 1) { > - brw->max_wm_threads = 86; > + brw->max_wm_threads = 42; > brw->max_vs_threads = 36; > brw->max_gs_threads = 36; > brw->urb.size = 128; - git cloned mesa - installed all kind of dev-packages to meet requirements - finally ./autogen.sh works .... - your patch fails with: root@engemann-H77:~/DDX/mesa# patch src/mesa/drivers/dri/i965/brw_context.c patch.patch patching file src/mesa/drivers/dri/i965/brw_context.c Hunk #1 FAILED at 240. 1 out of 1 hunk FAILED -- saving rejects to file src/mesa/drivers/dri/i965/brw_context.c.rej because: brw->max_wm_threads = 86; starts two lines later here. - so i manually changed "brw->max_wm_threads = 86;" to "brw->max_wm_threads = 42;" - hit "make" - installed bison because yacc was needed - hit "make" again and get another error: make[2]: Verlasse Verzeichnis '/root/DDX/mesa/src/mapi/glapi' Making all in glsl make[2]: Betrete Verzeichnis '/root/DDX/mesa/src/glsl' GEN glsl_parser.h Konflikte: 1 Schiebe/Reduziere CC hash_table.o CC symbol_table.o CXX standalone_scaffolding.o CXX main.o CXX builtin_stubs.o LEX glsl_lexer.cc make[2]: *** [glsl_lexer.cc] Fehler 1 make[2]: Verlasse Verzeichnis '/root/DDX/mesa/src/glsl' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/root/DDX/mesa/src' make: *** [all-recursive] Fehler 1 Don't know how to solve this one ... Ok, now it worked. I ran "make distclean", after that autogen.sh and make again ... Don't know what happened before - but now it is freshly built with: "brw->max_wm_threads = 42;" in src/mesa/drivers/dri/i965/brw_context.c Nothing seems changed ... Same symptoms as before: unity2d working, unity3d crashing ... How can I check if system is using self compiled mesa ? Ok unity2d seems to run "quite" well. No distortions - no hangs. But if I run glxgears - distortions and hangs are back ... Created attachment 64754 [details]
i915_error_state from Ubuntu 12.04 (git compiled + SNA activated + WM count patch + unity2d) after running glxgears
Created attachment 64755 [details]
Distortions from Ubuntu 12.04 (git compiled + SNA activated + WM count patch + unity2d) after running glxgears
hmmm. Think I'm running on wrong mesa. Maybe i missed some option while running autogen.sh ? This is what I get after running it without options:
prefix: /usr/local
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
OpenGL: yes (ES1: no ES2: no)
OpenVG: no
OSMesa: no
DRI drivers: i915 i965 nouveau r200 radeon swrast
DRI driver dir: ${libdir}/dri
GLX: DRI-based
GLU: yes
EGL: yes
EGL platforms: x11
EGL drivers: builtin:egl_glx builtin:egl_dri2
llvm: yes
llvm-config: /usr/bin/llvm-config
llvm-version: 2.9
Gallium: yes
Gallium dirs: auxiliary drivers state_trackers
Target dirs: dri-r300 dri-r600 dri-swrast dri-vmwgfx
Winsys dirs: radeon/drm svga/drm sw sw/dri
Driver dirs: galahad identity llvmpipe noop r300 r600 rbug softpipe svga trace
Trackers dirs: dri
Shared libs: yes
Static libs: no
CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC
CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LLVM=0x0209
PYTHON2: python2
Run 'make' to build Mesa
Ok, so we discovered that there was a bspec update and that IVB GT1 is limited to 48 threads, so I pushed commit 1ced4f1ddcf30b518e1760c7aa4a5ed4f934b9f5 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 26 10:50:31 2012 +0100 Reduce maximum thread count for IVB GT1 to avoid spontaneous combustion Somewhere along the way it seems that IVB GT1 was reduced to only allow a maximum of 48 threads, as revealed in the lastest bspecs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52473 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> to take care of the issue in the ddx. As you are aware the issue still remains in mesa. Testing mesa itself is a bit tricky since Ubuntu install their libGL ahead of /usr/local/lib in the search path. If you are brave, you can just cp your mesa/lib/i965_drv.so to /usr/lib/`uname -m`/dri and overwrite the system library. Or you can try poking around /etc/ld.so.conf to see if you can your library linked first (I haven't had much luck with that approach). Or you can boot to a vt, and run everything by hand with a LD_PRELOAD=/usr/local/lib/libGL.so. Ok running patched mesa now. Can confirm changing limiting max_wm_threads to 42 in src/mesa/drivers/dri/i965/brw_context.c does not crash anymore. OpenGL version string: 2.1 Mesa 8.1-devel (git-e72f206) Can run glxgears without crashing now. Can start unity3d session without crashing. Only strange thing is - it seems Ubuntu is falling back to unity2d. I have no desktop effects at least ... (In reply to comment #92) > Ok running patched mesa now. Can confirm changing limiting max_wm_threads to 42 > in src/mesa/drivers/dri/i965/brw_context.c does not crash anymore. > > OpenGL version string: 2.1 Mesa 8.1-devel (git-e72f206) > > Can run glxgears without crashing now. Can start unity3d session without > crashing. Only strange thing is - it seems Ubuntu is falling back to unity2d. I > have no desktop effects at least ... Don't know why that should be... But at least it looks like we on the right path to getting the driver stable. yes looks good now! I think it's something complete different and unrelated .... Can continue testing tomorrow - if needed. Cheers Felix I've pushed a new release of the DDX to fix this bug, thank you many times over for identifying the issue! I've raised a bug (#52382) against Mesa to get the respective fix into a release there as well. If you have any more issues, please do let me know about them. *** This bug has been marked as a duplicate of bug 52382 *** Thank you Chris for taking care about this issue so quick. Will retest new DDX release (2.20.2) on weekend. Hopefully it's picked up by Distros soon :) Will open a request on launchpad. Cheers Felix With 2.20.0 the SNA acceleration worked wonderfully on my gen4 965GM notebook.
After updating to 2.20.2 X gets stuck very fast after start-up with the
following message:
[ 33.859] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 33.859] (II) Module intel: vendor="X.Org Foundation"
[ 33.859] compiled for 1.12.3, module version = 2.20.2
[ 33.859] Module class: X.Org Video Driver
[ 33.859] ABI class: X.Org Video Driver, version 12.0
[ 33.859] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
...
[ 33.869] (II) intel(0): Creating default Display subsection in Screen
section
"Default Screen Section" for depth/fbbpp 24/32
[ 33.869] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[ 33.869] (==) intel(0): RGB weight 888
[ 33.869] (==) intel(0): Default visual is TrueColor
[ 33.869] (**) intel(0): Option "AccelMethod" "SNA"
[ 33.869] (--) intel(0): Integrated Graphics Chipset: Intel(R) 965GM
[ 33.870] (**) intel(0): Framebuffer tiled
[ 33.870] (**) intel(0): Pixmaps tiled
[ 33.870] (**) intel(0): 3D buffers tiled
[ 33.870] (**) intel(0): Throttling enabled
[ 33.870] (**) intel(0): Delayed flush enabled
[ 33.870] (**) intel(0): "Tear free" disabled
[ 33.870] (**) intel(0): Forcing per-crtc-pixmaps? no
[ 33.870] (II) intel(0): Output LVDS1 has no monitor section
[ 33.870] (II) intel(0): found backlight control interface acpi_video0 (type
'firmware')
[ 33.912] (II) intel(0): Output VGA1 has no monitor section
[ 33.920] (II) intel(0): Output DVI1 has no monitor section
[ 33.920] (II) intel(0): Output TV1 has no monitor section
[ 33.921] (II) intel(0): EDID for output LVDS1
...
[ 184.513] [mi] EQ overflowing. Additional events will be discarded until
existing events are processed.
[ 184.513]
[ 184.513] Backtrace:
[ 184.513] 0: /usr/bin/Xorg (xorg_backtrace+0x49) [0x81c8bf9]
[ 184.513] 1: /usr/bin/Xorg (mieqEnqueue+0x22b) [0x81a6e5b]
[ 184.513] 2: /usr/bin/Xorg (0x8048000+0x48375) [0x8090375]
[ 184.513] 3: /usr/bin/Xorg (xf86PostMotionEventM+0x25f) [0x80ccf9f]
[ 184.514] 4: /usr/bin/Xorg (xf86PostMotionEvent+0x8d) [0x80cd19d]
[ 184.514] 5: /usr/lib/xorg/modules/input/synaptics_drv.so
(0xb6862000+0x3afe) [0xb6865afe]
[ 184.514] 6: /usr/lib/xorg/modules/input/synaptics_drv.so
(0xb6862000+0x5e1e) [0xb6867e1e]
[ 184.514] 7: /usr/bin/Xorg (0x8048000+0x73af1) [0x80bbaf1]
[ 184.514] 8: /usr/bin/Xorg (0x8048000+0x9b412) [0x80e3412]
[ 184.514] 9: (vdso) (__kernel_sigreturn+0x0) [0xb7779400]
[ 184.514] 10: /lib/libc.so.6 (ioctl+0x14) [0xb73c0334]
[ 184.514] 11: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0xb71c2014]
[ 184.514] 12: /usr/lib/xorg/modules/drivers/intel_drv.so
(0xb6dd2000+0x349e7) [0xb6e069e7]
[ 184.514] 13: /usr/lib/xorg/modules/drivers/intel_drv.so
(0xb6dd2000+0x35aa8) [0xb6e07aa8]
[ 184.514] 14: /usr/lib/xorg/modules/drivers/intel_drv.so
(0xb6dd2000+0x5ee63) [0xb6e30e63]
[ 184.514] 15: /usr/lib/xorg/modules/drivers/intel_drv.so
(0xb6dd2000+0x6efe5) [0xb6e40fe5]
[ 184.514] 16: /usr/bin/Xorg (BlockHandler+0x56) [0x807efc6]
[ 184.514] 17: /usr/bin/Xorg (WaitForSomething+0x10b) [0x81c5dab]
[ 184.515] 18: /usr/bin/Xorg (0x8048000+0x32d62) [0x807ad62]
[ 184.515] 19: /usr/bin/Xorg (0x8048000+0x209ba) [0x80689ba]
[ 184.515] 20: /lib/libc.so.6 (__libc_start_main+0xf3) [0xb730c003]
[ 184.515] 21: /usr/bin/Xorg (0x8048000+0x20ce9) [0x8068ce9]
[ 184.515]
[ 184.515] [mi] These backtraces from mieqEnqueue may point to a culprit
higher up the stack.
[ 184.515] [mi] mieq is *NOT* the cause. It is a victim.
[ 189.020] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[ 189.020] (EE) intel(0): When reporting this, please include
i915_error_state from debugfs and the full dmesg.
[ 190.679] [mi] Increasing EQ size to 512 to prevent dropped events.
[ 190.680] [mi] EQ processing has resumed after 93 dropped events.
[ 190.680] [mi] This may be caused my a misbehaving driver monopolizing the
server's resources.
[ 201.938] (II) AIGLX: Suspending AIGLX clients for VT switch
This problem is gone, if I switch back to UXA.
When I check the change log from
http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_12.1/i586/xf86-video-intel-2.20.2-21.1.i586.rpm
I see this change.
In the other logs of this bug report like Xorg.0.log the messages seems to be quite similar.
I use openSUSE 12.1 with the newest intel driver version 2.20.2 offered by OBS together with stable kernel 3.4.6 and flavor desktop-i586.
Thanks
Ralf
Nothing at all obvious to do with this bug. Please file a fresh bug report with a full set of Xorg.log, dmesg and i915_error_state. With 2.20.0 the SNA acceleration worked wonderfully on my gen4 965GM notebook.
After updating to 2.20.2 X gets stuck very fast after start-up with the
following message:
[ 33.859] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 33.859] (II) Module intel: vendor="X.Org Foundation"
[ 33.859] compiled for 1.12.3, module version = 2.20.2
[ 33.859] Module class: X.Org Video Driver
[ 33.859] ABI class: X.Org Video Driver, version 12.0
[ 33.859] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
...
[ 33.869] (II) intel(0): Creating default Display subsection in Screen
section
"Default Screen Section" for depth/fbbpp 24/32
[ 33.869] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[ 33.869] (==) intel(0): RGB weight 888
[ 33.869] (==) intel(0): Default visual is TrueColor
[ 33.869] (**) intel(0): Option "AccelMethod" "SNA"
[ 33.869] (--) intel(0): Integrated Graphics Chipset: Intel(R) 965GM
[ 33.870] (**) intel(0): Framebuffer tiled
[ 33.870] (**) intel(0): Pixmaps tiled
[ 33.870] (**) intel(0): 3D buffers tiled
[ 33.870] (**) intel(0): Throttling enabled
[ 33.870] (**) intel(0): Delayed flush enabled
[ 33.870] (**) intel(0): "Tear free" disabled
[ 33.870] (**) intel(0): Forcing per-crtc-pixmaps? no
[ 33.870] (II) intel(0): Output LVDS1 has no monitor section
[ 33.870] (II) intel(0): found backlight control interface acpi_video0 (type
'firmware')
[ 33.912] (II) intel(0): Output VGA1 has no monitor section
[ 33.920] (II) intel(0): Output DVI1 has no monitor section
[ 33.920] (II) intel(0): Output TV1 has no monitor section
[ 33.921] (II) intel(0): EDID for output LVDS1
...
[ 184.513] [mi] EQ overflowing. Additional events will be discarded until
existing events are processed.
[ 184.513]
[ 184.513] Backtrace:
[ 184.513] 0: /usr/bin/Xorg (xorg_backtrace+0x49) [0x81c8bf9]
[ 184.513] 1: /usr/bin/Xorg (mieqEnqueue+0x22b) [0x81a6e5b]
[ 184.513] 2: /usr/bin/Xorg (0x8048000+0x48375) [0x8090375]
[ 184.513] 3: /usr/bin/Xorg (xf86PostMotionEventM+0x25f) [0x80ccf9f]
[ 184.514] 4: /usr/bin/Xorg (xf86PostMotionEvent+0x8d) [0x80cd19d]
[ 184.514] 5: /usr/lib/xorg/modules/input/synaptics_drv.so
(0xb6862000+0x3afe) [0xb6865afe]
[ 184.514] 6: /usr/lib/xorg/modules/input/synaptics_drv.so
(0xb6862000+0x5e1e) [0xb6867e1e]
[ 184.514] 7: /usr/bin/Xorg (0x8048000+0x73af1) [0x80bbaf1]
[ 184.514] 8: /usr/bin/Xorg (0x8048000+0x9b412) [0x80e3412]
[ 184.514] 9: (vdso) (__kernel_sigreturn+0x0) [0xb7779400]
[ 184.514] 10: /lib/libc.so.6 (ioctl+0x14) [0xb73c0334]
[ 184.514] 11: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0xb71c2014]
[ 184.514] 12: /usr/lib/xorg/modules/drivers/intel_drv.so
(0xb6dd2000+0x349e7) [0xb6e069e7]
[ 184.514] 13: /usr/lib/xorg/modules/drivers/intel_drv.so
(0xb6dd2000+0x35aa8) [0xb6e07aa8]
[ 184.514] 14: /usr/lib/xorg/modules/drivers/intel_drv.so
(0xb6dd2000+0x5ee63) [0xb6e30e63]
[ 184.514] 15: /usr/lib/xorg/modules/drivers/intel_drv.so
(0xb6dd2000+0x6efe5) [0xb6e40fe5]
[ 184.514] 16: /usr/bin/Xorg (BlockHandler+0x56) [0x807efc6]
[ 184.514] 17: /usr/bin/Xorg (WaitForSomething+0x10b) [0x81c5dab]
[ 184.515] 18: /usr/bin/Xorg (0x8048000+0x32d62) [0x807ad62]
[ 184.515] 19: /usr/bin/Xorg (0x8048000+0x209ba) [0x80689ba]
[ 184.515] 20: /lib/libc.so.6 (__libc_start_main+0xf3) [0xb730c003]
[ 184.515] 21: /usr/bin/Xorg (0x8048000+0x20ce9) [0x8068ce9]
[ 184.515]
[ 184.515] [mi] These backtraces from mieqEnqueue may point to a culprit
higher up the stack.
[ 184.515] [mi] mieq is *NOT* the cause. It is a victim.
[ 189.020] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[ 189.020] (EE) intel(0): When reporting this, please include
i915_error_state from debugfs and the full dmesg.
[ 190.679] [mi] Increasing EQ size to 512 to prevent dropped events.
[ 190.680] [mi] EQ processing has resumed after 93 dropped events.
[ 190.680] [mi] This may be caused my a misbehaving driver monopolizing the
server's resources.
[ 201.938] (II) AIGLX: Suspending AIGLX clients for VT switch
This problem is gone, if I switch back to UXA.
When I check the change log from
http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_12.1/i586/xf86-video-intel-2.20.2-21.1.i586.rpm
I see this change.
In the other logs of this bug report like Xorg.0.log the messages seems to be quite similar.
I use openSUSE 12.1 with the newest intel driver version 2.20.2 offered by OBS together with stable kernel 3.4.6 and flavor desktop-i586.
Thanks
Ralf
WONTFIX for gen4 hardware. 2.20.0 was able to work on GM965 Ralf, this is not your bug. This is nothing to do with 965gm. The first thing you should do before reporting a bug upstream is first try to reproduce it on the upstream driver. Had you done that you would have found it fixed already. *** Bug 54848 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 52382 *** |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.