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 @ 
> /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.

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 
467                              * Try GPIO bitbanging instead.
468                              */
469                             sc->force_bit_dev = true;
470     dumbbell        282199          error = -IICBUS_TRANSFER(idev, msgs, 
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:


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
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to