On Fri, Jan 07, 2011 at 11:46:15AM +0100, Sebastian Andrzej Siewior wrote: > Russell King - ARM Linux wrote: >> On Thu, Jan 06, 2011 at 10:29:05PM +0000, Russell King - ARM Linux wrote: >>> Hi, > Hi, > >>> 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. > > Yes that is correct. This was moved from KERN_ERR to KERN_NOTICE because > it is not an error and may occur on slower devices. If it is too spammy it > could be put silent. Is this actually an error? Surely for serial devices, this is normal behaviour. At the moment, it makes the console on the machine unusable all the time that the USB device is in use. Obviously, a serial device won't may not have data available for long periods of time to satisfy a pending read. Note that the console is serial, so printk() will have a higher latency than printk() to VGA. I do see quite a bit of interactive latency on the link, so I think something isn't right - I thought USB was supposed to be faster than a 75 baud serial connection? (That's what it feels like, except it's chunk-based rather than character based hesitations.) I've not been able to characterize whether it's the TX or RX at fault, and until I have the OMAP4 device to which the ftdi_sio driver up and running, that's impossible for me to do. >>> 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". > > My best guess would be that the driver received an URB and thinks that > more of it is coming but this is not case and it waits.... Having seen previous revisions of the ftdi_sio driver, nothing would surprise me. However, with a slightly fixed version of the ftdi_sio driver on a 2.6.30 Fedora 11 kernel, comms wise it worked fine (apart from the oops when I forget to kill minicom before unplugging.) People also tell me that Fedora 12 works fine out of the box with ftdi_sio. Unfortunately, I have very few USB devices - especially of the serial type, so I can't check with anything similar. -- 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
