On Thu, Jan 06, 2011 at 10:29:05PM +0000, Russell King - ARM Linux wrote: > Hi, > > I've just tried a FTDI SIO USB serial device connected to the ISP1761 on > Versatile Express (an ARM Cortex A9 SMP development platform) running 2.6.37. > It appears to be detected correctly: > > usb 1-1: new high speed USB device using isp1760 and address 2 > port 1 high speed > usb 1-1: New USB device found, idVendor=0471, idProduct=3526 > usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 1-1: Product: ISP1520 > usb 1-1: Manufacturer: Philips Semiconductors > hub 1-1:1.0: USB hub found > hub 1-1:1.0: 3 ports detected > usb 1-1.3: new high speed USB device using isp1760 and address 3 > usb 1-1.3: New USB device found, idVendor=0403, idProduct=6011 > usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 1-1.3: Product: Quad RS232-HS > usb 1-1.3: Manufacturer: FTDI > ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected > usb 1-1.3: Detected FT4232H > usb 1-1.3: Number of endpoints 2 > usb 1-1.3: Endpoint 1 MaxPacketSize 512 > usb 1-1.3: Endpoint 2 MaxPacketSize 512 > usb 1-1.3: Setting MaxPacketSize 512 > usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0 > ... > > but after minicom attaches to one of the four USB serial ports, the > console is spammed with: > > Reloading ptd e74070a0/e71e9680... qh e74070c0 read: 0 of 512 done: 00000002 cur: 00000001 > Reloading ptd e74070a0/e71e9680... qh e74070c0 read: 0 of 512 done: 00000002 cur: 00000001 > Reloading ptd e74070a0/e71e9680... qh e74070c0 read: 0 of 512 done: 00000002 cur: 00000001 > Reloading ptd e74070a0/e71e9680... qh e74070c0 read: 0 of 512 done: 00000002 cur: 00000001 > > The comment associated with the printk seems to suggest that it's caused > by the device not responding quickly enough - if it's a serial device > being polled for received data, I guess it won't respond... that's just > a guess though. > > However, it appears to receive and transmit fine, until I paste a >80 > line into minicom: > > Hit any key to stop autoboot: 0 > OMAP44XX SDP # setenv bootargs 'root=/dev/mmcb > > and there USB activity wedges after 31 characters - the interrupt count > against the host controller remains static no matter what I do. The > machine is otherwise alive. It seems that USB has completely fallen > over. > > Any ideas/patches to try? Incidentally, minicom is in D wait state, /proc/XXX/wchan for it says "usb_start_wait_urb". -- 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
