[Intel-gfx] 945gm: xrandr crashes X
Hi, after upgrade to 2.6.34 kernel I'm unable to configure external VGA monitor anymore, any attempt to use xrandr results in X crash with following message: X: intel_bufmgr_gem.c:900: drm_intel_gem_bo_unreference_locked_timed: Assertion `((bo_gem-refcount)-atomic) 0' failed. There's a bug entry in gentoo bugzilla, however they blame xorg-server, but xorg-server-1.8.x works for me with 2.6.33.x kernel: http://bugs.gentoo.org/show_bug.cgi?id=318743 Is it known/fixed issue, or should I file a new bug on fd.o bugzilla? Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 945gm: xrandr crashes X
On Tue, 25 May 2010 10:38:51 +0300, Vasily Khoruzhick anars...@gmail.com wrote: Hi, after upgrade to 2.6.34 kernel I'm unable to configure external VGA monitor anymore, any attempt to use xrandr results in X crash with following message: X: intel_bufmgr_gem.c:900: drm_intel_gem_bo_unreference_locked_timed: Assertion `((bo_gem-refcount)-atomic) 0' failed. There's a bug entry in gentoo bugzilla, however they blame xorg-server, but xorg-server-1.8.x works for me with 2.6.33.x kernel: http://bugs.gentoo.org/show_bug.cgi?id=318743 Is it known/fixed issue, or should I file a new bug on fd.o bugzilla? commit 9f54107f866a25cf670f81f7c52b8c108728c6a5 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue May 11 14:55:16 2010 +0100 dri2: Handle reference counting across page flipping 1. Instead of swapping bos, swap the entire private structure. 2. If we update the pixmap bo for the Screen, make sure we update the reference inside intel-front_buffer so that xrandr still functions. Fixes: Bug 27922 - i965: Rapidly resizing OpenGL window causes GPU to hang. https://bugs.freedesktop.org/show_bug.cgi?id=27922 -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gen4: Extra CRT hotplug paranoia
On Mon, 2010-05-24 at 21:46 -0400, Andrew Lutomirski wrote: On Mon, May 24, 2010 at 4:46 PM, Adam Jackson a...@redhat.com wrote: Disable the CRT plug interrupt while doing the force cycle, explicitly clear any CRT interrupt we may have generated, and restore when done. Should mitigate interrupt storms from hotplug detection. Is there any locking in here to protect PORT_HOTPLUG_EN? I'm asking because I *still* can't use mainline kernels reliably without commenting out digital output initialization, and that's one place where a bug might be lurking. At least in d-i-n, PORT_HOTPLUG_EN is only ever written to from -detect in the connector vtable, and from IRQ setup. I don't have a firm understanding of the locking around either path, but I'd be rather surprised if it was racy in any practical sense, since neither of those should get called from interrupt context and you typically only have one app doing setup. - ajax signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gen4: Extra CRT hotplug paranoia
On Tue, May 25, 2010 at 10:46 AM, Adam Jackson a...@redhat.com wrote: On Mon, 2010-05-24 at 21:46 -0400, Andrew Lutomirski wrote: On Mon, May 24, 2010 at 4:46 PM, Adam Jackson a...@redhat.com wrote: Disable the CRT plug interrupt while doing the force cycle, explicitly clear any CRT interrupt we may have generated, and restore when done. Should mitigate interrupt storms from hotplug detection. Is there any locking in here to protect PORT_HOTPLUG_EN? I'm asking because I *still* can't use mainline kernels reliably without commenting out digital output initialization, and that's one place where a bug might be lurking. At least in d-i-n, PORT_HOTPLUG_EN is only ever written to from -detect in the connector vtable, and from IRQ setup. I don't have a firm understanding of the locking around either path, but I'd be rather surprised if it was racy in any practical sense, since neither of those should get called from interrupt context and you typically only have one app doing setup. -detect seems to be called from status_show in drm_sysfs.c, which makes its way into intel_crt_detect_hotplug, which plays with PORT_HOTPLUG_EN without any locking. If another detect function (or the same one, even) is called at the same time, PORT_HOTPLUG_EN can be left in a bad state. There should probably be a mutex protecting PORT_HOTPLUG_EN. --Andy - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 945gm: xrandr crashes X
On Tue, May 25, 2010 at 5:18 AM, Vasily Khoruzhick anars...@gmail.com wrote: I've updated my xf86-video-intel and libdrm and this issue gone, but now I hit another bug - one with VSYNC on 945GM :( Is there any way to disable vsync wait? (It's disabled in driconf, but for some reason it remains enabled in apps) Regards Vasily ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx Regurgitating something I read on irc: to disable vsync wait, set env var vblank_mode=0 (or is it 3?) you need git mesa in order for that to work: This commit http://cgit.freedesktop.org/mesa/mesa/commit/?id=45e2b51c853471b79004a954ce3092a253b20b77 enables using that env var. -- Alexander Lam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx