| Summary: | GPU lockup WAIT_FOR_EVENT on disabled pipe | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Bryce Harrington <bryce> | ||||||||||||||||
| Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> | ||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||||||||
| Severity: | major | ||||||||||||||||||
| Priority: | high | CC: | ben, bgamari, chris, daniel, devtry1, dries, eugeni, jbarnes, kamil.42920, leann.ogasawara, pcarns, przanoni | ||||||||||||||||
| Version: | unspecified | ||||||||||||||||||
| Hardware: | x86 (IA32) | ||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||
| See Also: | https://bugzilla.kernel.org/show_bug.cgi?id=43088 | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||
| Bug Blocks: | 42991, 44622 | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Bryce Harrington
2011-04-22 16:27:58 UTC
Created attachment 45980 [details]
BootDmesg.txt
Created attachment 45981 [details]
CurrentDmesg.txt
Created attachment 45982 [details]
CurrentDmesg.txt
Here are links to some of the i915_error_state files for the various (suspected dupe) bugs: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/767511/+attachment/2075462/+files/i915_error_state.txt https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/767425/+attachment/2074874/+files/i915_error_state.txt https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/760054/+attachment/2031475/+files/i915_error_state.txt https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/757968/+attachment/2019472/+files/i915_error_state.txt Bryce, one aspect that we are wary of with 965G[M] is that the early chipsets had severe issues with memory above 4G. It the memory configuration captured in the LP reports? The attached dmesg has 4G + PAE, is that common? One affected 965gm user here (bug report with attachments https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/771655) - 4GB of memory but no PAE, ie. 64-bit. On the other hand my problem, is simply X.org crashing/segfaulting, I don't get apport triggered for a GPU lockup bug report. So sorry for the (possible) noise, even though my problem is clearly coming from the same bunch of changes and is similarly random/rare. To make up for that, I went through the mentioned lockup bug reports to answer the question and: only two has PAE, four don't have PAE, but all those i965gm GPU lockup reports currently so far seem to be i686 unlike me. Created attachment 48039 [details] [review] Apply the big hammer to finish the fb before disabling it. Created attachment 48043 [details] [review] Apply the big hammer to finish the fb before disabling it. When flushing before disabling, it helps to do it before and not after the disable. Created attachment 48066 [details]
dmesg
I think I may have reproduced this same bug on my own i965 finally. Not sure exactly how I did it, but it showed up after a lid open event (resume from sleep I guess). The machine has been plugged into its docking station with external monitor continuously.
Created attachment 48067 [details]
i915_error_state
IPEHR=0x01820000
I was hoping to see the contents of the display registers in the error state to confirm the theory about the WAIT_FOR_EVENT being on a disabled pipe. Alas, that feature isn't part of that kernel. May I also make a polite request that you enable pageflipping once more ;-) I wonder if we should just be waiting for the VBLANK on a full screen blit rather than a range that is impossible. Hmm. *** Bug 35576 has been marked as a duplicate of this bug. *** *** Bug 37450 has been marked as a duplicate of this bug. *** A bug I reported (Bug 37450) has been marked as a duplicate of this bug, and this bug is marked as NEEDINFO. Since I can reproduce the bug I reported 100% of the time, please let me know if you would like me to provide any additional info. Kamil, can you try applying the patch https://bugs.freedesktop.org/attachment.cgi?id=48043 to your kernel and seeing if that is sufficient. I'm confident that's the fix, just waiting for testing. I applied the patch to 2.6.39.3 kernel, but it did *not* help. I'm seeing the same problem as before (enabling an output after suspend/resume hangs the server). Do I need to be running a newer kernel perhaps? xf86-video-intel: 2.15.0 xorg-server: 1.10.2 mesa: 7.10.3 libdrm: 2.4.26 kernel: 2.6.39.3 Do I need to be running a newer kernel perhaps? Sigh. After applying the patch can you post an i915_error_state. $ cat /sys/kernel/debug/dri/0/i915_error_state no error state collected That's after a restart of the X server (Ctrl-Alt-Bcksp) so that I can access the machine again; I assume that would not reset i915_error_state? The only indication in the logs I can see is in /var/log/Xorg.0.log: [ 259.306] (WW) intel(0): flip queue failed: Invalid argument [ 259.306] (WW) intel(0): Page flip failed: Invalid argument [ 260.299] (WW) intel(0): flip queue failed: Device or resource busy [ 260.299] (WW) intel(0): Page flip failed: Device or resource busy [last two lines repeating] These start occurring after I enable an output using xrandr (after a suspend/resume cycle); Xorg works for a while, but hangs immediately after I switch to a text console and back to X (a required action to actually see something via the new output, as per https://bugzilla.kernel.org/show_bug.cgi?id=24982). A workaround that works for me is to modify xf86-video-intel to force intel->use_pageflipping to FALSE. I believe there used to be a user-accessible option to turn it off, but it's been removed? That is rather unfortunate, I must say. I was just about to add that you hit kernel bug # 24982... So we can't tell if the GPU lockup itself has been fixed if the second prevents you from testing. Are you saying that *this* bug is probably fixed, but X still hangs because of the (unrelated) DPMS bug in the kernel? That could be, as I no longer see the GPU hung messages. Well, I guess all I can do at this point is sit and wait for that kernel bug to be fixed, hopefully some time soon; it's been open since last year... I'd be happy to try any patches you guys might have. Ok, to be really complicated, can you please retest this patch on top of keithp/drm-intel-fixes [ git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git]. Hopefully we have the modeswitching bug fixed and so we can then successfully test the WAIT_FOR_EVENT fix... Chris, drm-intel-fixes (last commit cda2bb78c24de7674eafa3210314dc75bed344a6) does *not* fix the modeswitching bug for me. I guess no point in retesting your patch then? The patch should prevent the GPU hang upon turning off a pipe, but it is a nuisance if the machine is dying for other reason we can't but sure that the patch is sufficient. Hi, does this still happens with the latest versions of the drivers, or it is not an issue anymore? Yes, the patch is still required, just no one has volunteered to test it. Well, I would've loved to test it, but I just tried kernel 3.1-rc10 and with vanilla xf86-video-intel 2.16.0 the kernel still crashes for me on enabling an output via xrandr. I assume it's due to the infamous kernel bug 24982, which has probably been open for a year now with no resolution in sight, though with kernel bugzilla apparently still being down (pathetic), it's hard to tell. For what it's worth, with your patch applied, the kernel seems to crash less easily for me than without it. (In reply to comment #27) > Well, I would've loved to test it, but I just tried kernel 3.1-rc10 and with > vanilla xf86-video-intel 2.16.0 the kernel still crashes for me on enabling an > output via xrandr. I assume it's due to the infamous kernel bug 24982, which > has probably been open for a year now with no resolution in sight, though with > kernel bugzilla apparently still being down (pathetic), it's hard to tell. bugzilla.kernel.org and that I'm currently unaware of any crash inside i915.ko, so you're going to have to remind me... (In reply to comment #28) > I'm currently unaware of any crash inside i915.ko, > so you're going to have to remind me... Chris, please see comment #19 in this bugzilla entry, or, for a complete description, see bug #37450. In essence, it seems that stale DPMS properties (kernel bug 24982), which normally just result in a blank screen, can in some situations result in a crash/hang. When I originally reported it I could only trigger it after suspend/resume; nowadays I can reproduce it just by repeatedly enabling and disabling an output a few times. The only workaround that works for me is modifying the xf86-video-intel driver to force page flipping off. (In reply to comment #29) > (In reply to comment #28) > > I'm currently unaware of any crash inside i915.ko, > > so you're going to have to remind me... > > Chris, please see comment #19 in this bugzilla entry, or, for a complete > description, see bug #37450. In essence, it seems that stale DPMS properties > (kernel bug 24982), which normally just result in a blank screen, can in some > situations result in a crash/hang. When I originally reported it I could only > trigger it after suspend/resume; nowadays I can reproduce it just by repeatedly > enabling and disabling an output a few times. The only workaround that works > for me is modifying the xf86-video-intel driver to force page flipping off. Ok, I think we know that bug and had a fix for the races inside the page-flipping code, but I think Keith dropped them on the floor... *** Bug 40526 has been marked as a duplicate of this bug. *** *** Bug 40527 has been marked as a duplicate of this bug. *** All our 4 duplicates were high/major. Adjusting. (clear needinfo) *** Bug 45000 has been marked as a duplicate of this bug. *** Hi Stuart, Per a recent request, I've built an Ubuntu test kernel based on the latest drm-intel-fixes branch (eg git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux.git drm-intel-fixes) and applied the patch noted in comment 16. If you could please test and post you results that would be great. Thanks in advance. http://people.canonical.com/~ogasawara/fdo36515/ *** Bug 40052 has been marked as a duplicate of this bug. *** *** Bug 48518 has been marked as a duplicate of this bug. *** I'm the original reporter of bug 48518. That is the description of my problem (on Ubuntu 12.04): I was working on an external monitor with my notebook. I changed the monitor settings to turn off the external monitor and turn on the notebook integrated monitor. When I applied the changes something went wrong: I couldn't see anything. Then I replugged the VGA cable for the external monitor and something appeared again, but it was all working strange and not as it should. Unfortunately I was working and I had to restart the computer; anyway nearly nothing worked: it was just a miracle that I managed to report the bug. I couldn't even open a terminal, I don't think I would have managed to take a screenshot. Neither I had a camera at hand to take a photo. I'll do my best to describe what I saw: - no launcher appearing when approching the left screen side - no panel (the top bar) - all the windows (which were already open) overlapping and cut - clicking on a window didn't cause it to appear on the foreground, but I was able to interact with the application program (write, click buttons) - no keyboard shortcut worked (at least not visibly); I tried using these: CTRL-ALT-T (to open a Terminal), Windows button (to open the Dash), ALT-F4 (to close windows) - I was able to drag the windows I didn't think about this when it happened: maybe even if I was "blind" everything was working and I could take a screenshot. Anyway it's too late and I'm still not sure I could. For further details please refer to "https://bugs.freedesktop.org/show_bug.cgi?id=48518" and the original Ubuntu bug report. If somehow I can help you, please let me know. Thank! I tried to reproduce the bug but without success: everything went right. devtry1, don't worry, you're not the only one with this problem. Given your extended description of the issue in comment #39, I would say Chris was right merging these two bug reports. I have sporadically seen what appears to be the same problem, only with KDE. The GPU will hung, the timer will time out and usually manage to reset the chip. In the process, however, the compositing window manager dies, so you no longer have control over window positions, desktop shortcuts, etc. For me the solution is generally to reboot, because even if I can successfully restart the X server, the GPU is in an ill-defined state so 3D acceleration doesn't work properly. I have not been able to find a reliable way of reproducing it; sometimes it "just happens", luckily, not very frequently. The first of the fixes has landed: commit 14667a4bde4361b7ac420d68a2e9e9b9b2df5231 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 3 17:58:35 2012 +0100 drm/i915: Finish any pending operations on the framebuffer before disabling Similar to the case where we are changing from one framebuffer to another, we need to be sure that there are no pending WAIT_FOR_EVENTs on the pipe for the current framebuffer before switching. If we disable the pipe, and then try to execute a WAIT_FOR_EVENT it will block indefinitely and cause a GPU hang. |
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.