Hi Greg, > On Jan 16, 2015, at 00:55 , Greg Kroah-Hartman <gre...@linuxfoundation.org> > wrote: > > On Thu, Jan 15, 2015 at 06:25:22PM +0200, Pantelis Antoniou wrote: >> Hi Greg, >> >>> On Jan 14, 2015, at 22:41 , Greg Kroah-Hartman <gre...@linuxfoundation.org> >>> wrote: >>> >>> On Wed, Jan 14, 2015 at 07:24:22PM +0200, Pantelis Antoniou wrote: >>>> I’ll try to dig around tomorrow and see what the real device reference >>>> counts >>>> are, but my hunch goes like this: >>>> >>>> MUX >>>> +—- ADAPTER >>>> +— DEV. >>>> >>>> Mux remove method is called, i2c_del_mux_adapter is called on all the >>>> channels >>>> of the mux, calling in turn i2c_del_adapter which hangs on completion of >>>> the >>>> dev_released. >>>> >>>> The call to device_unregister never calls the device_type callback >>>> (i2c_adapter_dev_release) >>>> because the reference count is not 1 at that point, someone else is having >>>> another >>>> reference. >>> >> >> First of all, my head hurts. Tracking device references ain’t easy. Is there >> some kind >> of debugging method you’d recommend for this? > > You can turn on debugging for kobjects and the driver core if you want > to slow down your system log a bunch, but it can be helpful for trickier > issues. Or just sprinkle a few printks around. >
Turning on debugging for kobjects is like opening the floodgates… I managed to make do with a few printks, but some kind of tracking would be helpful. >>> I don't remember the i2c core code at all, that was a long time ago. >>> >> >> Bummer. > > Do you remember code you wrote 12 year ago and haven't looked at for at > least 11? Why expect others to as well? :) > You’re supposed to be a super-hero maintainer god right? How am I supposed to continue living with my belief system crumbled like that? :) > thanks, > > greg k-h Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
