Summary: | GPU hung with intel-2.10.901 when resizing qtconfig-qt4 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Clemens Eisserer <linuxhippy> | ||||||
Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | axet, moikkis, orion | ||||||
Version: | unspecified | ||||||||
Hardware: | Other | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
Clemens Eisserer
2010-02-28 14:44:39 UTC
just happend again while using firefox :( Created attachment 34012 [details]
Debug information
I had two freezes while using OpenOffice.org Impress. This is the relevant part of Xorg.log (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Input/output error. dmesg: [242458.032055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [242458.032065] render error detected, EIR: 0x00000000 [242458.032078] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 30818845 at 30818841) VT still working, reboot required to get X working again. I attached a file with debug information. Kernel 2.6.33 Mesa 7.6.1 x11-drivers/xf86-video-intel from git master (May 07) x11-libs/libdrm from git master (May 07) xorg-server 1.7.5 > x11-drivers/xf86-video-intel from git master (May 07)
> x11-libs/libdrm from git master (May 07)
Mar 07, 2010, of course. I tried to reproduce the bug as Clemens described, but couldn't trigger it that way. Tried resizing both the application window and the preview window for a couple of minutes.
did you select "Oxygen", as well as applied the new Look-and-Feel to the main-window? For me (quick) resizing that oxygen-themed window leads to a hang in about 5-15s. Yes, Oxygen is selected (I use it as my KDE theme)... Are you referring to "File | Save" when you say "apply new look and feel"? I did that. I'm using Qt 4.6.2, maybe it doesn't do whatever triggers the crash. KWin compositing is enabled, but it doesn't crash either when I suspend it (Alt+Shift+F12). I'm using an i915GM btw. still happens with intel-2.10.902 :/ Happens often enough (most of the time while using firefox), to make me switch back to intel-2.9.1. There is no information inside the tarball due to hang-check+reset interference. Can you try reproducing the hang with a 2.6.34-rc? That includes the "Record batch buffer at time of error" which will append the relevant batch buffer to /sys/kernel/debug/dri/0/i915_error_state. I'm not seeing firefox hangs on my GNOME systems, so I wonder if those hangs are also due to the Qt rendering commands. Created attachment 34409 [details] [review] Remove false reduction of a composite to a blit Without sufficient information to go on, I am guessing that this is the likely cause. I pushed the fix for the broken blit... I hope this was the cause. commit 90a971c60769781f53827b469a9be3aab14cf71c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Mar 24 14:50:45 2010 +0000 uxa: Only reduce a composite to a BLT if it is wholly contained Hi Chris, I'm running the latest git master now, but I had to revert your commit "uxa: Default to using TILING_X for pixmaps." because it would crash X as soon as a modal dialog is shown (kwin compositing is set to fade out the parent of modal windows). Unfortunately there's no information about the cause, neither dmesg nor syslog nor Xorg.0.log. All I get is "xorg died unexpectedly". Want me to file a bug for this? BTW, I'm still running 2.6.33, will upgrade when I get the time. Is the "DebugFlushCaches" option still necessary/potentially helpful? I disabled it for now to try "uxa: Only reduce a composite to a BLT if it is wholly contained". Just tested 2.11.0 and at least with qtconfig-qt4 I don't experience any hangs anymore :) Thanks for fixing this issue! (In reply to comment #11) > I'm running the latest git master now, but I had to revert your commit > "uxa: Default to using TILING_X for pixmaps." > because it would crash X as soon as a modal dialog is shown (kwin compositing > is set to fade out the parent of modal windows). Unfortunately there's no > information about the cause, neither dmesg nor syslog nor Xorg.0.log. All I get > is "xorg died unexpectedly". Want me to file a bug for this? Hmm, yes. Nothing at all in dmesg or Xorg.log? I would have thought it was another GPU hang, but it might just be an X crash plain and simple. Refresh the packages on your system, just in case it's a silly build error and install a 2.6.34 kernel. The advantage of this kernel is that /sys/kernel/debug/dri/0/i915_error_state contains the broken batchbuffer making debugging much easier. It is worth filing a new bug if this persists after the refresh. > BTW, I'm still running 2.6.33, will upgrade when I get the time. Is the > "DebugFlushCaches" option still necessary/potentially helpful? I disabled it > for now to try "uxa: Only reduce a composite to a BLT if it is wholly > contained". No, I think the flushing is correct now and certainly nobody has reported anything recently that matches this style of bug. It looks like the qt4-config bug was related to one of the BLT fixes. Thank you both for testing, and I hope we get this kwin crash resolved quickly. (In reply to comment #13) > Hmm, yes. Nothing at all in dmesg or Xorg.log? I would have thought it was > another GPU hang, but it might just be an X crash plain and simple. Refresh the > packages on your system, just in case it's a silly build error and install a > 2.6.34 kernel. The advantage of this kernel is that > /sys/kernel/debug/dri/0/i915_error_state contains the broken batchbuffer making > debugging much easier. It is worth filing a new bug if this persists after the > refresh. Alright, it's gone. I updated to kernel 2.6.34-rc3 x11-proto/dri2proto-2.3 media-libs/mesa-7.8.1 x11-proto/xcb-proto-1.6 x11-libs/libxcb-1.5 and the latest git driver. I cannot reproduce the crash anymore. Thanks for fixing this issue and taking the time to support old hardware. |
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.