> From: "Alan Stern" <stern@xxxxxxxxxxxxxxxxxxx> > 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? Also just sits there. But I'm going to try usbmon... > Do any other messages show up in the kernel log? No. > What does /sys/kernel/debug/usb/devices say? I think the relevant part is: T: Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 5 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=16d0 ProdID=087e Rev= 1.00 S: Manufacturer=digistump.com S: Product=Digispark Serial C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=255ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm E: Ad=01(O) Atr=03(Int.) MxPS= 8 Ivl=1ms E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=1ms It's a Digispark (cpu is ATtiny85 at 16.5MHz to get the USB speed nearly right) via Arduino 1.6.6 with support for the Digispark, flashed with DigisparkCDC sample (it tries to echo each byte received). > Can you collect a usbmon trace? Thanks!! I did not know it existed so will use it. (The short answer is yes.) > 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. It looks to work on a quick try. > > > 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). Indeed it appears fine. John -- 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
