Bug 116011 - usb-serial stops functioning when traffic increases
usb-serial stops functioning when traffic increases
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Depends On:
  Show dependency treegraph
Reported: 2004-02-17 11:20 EST by Atul Chitnis
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-29 16:05:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test fix (all-inclusive) (11.01 KB, patch)
2004-03-23 14:32 EST, Pete Zaitcev
no flags Details | Diff
part of /var/log/messages showing oops (3.91 KB, text/plain)
2004-04-02 03:27 EST, Atul Chitnis
no flags Details

  None (edit)
Description Atul Chitnis 2004-02-17 11:20:51 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040210 Firefox/0.8

Description of problem:
I have no problem using usb-serial devices (such as my CDMA phone) up
to kernel 2.4.22-1.2135.nptl. Works wonderfully well.

But if I boot any kernel after 2.4.22-1.2135.nptl (2.4.22-1.2140.nptl,
2.4.22-1.2149.nptl or 2.4.22-1.2166.nptl), I can begin using the
usb-serial device, but as soon as even moderate amount of traffic
starts flowing over it (say a simple ssh session over ppp), the
session dies, and no data transfers.

Checking /var/log/messages, I find this:

Feb 16 21:12:59 wookie kernel: usbserial.c: too much data (220)
Feb 16 21:13:00 wookie kernel: usbserial.c: too much data (250)
Feb 16 21:13:00 wookie kernel: usbserial.c: too much data (128)
Feb 16 21:13:01 wookie kernel: usbserial.c: too much data (250)

This happens with all kernels after 2.4.22-1.2135.nptl, reproducable
at will. Every time, switching back to 2.4.22-1.2135.nptl solves the

Version-Release number of selected component (if applicable):
kernel-2.4.22-1.2140.nptl and later

How reproducible:

Steps to Reproduce:
1.Boot into any kerne after 2.4.22-1.2135.nptl.
2.Connect using pppd over any usb-serial modem

Actual Results:  Data-flow stops as soon as traffic increases even
slightly. /var/log/messages reports 

Feb 16 21:12:59 wookie kernel: usbserial.c: too much data (220)
Feb 16 21:13:00 wookie kernel: usbserial.c: too much data (250)
Feb 16 21:13:00 wookie kernel: usbserial.c: too much data (128)
Feb 16 21:13:01 wookie kernel: usbserial.c: too much data (250)

Expected Results:  Data flow should continue (and does in kernels
2.4.22-1.2135.nptl or earlier).

Additional info:

This is on a IBM Thinkpad T30 with USB 1.1 ports.
Comment 1 Pete Zaitcev 2004-02-18 14:58:50 EST
Aww crap, it's a regression in my change. Taking...
Comment 2 Atul Chitnis 2004-03-10 00:38:21 EST
Installed most recent kernel (linux-2.4.22-1.2174) - bug still exists.
Comment 3 Pete Zaitcev 2004-03-10 01:48:01 EST
Thanks. I'm pretty sure this should be fixed in PPP, Paulus
actually floated patches to do it. I just have to find them.

Comment 4 Pete Zaitcev 2004-03-12 23:49:49 EST
OK, probably not in PPP.

I can easily make the helper eat and queue arbitrary amounts of
data, but this is going to eat atomic memory very quickly.
Comment 5 Pete Zaitcev 2004-03-23 14:32:38 EST
Created attachment 98796 [details]
Test fix (all-inclusive)
Comment 6 Pete Zaitcev 2004-03-23 14:35:11 EST
On the third thought, it should be safe to let PPP to submit
whatever it wants, because it ought to be limited by TCP.
Flood pings are dangerous, but this is not limited to serial.

There were other bugs in this code, so I had to refine the whole
thing considerably. The patch is bigger than needed just for PPP.
Comment 7 Atul Chitnis 2004-04-02 03:27:26 EST
Created attachment 99066 [details]
part of /var/log/messages showing oops

Shows usb subsystem oopsing.
Comment 8 Atul Chitnis 2004-04-02 03:28:40 EST
I seem to be running into this problem with other apps using usbserial
as well. For example, my Palm Zire 71 syncing process (uses visor.o
which uses usbserial.o) quite often hangs cold

 9189 ?        D      0:00 jpilot-sync

As you can see from the D, nothing is going to kill that process. 

