Bug 39238

Summary: Data being lost via USB
Product: [Retired] Red Hat Linux Reporter: Daniel Morris <danielm>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-02-08 18:01:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Vojtech's gigantic buffer none

Description Daniel Morris 2001-05-06 00:21:49 UTC
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 09:45:00 UTC
Can you try the kernel currently in rawhide? It has several USB bugfixes,
including fixes for modems.

Comment 2 Daniel Morris 2001-05-07 08:01:30 UTC
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 22:12:22 UTC
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 22:31:27 UTC
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 18:25:25 UTC
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 19:25:27 UTC
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 07:31:36 UTC
Created attachment 21144 [details]
Vojtech's gigantic buffer

Comment 8 Pete Zaitcev 2001-06-15 07:33:35 UTC
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 22:05:19 UTC
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 22:07:17 UTC
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 18:01:31 UTC
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 23:17:01 UTC
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.