Summary: | xf86-video-intel-2.6.3: Xv crashes X server | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Bob Raitz <pappy_mcfae> | ||||||
Component: | Driver/intel | Assignee: | Wang Zhenyu <zhenyu.z.wang> | ||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | eric, remi | ||||||
Version: | 7.4 (2008.09) | ||||||||
Hardware: | x86 (IA32) | ||||||||
OS: | Linux (All) | ||||||||
URL: | http://bugs.gentoo.org/show_bug.cgi?id=261531 | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 20276 | ||||||||
Attachments: |
|
Description
Bob Raitz
2009-03-07 12:10:50 UTC
Please attach Xorg.0.log. Are you able to use git-bisect to find which commit breaks? (In reply to comment #1) > Please attach Xorg.0.log. > In functional (2.6.1) and non-functional (2.6.3) forms? If so, I'll send the good one first, since I'm currently up on that machine, and it's running the functional driver. > Are you able to use git-bisect to find which commit breaks? > Not quite sure what that means. 2.6.2 worked, 2.6.3 didn't. Give me a git url, and I'll see what I can find. Attachment to follow... Created attachment 23648 [details]
Xorg.0.log under intel-2.6.1
Xorg.0.log with everything working right, and xf86-video-intel-2.6.1
Created attachment 23649 [details]
Xorg.0.log under intel-2.6.3, with various errors.
The machine in question is currently showing a black screen. I can ssh to it, and this is the file that was created as soon as things crashed. I think it's pretty interesting there at the end.
Could you get gdb backtrace? (In reply to comment #2) > (In reply to comment #1) > > Are you able to use git-bisect to find which commit breaks? > > > Not quite sure what that means. 2.6.2 worked, 2.6.3 didn't. Give me a git url, > and I'll see what I can find. > here are some tutorial about how to use git bisect. if it works on 2.6.2 while breaks on 2.6.3, it won't take long to pin which commit is the culprit... http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html I am currently ironing out problems getting the Gentoo ebuild to work with git. I am hoping to get things going tomorrow. (In reply to comment #5) > Could you get gdb backtrace? > No accelerated IMDCT transform found (EE) intel(0): Failed to pin xv buffer X Error: BadAlloc (insufficient resources for operation) 11 Major opcode: 140 Minor opcode: 19 Resource id: 0x3e00001 Backtrace: 0: X(xorg_backtrace+0x3c) [0x8124950] 1: X(xf86SigHandler+0x4e) [0x80c48ca] 2: [0xffffe400] 3: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb79a125e] 4: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb79a3ecf] 5: X [0x80b36de] 6: /usr/lib/xorg/modules/extensions//libextmod.so(XvdiPutImage+0x174) [0xb7a0e30a] 7: /usr/lib/xorg/modules/extensions//libextmod.so [0xb7a11c05] 8: /usr/lib/xorg/modules/extensions//libextmod.so(ProcXvDispatch+0x35) [0xb7a12fec] 9: X(Dispatch+0x33d) [0x8087cea] 10: X(main+0x457) [0x806f02d] 11: /lib/libc.so.6(__libc_start_main+0xd5) [0xb7a82715] 12: X [0x806e461] Fatal server error: Caught signal 11. Server aborting kdeinit: Fatal IO error: client killed I get this after X dies. Still working out the git problems. # git bisect start # git bisect good xf86-video-intel-2.6.1 # git bisect bad 2.6.2 Bisecting: 22 revisions left to test after this [8cb4d68089109f6cef0ce94429ba6f944910c646] Quirk MSI IM-945GSE-A LVDS, TV outputs. # git bisect good Bisecting: 11 revisions left to test after this [173270d49f218b7bcae7f887dd9e2d23343c6070] KMS: Hook up crtc::gamma_set. (cherry picked from commit 723b6065093adb56a2d7204bd990ceae41bfafc9) # git bisect good Bisecting: 5 revisions left to test after this [6314b9178a252292a79e21a64d47d740e23df28d] uxa: Ask for BOs ready for rendering for pixmaps. # git bisect bad Bisecting: 2 revisions left to test after this [3937756ae4cae78b6c6c72714ac8898f155844f6] Fix i915 textured video to work with the i830_memory -> bo change. Should I follow it to the very end, or is this what you wanted? # git bisect bad Bisecting: 0 revisions left to test after this [be56ce2c4cdeabaf655c53ca177ec35b8536bd9b] Make Xv used a buffer object instead of i830_memory. # git bisect bad be56ce2c4cdeabaf655c53ca177ec35b8536bd9b is first bad commit commit be56ce2c4cdeabaf655c53ca177ec35b8536bd9b Author: Kristian Høgsberg <krh@redhat.com> Date: Wed Feb 18 17:26:06 2009 -0500 Make Xv used a buffer object instead of i830_memory. We still pin the buffer object in case of overlay, but for textured video we're now no longer using i830_memory for Xv anymore. (cherry picked from commit 872aadc7102bd5131e1582ede081e22672911ba2) :040000 040000 322035cc99ace724f09bed12c55913c5227a1c8b 83814192ca02cdd2759c46d134c25b7d9c793457 M src Confirming on my 855GM laptop with any app that uses Xv (totem and mplayer in my tests). Reverting the following four patches on top of 2.6.3 works around the issue for now (I did those four to avoid merge conflicts) : - "Access the Xv buffer through the GTT for the non-KMS case." - "Fix i915 textured video to work with the i830_memory -> bo change." - "Dont allocate overlay registers in KMS mode." - "Make Xv used a buffer object instead of i830_memory." Is it safe to assume overlay Xv is broken on all pre-965 chips? Thanks Does this also happen on 2.7 or master branch? If so, I'd suggest increasing priority. Does this fixed by commit 2026c57cf0a352d9e6f9d208cfb7d4d550614477 Author: Kalev Lember <kalev@smartlink.ee> Date: Fri Mar 13 21:32:08 2009 +0200 Fix Xv crash with overlay video. Bug #20585. (In reply to comment #12) > Does this fixed by > commit 2026c57cf0a352d9e6f9d208cfb7d4d550614477 > Author: Kalev Lember <kalev@smartlink.ee> > Date: Fri Mar 13 21:32:08 2009 +0200 > > Fix Xv crash with overlay video. > > Bug #20585. > Thanks Zhenyu, that indeed fixes the crashes for me. Could this patch be nominated for the 2.6 and 2.7 branches as well? Thanks yeah, this bug has already blocked 2.7. And you can put it back to 2.6 for your dist. Thanks for verify, close. Thanks for letting me do the testing for this. It was fun once I figured out what was happening. Please re-open. xf86-video-intel-2.6.3-r1 causes the same issues, with the exception of not showing a green screen. It still causes locks coming out of X, and my computer with an i830 video chipset fails attempting to play a DVD. Things remain workable with xf86-video-intel-2.6.1. Could you test with git master to see if this's fixed upstream? (In reply to comment #17) > Could you test with git master to see if this's fixed upstream? > I thought the error was already found. As far as I can see, it's the same error I was dealing with when I started this report. The only difference is the green screen is gone. The i830 machine dies whenever DVD play starts (original complaint), caused by whatever commit was nailed down as the root cause. The other machine loses display coming out of X. No return of the frame buffer at all. The machine can be rebooted via ssh, or by a press of the power button. ACPI is a good thing. The issue remains on 2.6.3 branch with the i965 video. I've bisect the failed patch. # git bisect start # git bisect good xf86-video-intel-2.6.1 # git bisect bad 2.6.3 I find this commit : 8ef4eb50193a849cb9fd0d7a85c6814e1d473101 is first bad commit commit 8ef4eb50193a849cb9fd0d7a85c6814e1d473101 Author: Eric Anholt <eric@anholt.net> Date: Mon Jan 19 14:43:20 2009 -0800 Do check_aperture_space and batch_start_atomic for i965 video. The previous fix to this bug only fix i945 video. (I think, I can't test it, I've got only a i965) commit 2026c57cf0a352d9e6f9d208cfb7d4d550614477 Author: Kalev Lember <kalev@smartlink.ee> Date: Fri Mar 13 21:32:08 2009 +0200 Fix Xv crash with overlay video. Can I reopen the bug ? How can I help more ? (In reply to comment #19) > Can I reopen the bug ? How can I help more ? Let's keep the issues separate, please open a new bug with the information you've found so far, it'll make it easier to help. Don't forget to add "remi@gentoo.org" as a CC on that bug. Thanks |
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.