|
Bugzilla – Full Text Bug Listing |
| Summary: | radeonhd[r5xx] engine lockup when using dri application and render/tv | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Luc Verhaegen <lverhaegen> |
| Component: | X.Org | Assignee: | Egbert Eich <eich> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | bitdealer, eich, forgotten_99jW5vq2hJ, jslaby, sndirsch |
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
*** Bug 449454 has been marked as a duplicate of this bug. *** Is this still an issue with latest xradeon driver release 1.2.5 available via http://download.opensuse.org/repositories/X11:/Drivers:/Video/ (package: xorg-x11-driver-video-radeonhd)? The lockup reported in bug #449454 still occurs with the 1.2.5 package. *** Bug 548060 has been marked as a duplicate of this bug. *** *** Bug 542453 has been marked as a duplicate of this bug. *** This issue is probably fixed. ------------------------------------------------------------------- Fri Nov 6 14:24:21 CET 2009 - eich@suse.de - Updated driver: * Fix 2D/3D engine lockups. http://download.opensuse.org/repositories/X11:/Drivers:/Video/openSUSE_Factory/i586/xorg-x11-driver-video-radeonhd-1.3.0_20091106_619706-2.1.i586.rpm http://download.opensuse.org/repositories/X11:/Drivers:/Video/openSUSE_Factory/x86_64/xorg-x11-driver-video-radeonhd-1.3.0_20091106_619706-2.1.x86_64.rpm Can you confirm? Looks good here. So let's close it finally as fixed. |
It is still possible to have the engine lock up on us when using both a dri application and a high frequency direct 3D engine user in the xserver. One good test is running keithp's xvtest at blink setting (feeding frames to the hw as fast as the system can handle) while running the likes of glxgears. After a while, all the dma buffers will be used as the engine has stopped processing them, stuck on another command. The xserver then sits around and waits for a dmabuffer to become available. And this can take quite a long time... #0 0x00007f29bc9d9537 in ioctl () from /lib64/libc.so.6 #1 0x00007f29bc2dea0d in drmDMA () from /usr/lib64/libdrm.so.2 #2 0x00007f29bb620003 in RHDDRMCPBuffer (scrnIndex=0) at rhd_dri.c:1874 #3 0x00007f29bb5f9cc0 in DRMCPGrab (CS=0x814ce0, Count=3225445417) at rhd_cs.c:372 #4 0x00007f29bb61c54e in rhdPutImageTextured (pScrn=0x7fcb90, src_x=<value optimized out>, src_y=<value optimized out>, drw_x=415, drw_y=323, src_w=256, src_h=256, drw_w=256, drw_h=256, id=844715353, buf=0x7f29be8f8e38 "�", width=256, height=256, sync=0, clipBoxes=0x7fffc69d6ae0, data=0x849188, pDraw=0xb775b0) at rhd_video.c:333 #5 0x0000000000491efe in xf86XVPutImage (client=<value optimized out>, pDraw=0xb775b0, pPort=0x849c90, pGC=<value optimized out>, src_x=25641, src_y=26720, src_w=256, src_h=65520, drw_x=0, drw_y=0, drw_w=<value optimized out>, drw_h=<value optimized out>, format=0x8499d0, data=0x7f29be8e9038 "�", sync=0, width=<value optimized out>, height=<value optimized out>) at xf86xv.c:1767 #6 0x00007f29bbcc7a14 in ProcXvPutImage (client=0xb42810) at xvdisp.c:1080 #7 0x000000000044beb4 in Dispatch () at dispatch.c:454 #8 0x000000000043231d in main (argc=3, argv=0x7fffc69d6d68, envp=<value optimized out>) at main.c:441 A known issue is the 3DEngineInit in the xserver. This sets up the engine to perform the operations needed by the xserver, and when ran at too high a frequency, this is known to lock up the engine. If no DRI client is running, this initialization is run only once. But when a dri client runs, the xserver is constantly switching context and therefor reinitializing the engine all the time. The backtrace that Jiri provided in bug #443459 points at something different, and might be more closely related to the dri driver, as the xserver is waiting to get the drmlock from the kernel in this case: ... (mieqEnqueue stuff) 7: /lib64/libc.so.6 [0x7fd7cd4b07b0] 8: /lib64/libc.so.6(ioctl+0x7) [0x7fd7cd54c6c7] 9: /usr/lib64/libdrm.so.2 [0x7fd7cc1b2ca3] 10: /usr/lib64/libdrm.so.2(drmGetLock+0x67) [0x7fd7cc1b37f7] 11: /usr/lib64/xorg/modules//extensions/libdri.so(DRILock+0xed) [0x7fd7cc3bddad] 12: /usr/lib64/xorg/modules//extensions/libdri.so(DRIDoWakeupHandler+0x3d) [0x7fd7cc3bde0d] 13: /usr/lib64/xorg/modules//extensions/libdri.so(DRIWakeupHandler+0x66) [0x7fd7cc3bcdf6] 14: X(WakeupHandler+0x4b) [0x44fa3b] 15: X(WaitForSomething+0x1df) [0x4e8d3f] 16: X(Dispatch+0x7f) [0x44bbcf] 17: X(main+0x45d) [0x43231d] 18: /lib64/libc.so.6(__libc_start_main+0xe6) [0x7fd7cd49c586] 19: X [0x4316f9] Maybe we just aren't ready yet to run DRI clients on r5xx hw :)