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.
>
> 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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
