Summary: | i810/i915: X abort in I830WaitLpRing() w/ two DRI apps(gl-117+any) | ||
---|---|---|---|
Product: | xorg | Reporter: | Bernhard Kaindl <bkaindl> |
Component: | Driver/intel | Assignee: | Alan Hourihane <alanh> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | high | Keywords: | have-backtrace |
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
URL: | http://www.heptargon.de/gl-117/gl-117.html | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Bernhard Kaindl
2005-09-11 16:24:33 UTC
On starting the current Xorg CVS, I also get these kernel messages: mtrr: base(0xc0020000) is not aligned on a size(0x41a000) boundary mtrr: reg: 3 has count=0 mtrr: reg: 3 has count=0 mtrr: reg: 3 has count=0 mtrr: 0xc0000000,0x10000000 overlaps existing 0xc0000000,0x400000 Here is another backtrance, I got it while running the EXA patch while moving one DRI window above the other (the Composite extenion was also enabled): #0 0x405e4aec in I830EXACopy () from /usr/X11R6/lib/modules/drivers/i810_drv.so #1 0x4076eeba in exaCopyNtoN () from /usr/X11R6/lib/modules/libexa.so #2 0x4075559f in fbCopyRegion () from /usr/X11R6/lib/modules/libfb.so #3 0x4076e58c in exaCopyWindow () from /usr/X11R6/lib/modules/libexa.so #4 0x081710ee in cwCopyWindow () #5 0x0816c018 in damageCopyWindow () #6 0x081b13a2 in miSpriteCopyWindow () #7 0x405b62f7 in DRICopyWindow () from /usr/X11R6/lib/modules/extensions/libdri.so #8 0x08165f09 in compCopyWindow () #9 0x0819aff9 in miMoveWindow () #10 0x0816648f in compMoveWindow () #11 0x080df0cc in ConfigureWindow () #12 0x080c75c3 in ProcConfigureWindow () #13 0x080c7d52 in Dispatch () #14 0x080d4d55 in main () I also got this kernel message at the same time: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 2558 emitted: 2560 Alan, since you asked for a patch which supports DRI with EXA, this one works for me: http://ffii.org/~bkaindl/software/xorg/i830-exa-bkaindl-01.diff Do you have any idea on this bug, any hint what to do , what to look at, where it might be? May it be related to the Mesa memory corruption bug when moving gears (bug 4087)? I'm not sure what version of Mesa you are using, but I did do a quick sanity check on my hardware here and I can't replicate the problem at the moment. You might want to check out the Mesa 6.4 code and see if the fixes there help. Do you still have this problem with the stock X.org 6.9/7.0 driver ?? Try the current CVS versions of Mesa & Xorg and see if it helps your situation. Thanks, the X crash is fixed now. I did a quick test with the latest OpenSUSE-10.1 xorg-x11 rpms which use 6.9.0 (plus some patches to fix some bugs on top of it) from ftp://ftp4.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/RPMS.base I installed these packages using apt-get, if you need it for some other user, the best arting point to install/setup apt on any recent SuSE is http://susewiki.org/index.php?title=Install-apt4suse I used the xorg-x11-6.9.0-7 packages which have this changelog as the newest entry(just for my reference): * Mon Jan 16 2006 - sndirsch at suse.de - p_evdev_abs.diff: * adds support for absolute coordinate mice to evdev (Bug #142649) The X hang is gone, but when I start two GXL direct rendering apps at the same time, one does updates of screen in a correct way. Depending on the applications which I try to run in parallel, only one works while the other stops displaying or does only very incomplet drawing. With two glxgrears in parallel, I see their FPS at high numbers, which go back to normal numbers when only one glxgears runs, and while both glxgears are running, both glxgears windows go black. I don't need to run two DRI apps in parallel, but I am happy that the crash is fixed, that's more important... Of course some may like to at least run both, of course with severe performance degradiation because of task-switching and the additional loss of caching efficiency. On a NVIDIA 5200Go, when starting a second glxgear, the FTS drop from 2400 to 500 for both glxgears. I am impressed by the i915 DRI performance of the system now: On this Centrino, it's now possible to play certain missions of gl-116 in full quality and visibility with a resolution of 1400x1040 while frame rate always keeps in the playable range. I also should update the bugzilla (but don't want to do it this hour). I guess it's best to close the bug as resolved-fixed and report the DRI paralelism problem to the DRI people directly or just open a new bug about it. If I hear nothing I'll just mention the state which I have now and try to close the bug with resolved-fixed (if I can) and wait for your suggestion on what to do about the paralelism issue. That last comment was something that Bernhard sent via email to me. |
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.