Red Hat Bugzilla – Bug 90442
Using a USB FTDI device hangs system
Last modified: 2007-04-18 12:53:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
I have a Falcom Twist USB modem (vid=0x0f94, pid=0x0001) which uses the FTDI
chip. Its id is not in the ftdi_sio.o module, so I copied ftdi_sio.c to
ftdi_twist.c and patched it a little (patch attached). After I install the
module, I plug the device and try to open /dev/ttyUSB0 with minicom. The sytem
hangs (trace attached).
I found that the ftdi_sio driver calls tty_flip_buffer_push() in the function
ftdi_read_bulk_callback(). ftdi_read_bulk_callback() is called in an interrupt
(testing in_interrupt() returns 1). The FTDI SIO driver sets low latency, so
tty_flip_buffer_push() calls flush_to_ldisc() immediately. I think that this
should not be called in an interrupt.
I modified the driver a bit further with a second patch (patch2 attached) to
remove its low latency and now the modem seems to work.
Note: To compile, I use:
cc -c -D__KERNEL__ -DMODULE -I/lib/modules/2.4.20-9/build/drivers/usb/serial -I
/lib/modules/2.4.20-9/build/include -Wall -O2 ftdi_twist.c -o ftdi_twist.o
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Put ftdi_twist.o into /lib/modules/2.4.20-9/kernel/drivers/misc/
2. Run depmod -a
3. Plug in Falcom Twist USB device
4. Run minicom on /dev/ttyUSB0
Created attachment 91557 [details]
Patch to make Falcom Twist USB work with ftdi_sio driver
Created attachment 91558 [details]
Trace shown on console when the kernel panics
Created attachment 91559 [details]
Patch which removes low latency
This is interesting, grabbing and leaving Arjan on cc:.
Why do you not think it is ok to call flush_to_ldisc() from interrupt context?
It looks legal to me, and is required for usb-serial devices to handle high data
rates (the visor driver will drop bytes unless it is used.)
I am not that familiar with flush_to_ldisc() and other such functions. I only
made that comment because if I remove low latency from the driver the kernel
does not crash. It can be that there is a bug somewhere else which is trigerred
by some legal behaviour here.
Is 2.4.20-18 any better? Please try it. It may even have your IDs,
and another user reports that it works for him now.
I have a FTDI usb to serial cable, not a USB modem. I haven't even used it
much, just tried to get it to work with my palm sync cradle.
Neither 2.4.20-13.9 nor 2.4.20-18.9 solve the problem.
As a note, on another PC I do not see this problem. But on this PC, it still
I am attaching new patches and trace for new kernel (2.4.20-18.9).
Created attachment 92154 [details]
Make Falcom Twist USB work with ftdi_sio driver (2.4.20-18.9)
Created attachment 92155 [details]
Trace shown on console when the kernel panics (2.4.20-18.9)
Created attachment 92156 [details]
Remove low latency (2.4.20-18.9)
Trevor, does that last patch work? I think the usbserial.c
sets the tty->low_latency upon open no matter what.
Anyway, I think this needs a major surgery in usbserial.c
and possibly all subcomponent drivers.
*** Bug 91272 has been marked as a duplicate of this bug. ***
Yes, the last patch works for me for this device.
In usbserial.c, low latency is set in generic_open(). In ftdi_sio.c (or
ftdi_twist.c in my case), ftdi_open() and set_serial_info() both contain the line:
port->tty->low_latency = (priv->flags & ASYNC_LOW_LATENCY) ? 1 : 0;
So I guess it resets the low latency flag.
Date: Fri, 06 Jun 2003 10:03:44 -0500
From: Gregory Gulik <firstname.lastname@example.org>
Just to let you know but I rebooted into the 2.4.20-18.9.athlon kernel
and it's working just fine.
dmesg output attached. You'll see that the usbserial code for the
attached Palm device is configured but I unload it in my rc.local
because all my syncing is done in a Windows/VMware session.
Created attachment 96004 [details]
Something to think about - helper process (us1)
*** Bug 101905 has been marked as a duplicate of this bug. ***
I sent a reference to a test RPM to everyone involved,
got only one reply from Colin.
OK, people, here's the deal. I don't have the hardware, so
I cannot test. If you don't test, I'm not commiting anything
anywhere, and don't forget - Greg is not taking anything for 2.4.
I'll let this pile to fester for a week, and if no interest
Greg is taking 2.4 patches, just not sending them off during the -rc
series. When 2.4.23 comes back, I'll send more patches off that fix
bugs, and backport 2.6 changes.
I tried the test rpm and it seems to solve the problem for me. The
steps that crash the other kernels do not crash the test kernel.
Seems to work ok for me. Thanks!
Halleluya, modified in 2.4.22-1.2136.
Just use Fedora kernels for now, they should be compatible with RHL 9.
DaveJ included the fix in 2.4.22-1.2138, posted 2004/01/05.
Self-closing (too many requestors - nobody is closing).