X also locks by playing videos in mplayer w/ ogl output, but ONLY with subtitles on. Unable to reproduce with subtitles off. Happens if I scroll around a video with subtitles back and forth for like 30 seconds, but can happen during normal play. Fonts glitch in the window, may turn black or solid white. Tried updating pango, freetype, and cairo libraries, still the same problem. This is pretty much the last show stopping problem for me on G45, and it does cause X to lock. The hardware will get wedged and a reboot will be required. Did not have the problem on 2.4.1 non GEM. I'm on anholt's review tree, last patch. i915: Add /proc debugging entry for reading out the HWS. Backtrace of X 1. (gdb) bt 2. #0 0xb7bf7ca4 in ioctl () from /lib/libc.so.6 3. #1 0xb7ae841f in drmIoctl (fd=11, request=1074029637, arg=0xbfbd4ba4) 4. at xf86drm.c:183 5. #2 0xb7ae84d1 in drmCommandWrite (fd=11, drmCommandIndex=5, data=0xbfbd4ba4, 6. size=4) at xf86drm.c:2343 7. #3 0xb7a560c4 in I830Sync (pScrn=0x8222588) at i830_accel.c:214 8. #4 0xb7a7dcf9 in I830EXASync (pScreen=0x8263ad0, marker=0) at i830_exa.c:170 9. #5 0xb777746d in exaWaitSync () from /usr/lib/xorg/modules//libexa.so 10. #6 0xb777866e in ExaDoPrepareAccess () from /usr/lib/xorg/modules//libexa.so 11. #7 0xb777bb52 in exaCopyDirty () from /usr/lib/xorg/modules//libexa.so 12. #8 0xb777c07f in exaDoMoveInPixmap () from /usr/lib/xorg/modules//libexa.so 13. #9 0xb777c868 in exaDoMigration () from /usr/lib/xorg/modules//libexa.so 14. #10 0xb777de41 in exaTryDriverComposite () 15. from /usr/lib/xorg/modules//libexa.so 16. #11 0xb777e7e1 in exaComposite () from /usr/lib/xorg/modules//libexa.so 17. #12 0x0817693a in damageComposite () 18. #13 0x0815ee43 in CompositePicture () 19. #14 0x08164df8 in ProcRenderComposite
I set pci=nomsi in my kernel config, I had to do this for a while for my SATA controller to work at all, I thought I'd try it again for giggles. MPlayer is rendering correctly now, I'm unable to reproduce the problem. Is this something that can be fixed in the Intel driver? I posted this to DRI-DEVEL Hi all, I posted a bug a while ago https://bugs.freedesktop.org/show_bug.cgi?id=18402 I'm using anholt's for review kernel, on a p5q-EM board with 3 gigs of ram and a dual core CPU, with dual screens. In i830_accel, when I830Sync is called, an IRQ is emitted and then immediately waited on. In static int i915_wait_irq(struct drm_device * dev, int irq_nr) in DRM, with debugging on, it can show the IRQ NR it's waiting on. If I modprobe drm with debug, I get those debugging messages, But if I do this, I'm unable to reproduce this error!?! If I hold down J in mplayer, freetype renders text, and sometimes its drawn to the screen incorrectly, totally solid black, or corrupted...and X can lock. If I have debug on, it's always rendered correctly, and I'm unable to get X to lock. It's like IRQs are being missed? Does anyone have any idea what could be going on here? Thanks!
Disabling MSI drastically decreases how often this happens in SD video with subtitles, but if I play 720P video with subtitles, I can quickly still reproduce.....dang it! Dylan
DANG IT!!!!!!!! After using X for a while...in dmesg irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.28-rc3-08318-g679a6e0 #2 Call Trace: [<c0142de0>] __report_bad_irq+0x24/0x69 [<c0142de7>] __report_bad_irq+0x2b/0x69 [<c0142f10>] note_interrupt+0xeb/0x143 [<c014343f>] handle_fasteoi_irq+0x7e/0x9b [<c0104a97>] do_IRQ+0x89/0xa2 [<c0103afb>] common_interrupt+0x23/0x28 [<c0107d50>] mwait_idle+0x2f/0x32 [<c0102143>] cpu_idle+0x68/0x81 handlers: [<c033862b>] (ata_sff_interrupt+0x0/0x1fa) [<c036d7a9>] (usb_hcd_irq+0x0/0x59) [<f85c1ea1>] (i915_driver_irq_handler+0x0/0x153 [i915]) Disabling IRQ #16 Vsyncs are slow now in nomsi mode. No idea what caused this, I was in X for a few hours and noticed this in my dmesg.
This doesn't happen at all with OpenGl 2 output from mplayer. I don't get the text rendering glitches either. Only happens with regular GL output.
Now on GIT Xorg stack, rebuilt anholt kernel again, git libdrm, xf86-video-intel, mesa, etc, mplayer cpu usage is down ~20% in GL output mode VERY hard to reproduce in a blackbox session, doing a BT on X when it locks shows #0 0xb7b48ca4 in ioctl () from /lib/libc.so.6 #1 0xb79fd36f in drmIoctl () from /usr/lib/libdrm.so.2 #2 0xb79fd424 in drmCommandWrite () from /usr/lib/libdrm.so.2 #3 0xb7971e07 in I830Sync () from /usr/lib/xorg/modules/drivers//intel_drv.so #4 0xb79a2c7a in I830EXASync () from /usr/lib/xorg/modules/drivers//intel_drv.so #5 0xb76aa7b5 in exaWaitSync () from /usr/lib/xorg/modules//libexa.so #6 0xb76ab9ee in ExaDoPrepareAccess () from /usr/lib/xorg/modules//libexa.so #7 0xb76abafb in exaPrepareAccessReg () from /usr/lib/xorg/modules//libexa.so #8 0xb76ac122 in exaImageGlyphBlt () from /usr/lib/xorg/modules//libexa.so #9 0x0817d4fe in damageText () #10 0x0817d6d4 in damageImageText8 () #11 0x0808c4a0 in doImageText () #12 0x0808c695 in ImageText () #13 0x080872b6 in ProcImageText8 () #14 0x08089b3f in Dispatch () #15 0x0806e3ed in main () Disabled Damage was not able to reproduce after that HOWEVER if I go into an xfce session and run apps, firefox, purple, etc, the lockup is quickly reproduced.... This must have something to do with EXA and GL trying to write to the hardware at the same time somehow.... Has anyone from intel reproduced this...? Any feedback? Please? Thanks. :)
For GPU hangs, we need the output of intel_gpu_dump when you reproduce the hang on kernel 2.6.30-rc4 or newer to figure out what's wrong in what we sent to the hardware.
Dylan, we have many fixes for such gpu hang in the latest xf86-video-intel driver and kernel. Could you try that? If it still exists, please provide intel_gpu_dump according to http://intellinuxgraphics.org/intel-gpu-dump.html.
Feedback timeout. Things appear to work correctly today -- mplayer -vo gl ~/big_buck_bunny*ogg -sub ~/some-subfile.sub and holding down the J key for a minute worked fine.
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.