[Ftdi-usb-sio-devel] 15 Byte Write Limit

[Richard C. <sp...@ec...>]

I've found that when I write to the device file, if I use writes which are greater than 15 bytes in length, all hell eventually breaks loose.

I'm not sure what the sequence of events are that trigger hell, but it really seems as if if I limit the writes I make to 15 bytes (using direct system calls to write() rather than any language-dependant write) then everything works like it is supposed to.  I can send the same amount of data as before, I just have to break it up into 15 byte chunks.  ...and 16 bytes isn't small enough, it has to be 15 bytes.

If I don't, then after some time (it kind of seems like I have to do a large read later) the driver will lock up.  Sometimes the read() and write() system calls lock up.  Sometimes using the stty command on the device file will lock up stty within a system call.  Sometimes commands like 'lsusb -v' will also lock up in a system call.  ...or maybe I shouldn't say 'sometimes' since usually they all happen, it's just that nothing is guaranteed.  Sometimes disconnecting the device can return things to normal, though it might take a few attempts and some waiting, but since I upgraded to kernel 2.6.29-gentoo-r5, disconnecting the device when it is in this state causes an oops:

Jul 22 13:59:46 isuck kernel: usb 1-2.2: clear tt 1 (90b1) error -71
Jul 22 13:59:46 isuck kernel: usb 1-2.2: clear tt 1 (10b2) error -71
Jul 22 13:59:46 isuck kernel: usb 1-2.2: clear tt 1 (10b2) error -71
Jul 22 13:59:46 isuck kernel: usb 1-2.2.4: clear tt 1 (90a1) error -71
Jul 22 13:59:46 isuck kernel: usb 1-2.2: USB disconnect, address 8
Jul 22 13:59:46 isuck kernel: usb 1-2.2.3: USB disconnect, address 11
Jul 22 13:59:46 isuck kernel: ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
Jul 22 13:59:46 isuck kernel: ftdi_sio 1-2.2.3:1.0: device disconnected
Jul 22 13:59:46 isuck kernel: usb 1-2.2.4: USB disconnect, address 9
Jul 22 13:59:46 isuck kernel: usb 1-2.2.4.3: USB disconnect, address 10
Jul 22 13:59:46 isuck kernel: ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Jul 22 13:59:46 isuck kernel: ftdi_sio 1-2.2.4.3:1.0: device disconnected
Jul 22 13:59:46 isuck kernel: BUG: unable to handle kernel NULL pointer dereference at 0000006c
Jul 22 13:59:46 isuck kernel: IP: [<c03a333c>] ftdi_set_termios+0x3c/0x670
Jul 22 13:59:46 isuck kernel: *pde = 00000000 
Jul 22 13:59:46 isuck kernel: Oops: 0000 [#1] PREEMPT SMP 
Jul 22 13:59:46 isuck kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:04:03.0/class
Jul 22 13:59:46 isuck kernel: Modules linked in: cryptoloop loop
Jul 22 13:59:46 isuck kernel: 
Jul 22 13:59:46 isuck kernel: Pid: 20031, comm: stty Not tainted (2.6.29-gentoo-r5.isuck #10) MacBook3,1
Jul 22 13:59:46 isuck kernel: EIP: 0060:[<c03a333c>] EFLAGS: 00210246 CPU: 1
Jul 22 13:59:46 isuck kernel: EIP is at ftdi_set_termios+0x3c/0x670
Jul 22 13:59:46 isuck kernel: EAX: eb67a800 EBX: 00000000 ECX: eb7e3e38 EDX: 00000005
Jul 22 13:59:46 isuck kernel: ESI: eb769000 EDI: eb55db40 EBP: 00000000 ESP: eb7e3dc0
Jul 22 13:59:46 isuck kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Jul 22 13:59:46 isuck kernel: Process stty (pid: 20031, ti=eb7e2000 task=eb748d00 task.ti=eb7e2000)
Jul 22 13:59:46 isuck kernel: Stack:
Jul 22 13:59:46 isuck kernel:  7fffffff eb67a800 7fffffff eb67a8e4 c04c89a5 eb67a800 eb7e3e38 eb769000
Jul 22 13:59:46 isuck kernel:  eb67a800 eb6e7400 00000005 c013deed c03a3300 eb769000 eb67a800 eb7e3e38
Jul 22 13:59:46 isuck kernel:  c039e8c4 eb748d00 c013dd60 eb7e3e0c eb7e3e0c eb7e3e38 eb67a814 eb55db6c
Jul 22 13:59:46 isuck kernel: Call Trace:
Jul 22 13:59:46 isuck kernel:  [<c04c89a5>] schedule_timeout+0x85/0xc0
Jul 22 13:59:46 isuck kernel:  [<c013deed>] finish_wait+0x2d/0x70
Jul 22 13:59:46 isuck kernel:  [<c03a3300>] ftdi_set_termios+0x0/0x670
Jul 22 13:59:46 isuck kernel: BUG: unable to handle kernel NULL pointer dereference at 00000044
Jul 22 13:59:46 isuck kernel: IP: [<c0133a2f>] del_timer+0xf/0x60
Jul 22 13:59:46 isuck kernel: *pde = 00000000 
Jul 22 13:59:46 isuck kernel:  [<c039e8c4>] serial_set_termios+0x44/0xd0
Jul 22 13:59:46 isuck kernel:  [<c013dd60>] autoremove_wake_function+0x0/0x50
Jul 22 13:59:46 isuck kernel:  [<c02a9cfb>] set_termios+0x25b/0x420
Jul 22 13:59:46 isuck kernel:  [<c02a7480>] n_tty_ioctl+0x0/0xe0
Jul 22 13:59:46 isuck kernel:  [<c02aa260>] tty_mode_ioctl+0x2c0/0x530
Jul 22 13:59:46 isuck kernel:  [<c02aa745>] tty_ldisc_try+0x35/0x50
Jul 22 13:59:46 isuck kernel:  [<c02aaa8c>] tty_ldisc_ref_wait+0xc/0xa0
Jul 22 13:59:46 isuck kernel:  [<c039e652>] serial_ioctl+0x52/0xb0
Jul 22 13:59:46 isuck kernel:  [<c02a7480>] n_tty_ioctl+0x0/0xe0
Jul 22 13:59:46 isuck kernel:  [<c02a5256>] tty_ioctl+0x116/0x820
Jul 22 13:59:46 isuck kernel:  [<c028c511>] rb_insert_color+0xc1/0xf0
Jul 22 13:59:46 isuck kernel:  [<c02a5140>] tty_ioctl+0x0/0x820
Jul 22 13:59:46 isuck kernel:  [<c018e2db>] vfs_ioctl+0x2b/0x90
Jul 22 13:59:46 isuck kernel:  [<c0170575>] __vma_link+0x45/0x80
Jul 22 13:59:46 isuck kernel:  [<c018e4eb>] do_vfs_ioctl+0x7b/0x5c0
Jul 22 13:59:46 isuck kernel:  [<c0171840>] do_brk+0x300/0x340
Jul 22 13:59:46 isuck kernel:  [<c018ea6d>] sys_ioctl+0x3d/0x70
Jul 22 13:59:46 isuck kernel:  [<c01033f1>] sysenter_do_call+0x12/0x25
Jul 22 13:59:46 isuck kernel: Code: 24 18 8b 1d e8 c1 6a c0 8b 02 85 db 8b 00 89 44 24 24 8b 44 24 20 8b aa 6c 01 00 00 8b 78 30 8b 17 89 54 24 28 0f 85 49 05 00 00 <8b> 55 6c 85 d2 74 22 f7 47 08 0f 10 00 00 74 19 8b 0d e8 c1 6a 
Jul 22 13:59:46 isuck kernel: EIP: [<c03a333c>] ftdi_set_termios+0x3c/0x670 SS:ESP 0068:eb7e3dc0
Jul 22 13:59:46 isuck kernel: ---[ end trace 9c54124943e0dab1 ]---

On the bright side, those device files are stuck, and so I get new device files when I reattach the devices, and so I can use them again immediately.  (Before I'd just get the same device files again, which often inheireted their broken state from their last use.)  On the dark side, any processes that had those devices open are stuck as well, and sometimes the oops message is followed by a message that I need to reboot.  ...which remindes me, I need to reboot.

Anyway, I wonder, why does this driver implement TTY devices?  Maybe it's different from the other supported chips, but the UM245R I'm using has nothing at all in common with a serial port, let alone a TTY, other than the fact that they're all character devices.  It'd be a lot more convienent if the driver created simple character devices, like "/dev/FTDI/whatever" where 'whatever' is the serial number of the device.  Then I wouldn't have to parse through 'dmesg' and 'lsusb -v' to track down which device file refers to which physical device, nor would I have to use the 'stty' command to disable all of the nonsense in the TTY layer.  Then I could just "hexdump -C < /dev/FTDI/TS154323" and not have to worry that it's been unplugged recently and so I need to run "stty raw -echo < /dev/ttyUSB0" again, or that it might now refer to some completely different device which can happen since I often plug in two at at time.