USB stack getting confused

[Konstantin Belousov]

On Sat, Mar 09, 2019 at 04:42:50PM +0100, Hans Petter Selasky wrote:
> On 3/9/19 4:26 PM, Konstantin Belousov wrote:
> > On Sat, Mar 09, 2019 at 08:59:30PM +1030, O'Connor, Daniel wrote:
> >>
> >>
> >>> On 9 Mar 2019, at 19:30, Hans Petter Selasky <hps at selasky.org> wrote:
> >>> On 3/9/19 12:08 AM, O'Connor, Daniel wrote:
> >>>> My program normally runs continually doing acquisitions of data for N seconds, doing some checks and restarting. After a while (~30 1 minute acquisitions or ~8 30 minute ones) my program can't 'see' the device (it uses libusb10) any more (it reconnects each acquisition for $REASONS). Also pretty weirdly usbconfig can't see it either(!).
> >>>
> >>> What is printed in dmesg? Maybe the device has a problem.
> >>
> >> There is nothing in dmesg - no disconnect / reconnect etc.
> >>
> >> If I hold the user space process in gdb 'forever' (eg over night) usbconfig doesn't see the device, but the moment I quit the user space process it can be seen again.
> > 
> > Does it mean that the file descriptor opened for ugen has a chance to
> > be closed ?
> 
> The USB stack will wait for all FDs to be closed during detach also via 
> destroy_dev().
So my guess was correct.  Do you agree that this behaviour is wrong ?

In fact I saw something similar with apcupsd and either usb/com adapters
or native usb control card for APC UPSes.  For reasons I do not understand,
these devices are often disconnected.  For older versions of apcupsd,
it required restart for newly reattached device to be recreated in /dev.
Sometimes it hangs whole usb stack.

Newer apcupsd seems to open /dev/ugen only for the duration of the query,
which makes the erratic behaviour is much less likely, but could still cause
breakage when device disappear while apcupsd has it opened.

> 
> > 
> > I suspect that usb subsystem tried to destroy the device but some internal
> > refcounting prevents it.  Proper use of destroy_dev(_cb)(9) avoids
> > the issue.
> 
> --HPS