Bug 236450
| Summary: | USB mount needs three attempts; read/64, error -71; not accepting address; | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael De La Rue <mvyynqbgerqungqbgpbz.yeuhc> |
| Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7 | CC: | cebbert, davej, jonstanley, triage |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-06-17 01:17:57 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 427887 | ||
| Attachments: | |||
Created attachment 152612 [details]
Messages output during three attempts.
It's fairly common for flash keys to go bad this way. Does it work in other computers? Hmm.. It does work in all the computers I use it with. It's very new and hasn't yet been badly treated in any way. On an old fedora release it needs to be manually mounted. I'll try around a few more. Confirmed; On an old FC4 system it works instantly and the same on an RHEL4. There's one strange thing in that it comes up as 4.2G media, but the size reported by DF is correct. b Created attachment 152668 [details]
Log of inserting same key in FC4 (everything works)b
Confirmed; On an old FC4 system it works instantly and the same on an RHEL4.
There's one strange thing in that it comes up as 4.2G media, but the size
reported by DF is correct.
Does the key work when connected through an external hub? (I suspect the port sharing between EHCI and its companion) Created attachment 153235 [details]
Log of inserting via a hub in a monitor.
With some difficulty I've borrowed a USB hub (actually an entire monitor).. and
it does make a difference. I think this also behaves differently depending on
which port it's plugged into. It's also different on the second attempt after
unmounting (only needs one insert-remove cycle).
Peter Jones implemented a fix to mkinitrd to make ehci always loaded first. It is available in Rawhide as mkinitrd-6.0.14-1.fc8. This should help issues where EHCI disturbs its companion. In this case, however, this might not fix things completely, because on second reading it seems that the device tricks our EHCI into trying it repeatedly and returns to UCHI only when EHCI gives up. Normally, it should be one read off root hub status instead of trying to fetch descriptors. I have to admit, I don't know why FC4 used a full-speed controller from the outset (see log in comment #5). Michael, what is the box+key doing currently? Same thing, I presume? Last time I tested (a month ago?) same thing. I don't have the device right now, but will try to get it/one again and see. I found the device again. Put it in once; wait 10 seconds nothing happens (20:25:54->56) ; put it in again and it is recognised a short time later (20:26:13->19) Sep 20 20:22:18 telesfor gconfd (root-3244): Exiting Sep 20 20:25:54 telesfor kernel: usb 5-8: new high speed USB device using ehci_hcd and address 5 Sep 20 20:25:54 telesfor kernel: usb 5-8: device descriptor read/64, error -71 Sep 20 20:25:54 telesfor kernel: usb 5-8: device descriptor read/64, error -71 Sep 20 20:25:55 telesfor kernel: usb 5-8: new high speed USB device using ehci_hcd and address 6 Sep 20 20:25:55 telesfor kernel: usb 5-8: device descriptor read/64, error -71 Sep 20 20:25:55 telesfor kernel: usb 5-8: device descriptor read/64, error -71 Sep 20 20:25:55 telesfor kernel: usb 5-8: new high speed USB device using ehci_hcd and address 7 Sep 20 20:25:56 telesfor kernel: usb 5-8: device not accepting address 7, error -71 Sep 20 20:25:56 telesfor kernel: usb 5-8: new high speed USB device using ehci_hcd and address 8 Sep 20 20:25:56 telesfor kernel: usb 5-8: device not accepting address 8, error -71 Sep 20 20:26:13 telesfor kernel: usb 5-8: new high speed USB device using ehci_hcd and address 9 Sep 20 20:26:13 telesfor kernel: usb 5-8: configuration #1 chosen from 1 choice Sep 20 20:26:13 telesfor kernel: scsi5 : SCSI emulation for USB Mass Storage devices Sep 20 20:26:18 telesfor kernel: scsi 5:0:0:0: Direct-Access USB 2.0 Flash Disk 4.00 PQ: 0 ANSI: 2 Sep 20 20:26:18 telesfor kernel: sd 5:0:0:0: [sdh] 511487 2048-byte hardware sectors (1048 MB) Sep 20 20:26:18 telesfor kernel: sd 5:0:0:0: [sdh] Write Protect is off Sep 20 20:26:18 telesfor kernel: sd 5:0:0:0: [sdh] Assuming drive cache: write through Sep 20 20:26:18 telesfor kernel: sd 5:0:0:0: [sdh] 511487 2048-byte hardware sectors (1048 MB) Sep 20 20:26:18 telesfor kernel: sd 5:0:0:0: [sdh] Write Protect is off Sep 20 20:26:18 telesfor kernel: sd 5:0:0:0: [sdh] Assuming drive cache: write through Sep 20 20:26:18 telesfor kernel: sdh: unknown partition table Sep 20 20:26:18 telesfor kernel: sd 5:0:0:0: [sdh] Attached SCSI removable disk Sep 20 20:26:18 telesfor kernel: sd 5:0:0:0: Attached scsi generic sg9 type 0 Sep 20 20:26:19 telesfor hald: mounted /dev/sdh on behalf of uid 500 Michael, while you're hot, please capture a usbmon trace for me, but do not drop it into comments like the above, attach as a file please. There's a HOWTO in this: /usr/share/doc/kernel-doc-2.6.22/Documentation/usb/usbmon.txt If a "0u" socket exists on your kernel, please use that. Not sure what verion it comes with thought, F7 might not have it yet. Also, please save /proc/bus/usb/devices. If we have a usbmon trace and the devices file, we may be able to hash this out gradually. Enumeration issues are always tricky and take forever to work around. Once you've got the problem trace, please try this: # echo -n Y > /sys/module/usbcore/parameters/old_scheme_first Created attachment 201711 [details]
log after echo -n Y > /sys/module/usbcore/parameters/old_scheme_first
Well; I don't have usbmon on my system; "modprobe usbmon" fails; "locate
usbmon" fails and "yum whatprovides usbmon"* fails. I guess I have to do a
kernel rebuild?? Not this morning anyway. Instructions appreciated if any.
Setting the old_scheme_first doesn't seem to make any difference. However it
seems to me that the main thing I have to do to get it to work is to pull out
and get it back in before the USB disconnect message has come through.
You always have usbmon, it's just built statically. Just go ahead an mount debugfs and you should see /sys/kernel/debug/usbmon/Nt. Created attachment 202861 [details]
usbmon trace of insertion then reinsertion of pen drive
In this trace I first insert the pen drive, which fails to mount, then remove
and reinsert it quicky enough to get it to mount.
OMG that's one monster trace. Thanks for geting it. BTW, how about /proc/bus/usb/devices? Created attachment 202981 [details]
/proc/bus/usb/devices
I saw it was producing data pretty fast and tried to minimise the recording
time I doubt there was more than a second of extra messages in the last log :-)
this time here's cat /proc/bus/usb/devices with the pen drive actually mounted.
I'm running 2.6.22.5-76.fc7 today and it seems that my device always works first time... Did someone fix something??? But this is the same version as the one in devices file you posted above. Okay, I've had been running my system for a several days with multiple hibernates. (at least one a day for five days). For some reason the device started working on it's own. The difference was that the light stayed on for a long time and then the mount took place. After a reboot (to 2.6.22.9-91.fc7) the old behavior is back. When the device is inserted the light lights but after three seconds the light goes off and the device is never recognised... Hmm.. I have these patches to Fedora 7 recently, maybe one of them fixed the problem: linux-2.6-usb-allow-1-byte-replies.patch linux-2.6-usb-fixup-interval-lengths.patch This remains reproducable with Linux x.example.com 2.6.23.8-34.fc7 #1 SMP Thu Nov 22 23:05:33 EST 2007 i686 athlon i386 GNU/Linux (This is a mass-update to all current FC6 kernel bugs in NEW state) Hello, I'm reviewing this bug list as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug, however this version of Fedora is no longer maintained. Please attempt to reproduce this bug with a current version of Fedora (presently Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a few days if there is no further information lodged. Thanks for using Fedora! Not actually verified in F8 yet but still present in the latest kernel in F7 so I'm replying to this and updating the version. This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: My 1G USB pendrive works only on the third insertion. For the first two times it is recognised by the USB system as a device, but communiction fails ("device descriptor read/64, error -71" / "device not accepting address 8, error -71" etc) Version-Release number of selected component (if applicable): 2.6.19-1.2911.6.4.fc6xen How reproducible: every time Steps to Reproduce: 1. boot 2. insert pen drive 3. wait 4. remove pen drive 5. repeat steps 2 to 4 6. repeat steps 2 to 3 Actual results: The pen drive is recognised and mounted after step 6; a window opens on the Gnome desktop. Expected results: The pen drive is recognised and mounted after step 3. Additional info: [root@telesfor log]# lsusb | grep -v 0000 Bus 002 Device 002: ID 055d:1030 Samsung Electro-Mechanics Co. Bus 002 Device 003: ID 046d:08da Logitech, Inc. Bus 005 Device 014: ID 0204:6025 Bus 005 Device 002: ID 05e3:0710 Genesys Logic, Inc. USB 2.0 33-in-1 Card Reader I looked through a bunch of bugs, but couldn't find one very similar to this.. https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Core&version=fc6&short_desc_type=allwordssubstr&short_desc=USB&long_desc_type=allwordssubstr&long_desc=