Sometimes, even trying to remove the visor.o module produces a hang if
it was syncing via USB - the module gets removed, but the removal
process hangs hard. An lsmod from another window shows

visor                      0   0  (deleted)
usbserial              22044   0  [visor]

lsmod shows the modules deleted but the rmmod that did it goes out to
lunch and doesn't come home.

I am not sure if the issue is related to usbserial, but usbserial is
the only module visor.o depends on. During the sync process, a pretty
heavy amount of data flows.

If this is the case (visor.o also dying based on USBserial), then it
isn't just pppd that has an issue here.

I also just noticed a major /var/log/messages entry for this - will
create an attachment to show it. Maybe it will help.
Comment 9 Pete Zaitcev 2004-04-06 01:48:23 EDT
Please test a kernel from this place:
It's RHEL kernel, but should work fine for FC1
Comment 10 Pete Zaitcev 2004-04-06 01:49:25 EDT
Sorry, I meant ftp://people.redhat.com/zaitcev/us3/
Comment 11 Leigh Purdie 2004-04-06 04:32:59 EDT
Looks promising.

Files over about 50 bytes, that refuse to transfer under
2.4.22-1.2174.nptl, work beautifully under the patched kernel.

Application: synce, which uses pppd over usbserial under the guidance
of modules/ipaq.

Critical sections of dmesg and /var/log/messages: grep -i usbserial
temp-dmesg .. nothing much interesting, but here it is:

Linux version 2.4.21-12.usbserial3.1.EL
(bhcompile@daffy.perf.redhat.com) (gcc version 3.2.3 20030502 (Red Hat
Linux 3.2.3-32)) #1 Tue Apr 6 00:40:29 EDT 2004
inserting floppy driver for 2.4.21-12.usbserial3.1.EL
usbserial.c: USB Serial support registered for Generic
usbserial.c: USB Serial Driver core v1.4
usbserial.c: USB Serial support registered for PocketPC PDA
usbserial.c: PocketPC PDA converter detected
usbserial.c: PocketPC PDA converter now attached to ttyUSB0 (or
usb/tts/0 for devfs)

Apr  6 18:25:23 inferno pppd[10389]: pppd 2.4.1 started by root, uid 0
Apr  6 18:25:25 inferno pppd[10389]: Serial connection established.
Apr  6 18:25:25 inferno pppd[10389]: Using interface ppp0
Apr  6 18:25:25 inferno pppd[10389]: Connect: ppp0 <--> /dev/ttyUSB0
Apr  6 18:25:25 inferno pppd[10389]: local  IP address
Apr  6 18:25:25 inferno pppd[10389]: remote IP address
Apr  6 18:25:26 inferno dccm[10371]: Connection from
Apr  6 18:25:26 inferno dccm[10371]: Talking to 'Pocket_PC', a
PocketPC device of type hp iPAQ h1930
Comment 12 Leigh Purdie 2004-04-06 04:39:27 EDT
Kernel oops as a result of turning off the handheld power whilst ppp
is connected has also dissapeared. Good stuff, Pete.
Comment 13 Atul Chitnis 2004-04-06 04:59:06 EDT
Online for the first time via a kernel other than 2.4.22-1.2135.nptl :)

Linux wookie.exocore.com 2.4.21-12.usbserial3.1.EL #1 Tue Apr 6
00:40:29 EDT 2004 i686 i686 i386 GNU/Linux

Both pppd and various palm apps work flawlessly over several hours of
use. Repeated syncs do not cause the "module out to lunch" problem. No
oops so far despite repeated yanking of the Palm or modem while in use.

This usbserial code seems to work perfectly. Can't wait for it to be
rolled into a FC1 production kernel! :)
Comment 14 Atul Chitnis 2004-04-06 05:05:03 EDT
Ah, forgot to mention that the previous comment was posted while
connected to the net via my USB-connected CDMA phone - the thing that
wouldnt work originally. pppd seems happy and is not reporting any
issues. No data-flow problems - currently downloading a file without

Comment 15 Pete Zaitcev 2004-04-06 13:05:27 EDT
I am sorry to report that DaveJ gave up on 2.4 right when I was
ready with the integration, so unless a security issue
pops up, there will be no new release of FC1 kernel.

