On Fri, Jan 07, 2011 at 11:27:18AM +0000, Russell King - ARM Linux wrote: > 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'd suggest disabling the KERN_NOTICE message in question first. If that alone does not help, try enabling debugging in both usb-serial and ftdi_sio. > 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. Not sure which kernel Fedora uses but ftdi_sio was re-implemented in 2.6.35. Thanks, Johan -- 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
