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.
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....
Sebastian
--
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
