Bug 39238 - Data being lost via USB
Data being lost via USB
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-05 20:21 EDT by Daniel Morris
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-08 13:01:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Vojtech's gigantic buffer (4.00 KB, patch)
2001-06-15 03:31 EDT, Pete Zaitcev
no flags Details | Diff

  None (edit)
Description Daniel Morris 2001-05-05 20:21:49 EDT
Description of Problem:
External USB modem (3Com ISDN Pro TA) fails to work correctly with
2.4.2 kernel (upgrade of Wolverine - Seawolf). Has worked fine for 
months with 2.2.xx. I've re-installed 2.2.17-14 and it works fine.
What seems to happen is 'CONNECT 128000' response is not received
from modem, the subsequent PPP negotiation is, but WvDial is still
looking for the Carrier connection line.

I've dropped down into minicom on /dev/usb/ttySACM0 and manually 
dialling I see the same effect, PPP wibble straight after my ATDT string.
On 2.2.17-14 this works fine every time (I get <LF> CONNECT 128000 <LF>
PPP wibble). 


How Reproducible:
Completely. About 5% success with 2.4.2, 100% with 2.2.17-14.
I've also tried two other ISP's - just in case of simultaneous
meddling when I did my upgrade :-)


Steps to Reproduce:
1. ifup ppp0 or minicom -o ATDT08440416672
2. 
3. 

Actual Results: 
May  6 00:59:08 mouth WvDial: Modem initialized. 
May  6 00:59:08 mouth WvDial: Sending: ATDT 08440416672 
May  6 00:59:08 mouth WvDial: Waiting for carrier. 
May  6 00:59:08 mouth WvDial: ATDT 08440416672 
May  6 00:59:26 mouth WvDial: ~[7f]}#@!}!} } }2}!}$}%\}#}$@#}"}&} } } }
NM~~[7f]}#@!}!}!} }2}!}$}%\}#}$@#}"}&} } } } A]~~[7f]}#@!}!}"}
}2}!}$}%\}#}$@#}"}&} } } } Pm~~[7f]}#@!}!}#} }2}!}$}%\}#}$@#}"}&} } } }
_}~~[7f]}#@!}!}$} }2}!}$}%\}#}$@#}"}&} } } } r 
May  6 01:00:18 mouth WvDial: ~~[7f]}#@!}!}%} }2}!}$}%\}#}$@#}"}&} } } }
}][1d]~~[7f]}#@!}!}&} }2}!}$}%\}#}$@#}"}&} } } } l-~~[7f]}#@!}!}'}
}2}!}$}%\}#}$@#}"}&} } } } c=~~[7f]}#@!}!}(} }2}!}$}%\}#}$@#}"}&} } } }
6M~~[7f]}#@!}!})} }2}!}$}%\}#}$@#}"}&} } } } 9]~~[7f]}#@!}!}*}
}2}!}$}%\}#}$@#}"}&} } } } (m~ 
May  6 01:00:18 mouth WvDial: NO CARRIER 
May  6 01:00:18 mouth WvDial: No Carrier!  Trying again. 
May  6 01:00:21 mouth WvDial: Sending: ATDT 08440416672 


Expected Results:
May  6 01:03:44 mouth WvDial: Modem initialized. 
May  6 01:03:44 mouth WvDial: Sending: ATDT 08440416672 
May  6 01:03:44 mouth WvDial: Waiting for carrier. 
May  6 01:03:44 mouth WvDial: ATDT 08440416672 
May  6 01:03:46 mouth WvDial: CONNECT 128000 
May  6 01:03:46 mouth WvDial: Carrier detected.  Waiting for prompt. 
May  6 01:03:46 mouth WvDial: ~[7f]}#@!}!} } }2}!}$}%\}#}$@#}"}&} } } } NM~ 
May  6 01:03:46 mouth WvDial: PPP negotiation detected. 
May  6 01:03:46 mouth pppd[905]: Serial connection established.
May  6 01:03:46 mouth pppd[905]: Using interface ppp0
May  6 01:03:46 mouth pppd[905]: Connect: ppp0 <--> /dev/usb/ttyACM0
May  6 01:03:50 mouth kernel: PPP BSD Compression module registered
May  6 01:03:51 mouth kernel: PPP Deflate Compression module registered





Additional Information:
Celeron 500 MHz, 196MB RAM

