On Sun, Jan 09, 2011 at 01:35:45PM +0100, Sebastian Andrzej Siewior wrote: > * Russell King - ARM Linux | 2011-01-07 20:45:36 [+0000]: > > >On Fri, Jan 07, 2011 at 11:27:18AM +0000, Russell King - ARM Linux wrote: > >> 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. > > > >It appears to be the RX side which is getting wedged. Now that my OMAP4 > >platform boots to a prompt, I've been able to test various things. > > > >If I type 'dmesg' then I see it sometimes stop at a random point in the > >output. > > > >If I then exit minicom, I get: > > > >ftdi_sio ttyUSB2: ftdi_set_termios FAILED to set databits/stopbits/parity > >ftdi_sio ttyUSB2: ftdi_set_termios urb failed to set baudrate > >ftdi_sio ttyUSB2: urb failed to clear flow control > >ftdi_sio ttyUSB2: error from flowcontrol urb > > > >before minicom finally exits and I get a prompt back. If I then restart > >minicom: > > > >qh is 0 > > This is strange. The queue head (endpoint) was closed but there is still > a package descriptor active. This shouldn't happen. > > >ftdi_sio ttyUSB2: ftdi_set_termios FAILED to set databits/stopbits/parity > > > >but it appears to be working again. > > > >Next time around, I enabled debugging in ftdi_sio. This is everything > >that remains in the kernel message buffer: > > > > > >=== this is where stuff goes awol === > > > >drivers/usb/serial/ftdi_sio.c: ftdi_tiocmget TIOCMGET > >drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x5402 > >drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not supported - it was 0x5402 - check /usr/include/asm/ioctls.h > >drivers/usb/serial/ftdi_sio.c: ftdi_set_termios > >drivers/usb/serial/ftdi_sio.c: Setting CS8 > >ftdi_sio ttyUSB2: ftdi_set_termios FAILED to set databits/stopbits/parity > This fails while sending an URB. If we run here into the timeout > (instead of sending it to an dead end point) then this could be fixed :) > The erratum says that is has been observed with usb-to-serial and > usb-to-network adapter that the ATL interrupt stop appearing if clear > the done map while another interrupt is generated. The suggested > workaround is to listen on SOF interrupts instead of ATL and poll the > done bits. If you have a patch, I'll test it - it's very easy to reproduce here. Last night, it was at the point of having to restart minicom almost every time I rebooted the OMAP4 board because at some point during the uboot blurb the USB serial port went awol. -- 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
