Hi all, Thank you for your helpful answers! I have investigated it further, stopping potential culprits in userspace and I have found the issue: it is modemmanager that seems to keep the devices open somewhere and thus causes the ttyUSB numbers to go up. So now I will redirect the issue to their developers :-) I do not care about the device node name per se, I use symlinks anyway to have consistent naming, but since there is a limit of max. 512 ttyUSB devices and each modem consists of 3 of those, the system hits the limit rather quickly. Thanks a lot! Erwin On Wed, Oct 21, 2015 at 4:37 PM, Greg K-H <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Oct 21, 2015 at 11:39:04AM +0200, Erwin Van de Velde wrote: >> Hi all, >> >> As advised, I retried with a more recent kernel (4.2.0), but I get a >> similar result: >> >> I tested via 'echo 1 > /sys/bus/pci/ehci-pci/0000\:00\:1a.0/remove' >> and 'echo 1 > /sys/bus/pci/rescan'. > > Why did you remove the PCI device? Do you have a PCI hotplug system > that recan will work for? > > You are removing the whole USB host controller here, not just the USB > device itself, it's a "fake" hotplug, which is odd, and your PCI device > might not work correctly when you add it back... > >> There are two possible results: no >> errors when removing the device and then the devices are reinserted >> with the same ttyUSB number or, with an error: >> 'usb_wwan_indat_callback: resubmit read urb failed. (-19)' (as shown >> in the dmesg copied below) and then the numbers increase, even though >> the ttyUSB devices with the previously used numbers have been removed >> from /dev. On following attempts the numbers only remain the same or >> increase, never reusing the freed ttyUSB numbers. Can someone please >> tell me how I can prevent the error or circumvent the issue otherwise? >> Sometimes the devices get stuck and resetting them via removal seems >> to be the only option. >> >> Thanks in advance! >> Erwin >> >> [ 623.366025] ehci-pci 0000:00:1a.0: remove, state 1 >> [ 623.366042] usb usb1: USB disconnect, device number 1 >> [ 623.366047] usb 1-1: USB disconnect, device number 2 >> [ 623.366051] usb 1-1.1: USB disconnect, device number 4 >> [ 623.366270] option1 ttyUSB6: GSM modem (1-port) converter now >> disconnected from ttyUSB6 >> [ 623.366294] option 1-1.1:1.0: device disconnected >> [ 623.368715] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read >> urb failed. (-19) >> [ 623.369327] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read >> urb failed. (-19) >> [ 623.369863] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read >> urb failed. (-19) >> [ 623.370398] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read >> urb failed. (-19) > > Those are normal, the device is being removed. > >> [ 623.371083] option1 ttyUSB9: GSM modem (1-port) converter now >> disconnected from ttyUSB9 >> [ 623.371097] option 1-1.1:1.2: device disconnected >> [ 623.371315] option1 ttyUSB14: GSM modem (1-port) converter now >> disconnected from ttyUSB14 > > > Have you also shut down the userspace program that had these device > nodes open? That's the issue here, what program has the device nodes > open, if they don't close them, no matter what you do, the device nodes > will not be recycled within the kernel. This isn't a kernel issue, it's > a userspace issue to properly shut them down in order for the numbers to > be reused. > > But even if they aren't reused, it's not a big deal, userspace should > not care about the device node names at all, this isn't a problem, they > will be recycled once userspace closes the device node, eventually. > > So focus on your userspace programs if you are really worried about the > device numbers here. > > hope this helps, > > greg k-h -- 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
