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 problem. Version-Release number of selected component (if applicable): kernel-2.4.22-1.2140.nptl and later How reproducible: Always 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.
Aww crap, it's a regression in my change. Taking...
Installed most recent kernel (linux-2.4.22-1.2174) - bug still exists.
Thanks. I'm pretty sure this should be fixed in PPP, Paulus actually floated patches to do it. I just have to find them.
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.
Created attachment 98796 [details] Test fix (all-inclusive)
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.
Created attachment 99066 [details] part of /var/log/messages showing oops Shows usb subsystem oopsing.
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.
Please test a kernel from this place: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116011 It's RHEL kernel, but should work fine for FC1
Sorry, I meant ftp://people.redhat.com/zaitcev/us3/
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.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 192.168.131.102 Apr 6 18:25:25 inferno pppd[10389]: remote IP address 192.168.131.201 Apr 6 18:25:26 inferno dccm[10371]: Connection from 192.168.131.201 accepted Apr 6 18:25:26 inferno dccm[10371]: Talking to 'Pocket_PC', a PocketPC device of type hp iPAQ h1930
Kernel oops as a result of turning off the handheld power whilst ppp is connected has also dissapeared. Good stuff, Pete.
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! :)
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 problems.
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).
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.
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.
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.
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? TIA!
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.
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 [snip] 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 220.226.15.25 Apr 17 15:19:03 wookie pppd[5445]: remote IP address 97.237.2.3 Apr 17 15:19:03 wookie pppd[5445]: primary DNS address 202.138.103.100 Apr 17 15:19:03 wookie pppd[5445]: secondary DNS address 202.138.96.2 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 flawlessly.
Is this now fixed in 2.4.22-1.2188? From the release notes, it doesn't look promising..
Nope, 2.4.22-1.2188 is a security update. Bugs go into MODIFIED state when patches get committed.
Modified 2.4.21-1.2199
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 persists. 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/