| Summary: | [845] hang after VT switch (was xvideo crashes) | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Andrew Randrianasulu <randrik> |
| Component: | Driver/intel | Assignee: | Jesse Barnes <jbarnes> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | dmueller, foss-ml, rasasi78 |
| Version: | git | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 13027 | ||
| Attachments: | |||
Created attachment 11470 [details]
xorg.0.log
Created attachment 11471 [details]
xorg.conf, used at the same time
Created attachment 11479 [details]
x log with OVERLAY_DEBUG enabled
Created attachment 11481 [details]
new xorg log, with more debug uncommented
Now it DON'T crash!!!!
but on second run (after fresh server start, i don't need drm modules reloading) tvtime displays green color, mixed with TV image, and hw cursor looks like square with dynamic garbage inside it! I think writing log to disk slow down I830PutImage function, and this is enough for preventing crash. But image still incorrect ...
For me, last working driver was - 3655a1ecb62f6c387a16fa87cf6f00bf7835dce4. I can use it for watching video (i can use EXA and tiling, or XAA without tiling). Any newer version [after commit 9ad33dd65a79277ef75a6e95373614852725f5a9 " Use i830_memory.c instead of the AA's allocator for XV buffers. " ] will crash on second app's [mplayer -vo xv or tvtime] start. I'll look at changes and try to figure out what was done wrong. Created attachment 11483 [details]
even more debug
This bug is very hard. I can _sometimes_ relaunch tvtime up to 3 times, but _always_ got a crash at the end. Only one stable way for "reset" xvideo - server restart. And line in this log file ((II) intel(0): xf86UnbindGARTMemory: unbind key 4 ) just before correct xvideo restart makes me wonder if i should look at i830_memory.c and add some more debug output there .... May be my hardware (i845G) just broken for all those dynamic relocations. I'll try to find more. (try new kernel for example, 2.6.23. Bug stay with me on older kernels 2.6.19.7 and 2.6.17.14). I'll also try older patch, posted on mail list [solution for xv + xaa + tiling problem] and will write here about results, if any.
Yes! Old patch from Zhenyu Wang (Date: Sun, 12 Aug 2007 16:02:18 +0800 Subject: [PATCH] Use new memory for Xv buffer) works well! I can use composite, GL and xv at the same time, switch to/from vga console and all work! Patch was applied on top of this commit 3655a1ecb62f6c387a16fa87cf6f00bf7835dce4 Merge: e5c336e... 2231cdc... Author: Jesse Barnes <jbarnes@nietzche.virtuousgeek.org> Date: Thu Aug 16 12:04:20 2007 -0700 One observation - if i tried XAA - i get working XV but glxinfo fails with these lines in dmesg: [drm] Initialized drm 1.1.0 20060810 ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:02.0 to 64 [drm] Initialized i915 1.9.0 20070209 on minor 0 agpgart: pg_start == 0x0000003d,intel_i830_private.gtt_entries == 0x000007df agpgart: Trying to insert into local/stolen memory [drm:drm_agp_bind_ttm] *ERROR* AGP Bind memory failed [drm:drm_bind_ttm] *ERROR* Couldn't bind backend. [drm:drm_buffer_object_validate] *ERROR* Failed moving buffer. agpgart: pg_start == 0x0000003d,intel_i830_private.gtt_entries == 0x000007df agpgart: Trying to insert into local/stolen memory [drm:drm_agp_bind_ttm] *ERROR* AGP Bind memory failed [drm:drm_bind_ttm] *ERROR* Couldn't bind backend. [drm:drm_buffer_object_validate] *ERROR* Failed moving buffer. i'll test this patched driver more today. and report here about any bugs and crashes. Created attachment 11484 [details]
current xorg log, with patched driver
Created attachment 11485 [details]
xorg log after server crash with patched driver and XAA
---------from XAA crash log--------
(II) intel(0): Kernel reported 110336 total, 1 used
(II) intel(0): I830CheckAvailableMemory: 441340 kB available
(==) intel(0): VideoRam: 131072 KB
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(II) intel(0): Attempting memory allocation with tiled buffers and
large DRI memory manager reservation:
(II) intel(0): Allocating 5112 scanlines for pixmap cache
(II) intel(0): Attempting memory allocation with tiled buffers and
small DRI memory manager reservation:
(II) intel(0): Allocating 5112 scanlines for pixmap cache
(II) intel(0): Success.
(II) intel(0): Memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x00020000-0x00024fff: HW cursors (20 kB)
(II) intel(0): 0x00025000-0x0002cfff: logical 3D context (32 kB)
(II) intel(0): 0x0002d000-0x0003cfff: xaa scratch (64 kB)
(II) intel(0): 0x0003d000-0x0023cfff: DRI memory manager (2048 kB)
(II) intel(0): 0x007df000: end of stolen memory
(II) intel(0): 0x007df000-0x007dffff: overlay registers (4 kB, 0x000000001a46700
0 physical
)
(II) intel(0): 0x007e0000-0x00fd7fff: Xv linear (8160 kB)
(II) intel(0): 0x01000000-0x013fffff: back buffer (4096 kB) X tiled
(II) intel(0): 0x01400000-0x017fffff: third buffer (4096 kB) X tiled
(II) intel(0): 0x01800000-0x01bfffff: depth buffer (4096 kB) X tiled
(II) intel(0): 0x02000000-0x03ffffff: front buffer (24544 kB) X tiled
(II) intel(0): 0x08000000: end of aperture
--------------------------------------------------------------------------
Note, dri memory manager initialized inside stolen memory region.
Bug still present, (drm git commit 7fdf98051a51a0117f415f7f7374f2b4d0b2e531 mesa git commit 9944174abc546fe1845c26ce496edd747ad34347 xf86-video-intel git commit d02336290bea30de3c390b8121046c38fd6b0f62 ) for stable xv i need to re-apply xv patch on top of latest 2d driver from git, with manual conflict resolve. from dmesg: [drm] Initialized drm 1.1.0 20060810 ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:02.0 to 64 [drm] Initialized i915 1.10.0 20070209 on minor 0 eth0: no IPv6 routers present Generic RTC Driver v1.07 xorg.0.log will be attached in next message Created attachment 11526 [details]
xorg log with latest git + xv patch.
Hello, I think I'm also experiencing this. In order to check could you be so kind to include a core dump backtrace as explained here: http://wiki.debian.org/XStrikeForce/XserverDebugging This is mine's, but I'll warn you this was not with latest git, instead some weeks old and applied the patch stated here: https://bugs.freedesktop.org/show_bug.cgi?id=11432 #0 i830_free_memory (pScrn=0x8211af0, mem=0x8d01eb8) at ../../src/i830_memory.c:186 #1 0xb7b9063a in I830StopVideo (pScrn=0x8211af0, data=0x8255cfc, shutdown=1) at ../../src/i830_video.c:1018 #2 0x080db683 in xf86XVLeaveVT (index=0, flags=0) at ../../../../hw/xfree86/common/xf86xv.c:1262 #3 0xb7c2528f in glxDRILeaveVT (index=0, flags=0) at ../../../GL/glx/glxdri.c:839 #4 0x080a73cd in AbortDDX () at ../../../../hw/xfree86/common/xf86Init.c:1287 #5 0x081c5bc3 in AbortServer () at ../../os/log.c:407 #6 0x081c60c6 in FatalError (f=0x81d0dbc "Caught signal %d. Server aborting\n") at ../../os/log.c:553 #7 0x080c86a0 in xf86SigHandler (signo=11) at ../../../../hw/xfree86/common/xf86Events.c:1460 #8 0xffffe420 in ?? () #9 0x0000000b in ?? () #10 0x00000033 in ?? () #11 0xc0100000 in ?? () #12 0x0000007b in ?? () #13 0x0000007b in ?? () #14 0xb8881728 in ?? () #15 0xa822c000 in ?? () #16 0xbfc34b28 in ?? () #17 0xbfc348ec in ?? () #18 0xb7bb2808 in ?? () from /usr/lib/xorg/modules/drivers//intel_drv.so #19 0xb8881728 in ?? () #20 0x00000084 in ?? () #21 0xa822c000 in ?? () #22 0x0000000e in ?? () #23 0x00000006 in ?? () #24 0xb7daac9c in memcpy () from /lib/i686/cmov/libc.so.6 #25 0x00000073 in ?? () #26 0x00213206 in ?? () #27 0xbfc348ec in ?? () #28 0x0000007b in ?? () #29 0xbfc3466c in ?? () #30 0x00000000 in ?? () #0 i830_free_memory (pScrn=0x8211af0, mem=0x8d01eb8) at ../../src/i830_memory.c:186 186 mem->next->prev = mem->prev; 181 182 /* Disconnect from the list of allocations */ 183 if (mem->prev != NULL) 184 mem->prev->next = mem->next; 185 if (mem->next != NULL) 186 mem->next->prev = mem->prev; 187 188 /* Free any AGP memory. */ 189 i830_unbind_memory(pScrn, mem); 190 I will provide some more info after having checked that it's the same bug. Thanks looks similar to this debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441902 Created attachment 11735 [details]
Xorg.0.log
with latest xf86-video-intel git (commit ca67fa767dc762dac369e84b27a7ef15673d527c) and drm (commit 54df1b9ff3b79097fedd8ed7bf54aca30a660cbd) i haven't HW cursor anymore (red-and-black contour, transparent inside), no vt switch to vga console ("[drm:drm_bo_leave_list] *ERROR* A pinned buffer was present at cleanup. Removing flag and evicting." in dmesg and some errors in X.org.log. After this, i can't start X anymore, but text mode restored properly). Even first tvtime launch displays wrong picture. Should i rebuild X-server against new drm? I'll try this night.
Commit 130f79613bfe6a8cfa7f431c8cce06cbb93cc91a (Merge branch 'buffer-objects') broke HW cursor, vt switch and possible other things .. So, i think this is not just xvideo but more general - memory allocating bug. I'll enable debug messages and fill another bugreport. Can you close this one? I have some news regarding this bug. Once I updated to latest git, I had the following conclusions: · X no longer crashes no matter how many videos you play and stop. · If you change to a text terminal (1-6 usually) when you are playing video or after the video is stopped X will crash and will restart. (log and backtrace attached) · If after the previous restart you change to a text terminal again, the whole machine will hang at least in my case: Intel 855GME on a Dell Inspiron 510m running Debian Sid. Created attachment 12280 [details]
Xorg log with the crash info.
Created attachment 12281 [details]
Bactrace from the core dump using gdb.
Created attachment 12307 [details] [review] Fix for XV crash, as discussed with Keith P on the Xorg mailing list I would just like to point out that the backtrace Raul posted shows in fact the same crash I experience at switch to console, and which I've described at http://lists.freedesktop.org/archives/xorg/2007-October/029604.html I have posted register dumps at http://lists.freedesktop.org/archives/xorg/2007-November/029929.html Most noteably seems to be the difference in the VBLANK_A register. Maybe anyone can explain why xv modifies this register. http://wserver.wm1.at/~willi/xorg-dump2/ I've created a second series of dumps, it differs considerable from the first series of dumps, but the crash experience is the same. The file diff-series.txt contains the diff from dump to dump (perl is great). Change bug summary to "hang after VT switch" Tested patch on comment #19 and still experiencing the problem. BTW, Peter could you point me to the date where the patch was discussed in the Xorg ML? I can't manage to find it in my archive. Thanks. Raul: Peter Clifton is not on the CC: list. I think he meant the thread were this posting is in: http://lists.freedesktop.org/archives/xorg/2007-October/029162.html I experienced other XV crashes yesterday and today, which I've reported to https://bugs.freedesktop.org/show_bug.cgi?id=13108 (It's not Vt switch, it's looks like an issue with closing XV sessions when multiple players are involved) One more note. Bug title says this happens on 845, but I own a 855GME and the crash also happens. Me too, I own a 855GM (See the first link in Comment#20). Probably we are talking about two different bugs, as the backtrace of the crash as described by Raul and me looks similar and is very reproduceable, while the original report has a very different backtrace. Andrew, Raúl and Willi, please test the latest upstream bits. We've put in a lot of VT switch and video fixes lately... Created attachment 12416 [details]
current backtrace
177924e879564b7e9e70fd607141978bfd053fff still does not fix the issue. Current backtrace attached.
Tested again with 10988c5e6ec0f3c40d56bbf209b7976627cca706 (latest but one commit) and same crash, same behaviour, same backtrace. Ideas are welcome. This looks like 13177. Does it only happen after you've played a video and then switch VTs? There's a patch in that bug that may (if we're very lucky) fix the problem... Yes, only after using XV. (I haven't tested what happens when I switch VT while using XV) The patch in bug#13177 does not fix the issue for me. (same backtrace). But I'd happily test other shots in the dark if they bring us closer to fix for this issue. Just for completeness: I've just tested what happens when do the VT switch while playing (the first time in the session) video with XV: Same crash, same backtrace. *** This bug has been marked as a duplicate of bug 13177 *** Is this really VT switch specific ? I don't see what's VT switch related in the very first backtrace. Comment #12 talks about VT, but what does it have to do with the original report/backtrace ? I have got one report about driver 2.2.1 crashing with the same backtrace than in the original report when a fullscreen application starts. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472081 So either bug#13177 is not fixed, or this one is not a dupe (I vote for the latter). Well, the original backtrace doesn't give us much to go on. If you (or anyone else on this bug) is still seeing crashes, Xv related or not, please file a new bug with what info you have. There was another Xv fix recently as well for a crash in the XvPutImage path, so even if this isn't a DUP of 13177 it may be a DUP of the other one. Either way, let's just start a new bug if needed... |
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.
I'm using 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) (prog-if 00 [VGA]) Subsystem: Micro-Star International Co., Ltd. Unknown device 5808 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at d0000000 (32-bit, prefetchable) [size=128M] Memory at dff80000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 1 X server-1.4, kernel 2.6.21.7, drm/libdrm git (commit 06bb07259531d10df2c1979919af899e3812057b), xf86-video-intel git (commit 286f5df0b62f571cbb4dbf120679d3af029b8775). And with this combination i can use xvideo only once. If i start mplayer or tvtime twise - my screen go black, and i need reboot. from xorg.o.log (II) intel(0): xf86BindGARTMemory: bind key 5 at 0x000e0000 (pgoffset 224) (II) intel(0): xf86UnbindGARTMemory: unbind key 5 Backtrace: 0: /usr/X11/bin/X(xf86SigHandler+0x74) [0x80bc304] 1: [0xffffe420] 2: /usr/X11R7/lib/xorg/modules/drivers//intel_drv.so [0xa7bd9125] 3: /usr/X11/bin/X [0x80cf392] 4: /usr/X11R7/lib/xorg/modules/extensions//libextmod.so(XvdiPutImage+0x142) [0xa 7c66d32] 5: /usr/X11R7/lib/xorg/modules/extensions//libextmod.so [0xa7c694ae] 6: /usr/X11/bin/X [0x813e8d0] 7: /usr/X11/bin/X(Dispatch+0x3a1) [0x8085be1] 8: /usr/X11/bin/X(main+0x4a5) [0x806daa5] 9: /lib/tls/libc.so.6(__libc_start_main+0xd4) [0xa7d27e14] 10: /usr/X11/bin/X(FontFileCompleteXLFD+0x1f9) [0x806cfa1] Fatal server error: Caught signal 11. Server aborting full xorg.conf, Xorg.0.log will be attached. This bug present with EXA and XAA. Composite (both extension and compositing manager) disabled. Playing with options has no effect. Only one thing make real change - if i increase in BIOS setup shared memory size from 1Mb to 8Mb i can (sometimes) start tvtime twice without crash, but 2nd time i have piece of overlay instead of HW cursor! SW cursor doesn't help. And anyway i got my crash after 3d tvtime launch. Now i have XAA + composite manager active just for preventing xv from crashing my x server.