Ubuntu Wily / VMWare graphics boot regression

[Sinclair Yeh]

Hi,

I was able to reproduce this last night after updating 15.10, and I
didn't know what the cause was until your mail.

Let me try a 4.2 kernel with lockdep check enabled and see if I can
spot anything.

Thomas' in a different time zone, so he may also pick this up in
his morning.

Sinclair

On Wed, Feb 24, 2016 at 02:42:10PM -0800, Kamal Mostafa wrote:
> Hi Thomas, Sinclair, and my team-
> 
> Here's a weird one.  It appears that this Linux commit which was
> recently applied to Ubuntu Wily 15.10 (via 4.2-stable):
> 
>   [mainline] 025af18 drm/ttm: Fixed a read/write lock imbalance
> 
> is the trigger for this rather major Ubuntu/VMWare graphics boot
> regression:
> 
>   https://bugs.launchpad.net/ubuntu/wily/+source/linux/+bug/1548587
>   Ubuntu 15.10 VMWare guest won't show UI after upgrading to 4.2.0-30
> 
> (In Comment #33 I produced a test kernel with that commit reverted  
> which was confirmed as fixing the regression).
> 
> 
> But the thing is...
> 
> 025af18 (attached) just looks so *obviously* valid, in that the thing
> it fixes looks like it was obviously wrong.  I was reluctant to even
> try reverting it, and was surprised when multiple testers confirmed
> that it fixed the problem.
> 
> Furthermore, backports of 025af18 have been deployed in many other
> stable kernels (and of course, mainline) but the reported boot problem
> ** only seems to occur with v4.2-based kernels **.  The problem does
> occur with 4.2-stable (including the 025af18 backport), but does _not_
> occur with a 4.4 kernel (which always contained 025af18).  That commit
> been shipping in pre-4.2 Ubuntu Trusty and Vivid for at cycle or two
> with no reports of problems there either.
> 
> So despite the indication that 025af18 is the troublemaker for 4.2-
> stable based kernels, I'm not very happy with the idea of just
> reverting it from 4.2-stable or from Wily without a better
> understanding of why.
> 
> Any thoughts on this topic will be much appreciated.
> 
>  -Kamal

> From 025af189fb44250206dd8a32fa4a682392af3301 Mon Sep 17 00:00:00 2001
> From: Thomas Hellstrom <thellstrom at vmware.com>
> Date: Fri, 20 Nov 2015 11:43:50 -0800
> Subject: drm/ttm: Fixed a read/write lock imbalance
> 
> In ttm_write_lock(), the uninterruptible path should call
> __ttm_write_lock() not __ttm_read_lock().  This fixes a vmwgfx hang
> on F23 start up.
> 
> syeh: Extracted this from one of Thomas' internal patches.
> 
> Cc: <stable at vger.kernel.org>
> Signed-off-by: Thomas Hellstrom <thellstrom at vmware.com>
> Reviewed-by: Sinclair Yeh <syeh at vmware.com>
> ---
>  drivers/gpu/drm/ttm/ttm_lock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_lock.c b/drivers/gpu/drm/ttm/ttm_lock.c
> index 6a95454..f154fb1 100644
> --- a/drivers/gpu/drm/ttm/ttm_lock.c
> +++ b/drivers/gpu/drm/ttm/ttm_lock.c
> @@ -180,7 +180,7 @@ int ttm_write_lock(struct ttm_lock *lock, bool interruptible)
>  			spin_unlock(&lock->lock);
>  		}
>  	} else
> -		wait_event(lock->queue, __ttm_read_lock(lock));
> +		wait_event(lock->queue, __ttm_write_lock(lock));
>  
>  	return ret;
>  }
> -- 
> 2.7.0
>