I followed RHEL 3 branching procedure to build a test kernel.
Fortunately, it is binary compatible with FC1 (it includes NPTL).
Comment 16 Pete Zaitcev 2004-04-06 14:52:44 EDT
Woops, ignore that comment about the security errata, it's backwards.
Putting unrelated stuff into security errata is actually harmful.
So anyway, enojy the RHEL branch, and I'll figure a way to deliver
FC1 update meanwhile.
Comment 17 Atul Chitnis 2004-04-07 00:03:09 EDT
Many thanks, Pete!

Could you put up the kernel-source rpm for this branch as well? Can't
compile other stuff (like my wifi drivers) otherwise for this kernel.
Comment 18 Pete Zaitcev 2004-04-07 11:23:00 EDT
Getting that many kernel-source packages pushes me over the quota
limit at the FTP server people.redhat.com. I started with them
in place at first. What is the required architecture, precisely?
I can upload one or two.
Comment 19 Atul Chitnis 2004-04-07 11:35:10 EDT
No problem - I realised that the SRPM was up anyway, so sucked that
down and just rebuilt all the required packages (I needed the
kernel-source-*.i386.rpm). Thanks for the offer though.

One thing I notice (and which keeps my fingers crossed firmly for the
FC1 kernel update) is that the RHEL kernel doesnt give as rapid a
desktop response as teh FC1 kernels do - xmms is positively unhappy. ;)

If it isn't too much of trouble (and against the rules?), any hope of
possibly issuing a patch (even unofficially) that will build against
the last FC1 kernel so that I can just apply that to a FC1 kernel here
and use it?

I havent dug in that deeply yet, but are your changes only in
drivers/usb or elsewhere as well?

Comment 20 Pete Zaitcev 2004-04-07 12:10:18 EDT
The patch for FC1 is attached to this very bug report, completely
officially and everything. The Fedora is an open development,
no hidden patches (except embargoed security).

It was submitted to DaveJ long ago, but he asked me to hold
until April 14.
Comment 21 Atul Chitnis 2004-04-18 01:18:17 EDT
Just downloaded and installed kernel-2.4.22-1.2179 that appeared on
Fedora updates - looks like this usbserial patch didn't make it into
this kernel, since all the USB-related problems seem to be back in
this (2.4.22-1.2179) kernel.

Apr 17 15:16:57 wookie kernel: Linux version 2.4.22-1.2179.nptl
(bhcompile@porky .devel.redhat.com) (gcc version 3.2.3 20030422 (Red
Hat Linux 3.2.3-6)) #1 Tue Apr 13 09:59:19 EDT 2004


Apr 17 15:18:57 wookie pppd[5445]: Serial connection established.
Apr 17 15:18:57 wookie pppd[5445]: Using interface ppp0
Apr 17 15:18:57 wookie pppd[5445]: Connect: ppp0 <--> /dev/rmodem
Apr 17 15:19:03 wookie pppd[5445]: PAP authentication succeeded
Apr 17 15:19:03 wookie kernel: PPP Deflate Compression module registered
Apr 17 15:19:03 wookie pppd[5445]: local  IP address
Apr 17 15:19:03 wookie pppd[5445]: remote IP address
Apr 17 15:19:03 wookie pppd[5445]: primary   DNS address
Apr 17 15:19:03 wookie pppd[5445]: secondary DNS address
Apr 17 15:19:13 wookie kernel: usbserial.c: too much data (220)
Apr 17 15:19:13 wookie kernel: usbserial.c: too much data (250)
Apr 17 15:19:13 wookie kernel: usbserial.c: too much data (128)
Apr 17 15:19:16 wookie kernel: usbserial.c: too much data (250)

However my kernel-2.4.22-1.2174 patched with the usbserial patch works
Comment 22 Leigh Purdie 2004-04-29 02:04:12 EDT
Is this now fixed in 2.4.22-1.2188?

From the release notes, it doesn't look promising..
Comment 23 Pete Zaitcev 2004-04-29 02:13:33 EDT
Nope, 2.4.22-1.2188 is a security update.
Bugs go into MODIFIED state when patches get committed.
Comment 24 Pete Zaitcev 2004-08-10 15:33:04 EDT
Modified 2.4.21-1.2199
Comment 25 David Lawrence 2004-09-29 16:05:50 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.