The reason for the random disconnects is apparently EMI related. Mar 1 07:09:09 localhost kernel: [265922.921985] hub 5-0:1.0: port 1 disabled by hub (EMI?), re-enabling... This is very much a possibility because the box is in a high current industrial control panel. That is not an issue because the device automatically reconnects. But after a few day's operation it stops reconnecting and i finally managed to capture the syslog. Mar 1 07:09:09 localhost kernel: [265922.934119] usb 5-1: USB disconnect, device number 83 Mar 1 07:09:10 localhost kernel: [265923.245580] usb 5-1: new full-speed USB device number 84 using sw-ohci Mar 1 07:09:10 localhost kernel: [265923.451746] pl2303 5-1:1.0: pl2303 converter detected Mar 1 07:09:10 localhost kernel: [265923.486633] pl2303 5-1:1.0: No more free serial devices Mar 1 07:09:10 localhost kernel: [265923.496483] pl2303: probe of 5-1:1.0 failed with error -5 Mar 1 07:09:10 localhost mtp-probe: checking bus 5, device 84: "/sys/devices/platform/sw-ohci.2/usb5/5-1" Mar 1 07:09:10 localhost mtp-probe: bus: 5, device: 84 was not an MTP device The driver issues "No more free serial devices". The two reasons i can see for this are either if the malloc fails (but there's no "out of memory" error) or if minor numbers have exceeded the limit. But the minor is only 84! Any pointers for a solution? Thanks, Malith On Wed, Jul 6, 2016 at 4:38 PM, Malith Yapa <malithyapa@xxxxxxxxx> wrote: > On Wed, Jul 6, 2016 at 3:42 PM, Johan Hovold <johan@xxxxxxxxxx> wrote: >> [ +CC: linux-usb, for real this time ;) ] >> >> On Wed, Jul 06, 2016 at 02:40:25PM +0530, Malith Yapa wrote: >>> On Wed, Jul 6, 2016 at 2:13 PM, Johan Hovold <johan@xxxxxxxxxx> wrote: >>> > [ Please avoid top-posing. ] >>> > >>> > On Wed, Jul 06, 2016 at 03:49:15AM +0000, Malith Yapa wrote: >>> >> I'm polling a couple of input bits as well as 16 bit memory registers from >>> >> a PLC (xinje) using libmodbus. >>> > >>> > Ah, so just normal tty use. >>> > >>> >> Feb 23 09:59:34 localhost kernel: [16960.073287] usb 5-1: USB disconnect, >>> >> device number 11 >>> >> Feb 23 09:59:34 localhost kernel: [16960.080069] usb 5-1: >>> >> pl2303_read_int_callback - usb_submit_urb failed with result -19 >>> > >>> > You're getting these -ENODEV (-19) error because the pl2303 device has >>> > already given up (crashed) and been disconnected. >>> > >>> >> Feb 23 09:59:35 localhost kernel: [16960.426637] usb 5-1: new full-speed >>> >> USB device number 12 using sw-ohci >>> >> Feb 23 09:59:35 localhost kernel: [16960.649900] usb 5-1: pl2303 converter >>> >> now attached to ttyUSB10 >>> > >>> >> Any pointers for a workaround at the driver level? I could see that ENODEV >>> >> results with the wrong device status. could that status be device 'busy'? >>> >> will it help if i reduce my polling rate? >>> > >>> > I don't think there's anything to be done at the driver level I'm >>> > afraid. If I understand you correctly, you're just using the normal tty >>> > interface (e.g. through libmodbus) to access some external entity (and >>> > its registers). >>> > >>> > Something is causing the pl2303 device to be reset. Perhaps an >>> > electrical issue. >>> > >>> >> On Tue, Jul 5, 2016 at 6:09 PM Johan Hovold <johan@xxxxxxxxxx> wrote: >>> >> >>> >> > On Mon, Jul 04, 2016 at 10:22:04PM +0530, Malith Yapa wrote: >>> >> > > Continuously polling registers with the PL2303 usb serial adapter >>> >> > > eventually results in usb_subimit_urb failed with result -19 (ENODEV) >>> >> > > but reconnects immediately. >>> >> > > occurrences are random. >>> >> > > tried with two different PL2303 devices with the same result. >>> >> > >>> >> > Sounds like a firmware issue, so not sure there's much we can do. >>> >> > >>> >> > Can you tell from the syslogs that the device is being disconnected and >>> >> > re-enumerated? What registers are you polling? >>> >>> Ok. Thats fine with me as long as it reconnects. However since the >>> device number keeps incrementing, I'm worried that it will fail >>> sometime in the future. It failed a couple of times before (I think >>> after reaching 255). I'm waiting for it to happen again to capture the >>> syslog. Is there anyway i can force it to reconnect with the same >>> id?(or come back to 0 after some time) what would be the maximum it >>> can go upto? >> >> That would be 512 these days. >> >> The minor numbers are not reused until your application (or libmodbus) >> releases them. The application should detect that the tty has been hung >> up and close the tty device. >> >> Another thing you can try (to avoid the disconnect) is to verify that >> you get the same behaviour using a different host controller (e.g. PC). >> Try without any intermediate external hubs too. >> >> Good luck, >> Johan > > Ok that makes sense. I think I've forgotten to close my modbus connection. > On the disconnect issue, i don't have any external hubs. I'll try a > different host, but if the minor numbers are reused my problem is > largely solved :) > > Thanks a lot! > Malith -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
