Summary: | [G45 GEM] Cairo + Pango + Freetype Rendering in MPlayer Locks X | ||
---|---|---|---|
Product: | xorg | Reporter: | Dylan <d13f00l> |
Component: | Driver/intel | Assignee: | Eric Anholt <eric> |
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | critical | ||
Priority: | medium | Keywords: | NEEDINFO |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Dylan
2008-11-05 21:19:13 UTC
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.