Re: EFI and i915kms questions

On Saturday, November 28, 2015 04:50:41 PM Joe Maloney wrote:
> Thank you.  For what it’s worth I was able to grab a dump after setting that sysctl.  It looks like this maybe the culprit?
> 
> panic: _sx_xlock_hard: recursed on non-recursive sx gmbus _at_ /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:362
> 
> Since it is to large for posting here.  I will include a link to the entire dump on pastebin if anyone is interesting in looking at it.
> 
> http://pastebin.com/mzS5svy8
> 
> In addition I did a little further testing to narrow down the issue.
> 
> 10.1-RELEASE WORKS
> 10.2-RELEASE WORKS

Hmm, the relevant file (intel_iic.c) hasn't changed since 10.2.  However, the code looks
rather dubious.  It seems that the function is recursing onto itself here:

465 	  	  	        /*
466 	  	  	         * Hardware may not support GMBUS over these pins?
467 	  	  	         * Try GPIO bitbanging instead.
468 	  	  	         */
469 	  	  	        sc->force_bit_dev = true;
470 	dumbbell 	282199 	        error = -IICBUS_TRANSFER(idev, msgs, nmsgs);
471 	kib 	280369 	        goto out;


Note that at the top of the function it invokes IICBUS_TRANSFER on a different
device when force_bit_dev is true:

370 	  	  	        sx_xlock(&dev_priv->gmbus_sx);
371 	  	  	        if (sc->force_bit_dev) {
372 	dumbbell 	282199 	                error = -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
373 	kib 	235783 	                goto out;
374 	  	  	        }

Hmm, I would try changing the line at 470 to match the line at 372.

They used to match, and then this change:

https://svnweb.freebsd.org/base?view=revision&revision=277487

converted direct calls to an iic routine to IICBUS_TRANSFER.  However, it
also changed the first parameter of the IICBUS_TRANSFER() to idev at line 470
when it was the longer expression in the previous diff.

-- 
John Baldwin