May  6 00:47:15 mouth kernel: usb.c: registered new driver usbdevfs
May  6 00:47:15 mouth kernel: usb.c: registered new driver hub
May  6 00:47:15 mouth kernel: usb-uhci.c: $Revision: 1.251 $ time 20:53:29
Apr  8 2001
May  6 00:47:15 mouth kernel: usb-uhci.c: Highbandwidth mode enabled
May  6 00:47:15 mouth kernel: PCI: Found IRQ 11 for device 00:07.2
May  6 00:47:15 mouth kernel: usb-uhci.c: USB UHCI at I/O 0xe000, IRQ 11
May  6 00:47:15 mouth kernel: usb-uhci.c: Detected 2 ports
May  6 00:47:15 mouth kernel: usb.c: new USB bus registered, assigned bus
number 1
May  6 00:47:15 mouth kernel: hub.c: USB hub found
May  6 00:47:15 mouth kernel: hub.c: 2 ports detected
May  6 00:47:15 mouth kernel: hub.c: USB new device connect on bus1/1,
assigned device number 2
May  6 00:47:15 mouth kernel: usb.c: registered new driver acm
May  6 00:47:15 mouth kernel: ttyACM0: USB ACM device
May  6 00:47:15 mouth kernel: hub.c: USB new device connect on bus1/2,
assigned device number 3
May  6 00:47:16 mouth kernel: hub.c: USB hub found
May  6 00:47:16 mouth kernel: hub.c: 5 ports detected
Comment 1 Arjan van de Ven 2001-05-06 05:45:00 EDT
Can you try the kernel currently in rawhide? It has several USB bugfixes,
including fixes for modems.
Comment 2 Daniel Morris 2001-05-07 04:01:30 EDT
I get the same failure behaviour from both the kernels there 
(kernel-2.4.3-2.14.10.i686.rpm & kernel-2.4.3-2.14.14.i386.rpm)

Comment 3 Pete Zaitcev 2001-05-11 18:12:22 EDT
The hard part is that 2.2 and 2.4 versions of acm.c
are almost identical. The only interestig difference is
that 2.4 adds USB_NO_FSBR flag:

--- linux-2.2.18/drivers/usb/acm.c	Sun Dec 10 16:49:43 2000
+++ linux-2.4.4-niph/drivers/usb/acm.c	Fri Feb 16 16:06:17 2001
@@ -560,10 +563,12 @@
 
 		FILL_BULK_URB(&acm->readurb, dev, usb_rcvbulkpipe(dev,
epread->bEndpointAddress),
 			buf += ctrlsize, readsize, acm_read_bulk, acm);
+		acm->readurb.transfer_flags |= USB_NO_FSBR;
 
 		FILL_BULK_URB(&acm->writeurb, dev, usb_sndbulkpipe(dev,
epwrite->bEndpointAddress),
 			buf += readsize, acm->writesize, acm_write_bulk, acm);
-	
+		acm->writeurb.transfer_flags |= USB_NO_FSBR;
+
 		printk(KERN_INFO "ttyACM%d: USB ACM device\n", minor);
 
 		acm_set_control(acm, acm->ctrlout);

[there are also obvious changes for re-assignment of urb->dev
and new probing.]

Daniel, if you are willing to remove those FSBR things and
check it out, you are welcome to try. However, I think it
should be something else. A race, perhaps.
Comment 4 Pete Zaitcev 2001-05-11 18:31:27 EDT
On second thought, perhaps FSBR was the culprit, after all.
Look at this thread:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=97431673401127&w=2

I still think something is up in acm. You do not happen to
use it on SMP?
Comment 5 Pete Zaitcev 2001-05-21 14:25:25 EDT
Daniel, this is one of those things that has no easy resolution
as it is now. We have these options:

1. Mark the bug WONTFIX and make you recompile the
   kernel and manually remove FSBR's.
2. Again, have you a locally compiled kernel and
   then do the "remote debugging" thing: I will
   send patches, you will try them and report results.
   There is no guarantee of success, mind.

Sorry about it. Even if I had the hardware, I would have
nowhere to plug it.
Comment 6 Pete Zaitcev 2001-06-12 15:25:27 EDT
I am loth to add an option to the driver because it is
too kludgy.

Daniel, is there a chance you try the TA with an add-on
PCI card (almost all of them are OHCI)? This experiemnt
is important for my discussion with Linux USB group,
so it's ok if you just borrow the card or do other
one-off test.
Comment 7 Pete Zaitcev 2001-06-15 03:31:36 EDT
Created attachment 21144 [details]
Vojtech's gigantic buffer
Comment 8 Pete Zaitcev 2001-06-15 03:33:35 EDT
I am arguing with Vojtech about the problem.

Daniel, please let me know if you can test what he offers.
Comment 9 Daniel Morris 2001-06-16 18:05:19 EDT
The gigantic buffer patch made no improvement, I still get the same behaviour as
initially reported.
Next patch?
Comment 10 Daniel Morris 2001-06-16 18:07:17 EDT
I should have mentioned that I applied against 2.4.5-0.2.9 from Rawhide using
i686.config
Comment 11 Pete Zaitcev 2002-02-08 13:01:31 EST
Pavel keeps honking the same pipe "Depth-first, depth-first",
but the truth of the matter is that depth-first is not supported
well by usb-uchi.

I suggest we try the 2.4.9-21, on the off chance that
something works, and to establish the codebase. Then,
we add a module parameter to ACM.

This actually a very rare problem, specific to 3Com TA.
I think the TA is broken, but I am willing to work around that.
Comment 12 Pete Zaitcev 2002-10-31 18:17:01 EST
I'll put it into wontfix for now, because it cannot be resolved
without the hardware by us, and let's be honest - I am not working
on the bug actively. The community is the only hope.

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