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? > Who has that reference? It's not sysfs, right? Or is it? How is the > remove method being called, is that coming from a sysfs file? > No, it’s not sysfs. Sysfs is not used at all. The remove method of the mux gets called and on it’s remove method i2c_del_mux_adapter is called, which in turn calls i2c_del_adapter() which hangs. Anyway, finally figured out what the problem was, a reference was held, and not released properly in the i2c notifier pathc. I’ll send out an updated patch later today. > Having that call "wait" for the other release call to happen is really > old, as Jean points out, from 2003. We have "fixed" sysfs since then to > detach the files from the devices easier, we used to have some nasy > reference count issues in that area. Perhaps this isn't needed anymore, It’s awfully easy to get a hang with this blocking wait. Turns a memory leak into a hard hang. > I don't remember the i2c core code at all, that was a long time ago. > Bummer. > 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
