Bug 39238
Summary: | Data being lost via USB | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Daniel Morris <danielm> | ||||
Component: | kernel | Assignee: | 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
Daniel Morris
2001-05-06 00:21:49 UTC
Can you try the kernel currently in rawhide? It has several USB bugfixes, including fixes for modems. 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) 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. 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? 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. 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. Created attachment 21144 [details]
Vojtech's gigantic buffer
I am arguing with Vojtech about the problem. Daniel, please let me know if you can test what he offers. The gigantic buffer patch made no improvement, I still get the same behaviour as initially reported. Next patch? I should have mentioned that I applied against 2.4.5-0.2.9 from Rawhide using i686.config 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. 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. |