On Wed, 11 Feb 2015, Dave Mielke wrote: > [quoted lines by Alan Stern on 2015/02/11 at 11:13 -0500] > > >Hmmm. In addition to usbmon, you can try writing 1 to > >/sys/module/usbcore/parameters/usbfs_snoop and then seeing what shows > >up in the dmesg log. > > Looking at the snoop logs is hinting that I may need to add another piece to > this puzzle. It's showing that the urb doesn't complete until the device is > finally closed. This makes sense because, being turned off, the device isn't > responding to the probes. That's also what I used to see when using an actual > signal handler. > > What I didn't mention (because I didn't think it'd be significant) is that > I've > started seeing the current problem when I switched to using signalfd so that > a > signal handler wouldn't be necessary. What I see when using signalfd is that > the signal arrives (the signalfd file descriptor becomes readable) almost > immediately, i.e. as soon as the poll() is entered to wait for a response > from > the first probe. Reading the struct signalfd_siginfo from the signalfd file > descriptor does give the expected signal number. > > So now, perhaps the question is could it be that signalfd data is arriving > too > early? Could signalfd and signal handler behaviour really be different like > that?
That probably is the explanation. I don't know anything about signalfd; you should ask somebody who does. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
