On Tue, 7 Feb 2017, John Skelton wrote: > > What happens after that? Does the cdc-acm driver refuse to bind? Any > > other types of error/warning messages? > > Along the lines of: > usb 2-1.2: >new low-speed USB device number 95 using ehci_hcd > usb 2-1.2: >device descriptor read/64, error -32 > usb 2-1.2: >config 1 interface 1 altsetting 0 endpoint 0x1 is Bulk; changing > to Interrupt > usb 2-1.2: >config 1 interface 1 altsetting 0 endpoint 0x81 is Bulk; changing > to Interrupt > usb 2-1.2: >New USB device found, idVendor=16d0, idProduct=087e > usb 2-1.2: >New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 2-1.2: >Product: Digispark Serial > usb 2-1.2: >Manufacturer: digistump.com > cdc_acm 2-1.2:1.0: >ttyACM0: USB ACM device > > But screen /dev/ttyACM0 (with or without a "baud" rate) just hangs.
Have you tried using minicom instead of screen? Do any other messages show up in the kernel log? What does /sys/kernel/debug/usb/devices say? Can you collect a usbmon trace? In theory, this should work. Especially since the port you're connecting to is hooked up to an EHCI controller and not an xHCI controller. > > Doing this type of thing really isn't a good idea for the obvious reason > > that hubs might just die a horrible death. Who knows what a USB 3 > > controller would do with a low speed device like this as well (hubs are > > crazy complex, and low speed makes them really sad.) > > Ah. Maybe it's my laptop's internal hub that hangs. Though the other USB > ports carry on working. That is unlikely. Treating a bulk interrupt as an interrupt endpoint makes very little difference (mostly it just affects the throughput, but a low-speed connection wouldn't be expected to have high throughput anyway). 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
