[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090202224448.b19eaca4.akpm@linux-foundation.org>
Date: Mon, 2 Feb 2009 22:44:48 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Daniel Vetter <daniel@...ll.ch>
Cc: Jesse Barnes <jbarnes@...tuousgeek.org>, airlied@...ux.ie,
eric@...olt.net, dri-devel@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: + drivers-gpu-drm-i915-intel_lvdsc-fix-locking-snafu.patch
added to -mm tree
(cc's added)
On Sat, 31 Jan 2009 16:25:08 +0100 Daniel Vetter <daniel@...ll.ch> wrote:
> On Thu, Jan 29, 2009 at 01:48:25PM -0800, Andrew Morton wrote:
> > On Thu, 29 Jan 2009 13:24:17 -0800
> > Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> > > On Thursday, January 29, 2009 12:50 pm akpm@...ux-foundation.org wrote:
> > > > diff -puN
> > > > drivers/gpu/drm/i915/intel_lvds.c~drivers-gpu-drm-i915-intel_lvdsc-fix-lock
> > > >ing-snafu drivers/gpu/drm/i915/intel_lvds.c ---
> > > > a/drivers/gpu/drm/i915/intel_lvds.c~drivers-gpu-drm-i915-intel_lvdsc-fix-lo
> > > >cking-snafu +++ a/drivers/gpu/drm/i915/intel_lvds.c
> > > > @@ -311,7 +311,7 @@ static int intel_lvds_get_modes(struct d
> > > > if (dev_priv->panel_fixed_mode != NULL) {
> > > > struct drm_display_mode *mode;
> > > >
> > > > - mutex_unlock(&dev->mode_config.mutex);
> > > > + mutex_lock(&dev->mode_config.mutex);
> > > > mode = drm_mode_duplicate(dev, dev_priv->panel_fixed_mode);
> > > > drm_mode_probed_add(connector, mode);
> > > > mutex_unlock(&dev->mode_config.mutex);
> > > > _
> > > >
> > > > Patches currently in -mm which might be from akpm@...ux-foundation.org are
> > >
> > > Oops. This should go upstream asap.
> >
> > yup, I'll send it later today hopefully.
>
> Thanks for the speedy fix. Unfortunately it looks like the locking in this
> area still doesn't quite work:
>
> Enabling kms works flawlessly now, but when I fire up X, the screen blanks
> (no more blinking cursors), then X hangs. vt-switchings doesn't work
> anymore, otherwise the machine looked fine (ping on the network was fine,
> couldn't check anything else for lack of a running sshd on the crashing
> machine). Twice using SysRq-T (half a minute in between) showed that Xorg
> was indeed stuck, both times with the exact same backtrace:
>
> Xorg D 00203246 6448 6049 6048
> f1c81df0 00203046 f6322720 00203246 f1c81de0 f83fb98d f6322720 f632297c
> 00203046 f1d88444 00203046 f2f63cc0 f8388dae f1d88444 ffffffff f1d88408
> 00203246 f1c81e2c c02e18ba f83fb98d 00000000 f6322720 f1d88430 f1d88444
> Call Trace:
> [<f83fb98d>] ? intel_lvds_get_modes+0x69/0x94 [i915]
> [<f8388dae>] ? drm_mode_getconnector+0x54/0x31f [drm]
> [<c02e18ba>] mutex_lock_nested+0x158/0x254
> [<f83fb98d>] ? intel_lvds_get_modes+0x69/0x94 [i915]
> [<f83fb98d>] intel_lvds_get_modes+0x69/0x94 [i915]
> [<f838a170>] drm_helper_probe_single_connector_modes+0xb8/0x194 [drm]
> [<f8388e20>] drm_mode_getconnector+0xc6/0x31f [drm]
> [<c02e13bc>] ? mutex_unlock+0xd/0xf
> [<f837f71f>] drm_ioctl+0x1c1/0x23d [drm]
> [<f8388d5a>] ? drm_mode_getconnector+0x0/0x31f [drm]
> [<f837f55e>] ? drm_ioctl+0x0/0x23d [drm]
> [<c0191277>] vfs_ioctl+0x43/0x56
> [<c0191a34>] do_vfs_ioctl+0x49f/0x4e0
> [<c0186c42>] ? vfs_write+0xf5/0x131
> [<c0191aba>] sys_ioctl+0x45/0x5f
> [<c0102e91>] sysenter_do_call+0x12/0x31
>
> This is on 2.6.29-rc3-00100-gf2257b7.
>
So I assume that it would make sense to track this as a post-2.6.28
regression?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists