On Thu, Aug 06, 2009 at 08:54:50AM -0400, MikeHudy wrote: > I'm trying to understand an issue I'm having with the ftdi_sio driver. > Basically, I have a device which contains an FT2232D chip that I'm > trying to communicate with from an embedded controller. When I open a > tty port on the device (using "screen /dev/ttyUSB1 115200") I'm able > to send characters to the device but I cannot read anything from it. > When I turn on debug logging in the ftdi driver I get the following: > > [ 44.630000] drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 1 > [ 44.630000] drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 1 > [ 44.630000] drivers/usb/serial/ftdi_sio.c: Status only: 361o 140o > [ 44.650000] drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 1 > [ 44.650000] drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 1 > [ 44.650000] drivers/usb/serial/ftdi_sio.c: Status only: 361o 140o > [ 44.670000] drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 1 > [ 44.670000] drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 1 > [ 44.670000] drivers/usb/serial/ftdi_sio.c: Status only: 361o 140o > [ 44.690000] drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 1 > [ 44.690000] drivers/usb/serial/ftdi_sio.c: (this is ok on close) > nonzero read bulk status received: -75 > [ 45.250000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x5401 > [ 45.250000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not > supported - it was 0x5401 - check /usr/include/asm/ioctls.h > [ 45.270000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x5401 > [ 45.270000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not > supported - it was 0x5401 - check /usr/include/asm/ioctls.h > [ 45.290000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x5402 > [ 45.290000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not > supported - it was 0x5402 - check /usr/include/asm/ioctls.h > [ 45.310000] drivers/usb/serial/ftdi_sio.c: ftdi_set_termios > [ 45.310000] drivers/usb/serial/ftdi_sio.c: Setting CS8 > [ 45.320000] drivers/usb/serial/ftdi_sio.c: get_ftdi_divisor - > tty_get_baud_rate reports speed 115200 > [ 45.330000] drivers/usb/serial/ftdi_sio.c: get_ftdi_divisor - Baud > rate set to 115200 (divisor 0x1A) on chip FT2232C > [ 45.340000] drivers/usb/serial/ftdi_sio.c: ftdi_set_termios Turning > off hardware flow control > [ 45.350000] drivers/usb/serial/ftdi_sio.c: ftdi_tiocmset TIOCMSET > [ 45.360000] drivers/usb/serial/ftdi_sio.c: update_mctrl - DTR HIGH, RTS HIGH > [ 45.370000] drivers/usb/serial/ftdi_sio.c: ftdi_write port 1, 2 bytes > [ 45.380000] drivers/usb/serial/ftdi_sio.c: data_offset set to 0 > [ 45.390000] ftdi_sio ttyUSB1: ftdi_write - length = 2, data = 0d 0a > [ 45.400000] drivers/usb/serial/ftdi_sio.c: ftdi_write write returning: 2 > [ 45.400000] drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 1 > [ 45.520000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl cmd 0x541b > [ 45.520000] drivers/usb/serial/ftdi_sio.c: ftdi_ioctl arg not > supported - it was 0x541b - check /usr/include/asm/ioctls.h > [ 45.540000] drivers/usb/serial/ftdi_sio.c: ftdi_write port 1, 5 bytes > [ 45.540000] drivers/usb/serial/ftdi_sio.c: data_offset set to 0 > [ 45.550000] ftdi_sio ttyUSB1: ftdi_write - length = 5, data = 6e 70 73 0d 0a > [ 45.560000] drivers/usb/serial/ftdi_sio.c: ftdi_write write returning: 5 > [ 45.560000] drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 1 > [ 45.580000] drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 1 > [ 45.580000] drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 1 > [ 45.590000] drivers/usb/serial/ftdi_sio.c: ftdi_chars_in_buffer - port 1 > [ 45.600000] drivers/usb/serial/ftdi_sio.c: ftdi_write_room - port 1 > > When the driver starts there is an endless stream of read requests > until the URB failure at 44.690000 at which point all reading stops. > Looking at the ftdi code in ftdi_read_bulk_callback, it appears that > read requests are endlessly chained together until/unless a non-zero > URB status is received at which point the read chain comes to a > screeching halt. I believe my fundamental problem is the HCD that > generates the -75 (overflow) error (which is probably related to > development of the HCD driver for the OXU210 on our controller), but > my question is this... > > It seems that reading will always come to a halt if an URB error > occurs. While this is probably a rare event, is this a good idea? > Why not restart the read URB chain after discarding the errant URB? That would be a good idea, except that the error that was received -EOVERFLOW, indicates a hardware error happened with the device, so restarting it might not be the best thing to do. But, if you think it would be best to resubmit on that error, please send a patch to do this. Or better yet, fix your host controller driver :) thanks, greg k-h -- 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
