Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236450 - USB mount needs three attempts; read/64, error -71; not accepting address;
Summary: USB mount needs three attempts; read/64, error -71; not accepting address;
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 427887
TreeView+ depends on / blocked
 
Reported: 2007-04-14 13:13 UTC by Michael De La Rue
Modified: 2008-06-17 01:17 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-17 01:17:57 UTC


Attachments (Terms of Use)
Messages output during three attempts. (deleted)
2007-04-14 13:13 UTC, Michael De La Rue
no flags Details
Log of inserting same key in FC4 (everything works)b (deleted)
2007-04-16 07:05 UTC, Michael De La Rue
no flags Details
Log of inserting via a hub in a monitor. (deleted)
2007-04-21 07:29 UTC, Michael De La Rue
no flags Details
log after echo -n Y > /sys/module/usbcore/parameters/old_scheme_first (deleted)
2007-09-21 06:39 UTC, Michael De La Rue
no flags Details
usbmon trace of insertion then reinsertion of pen drive (deleted)
2007-09-21 22:57 UTC, Michael De La Rue
no flags Details
/proc/bus/usb/devices (deleted)
2007-09-22 11:26 UTC, Michael De La Rue
no flags Details

Description Michael De La Rue 2007-04-14 13:13:19 UTC
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=

Comment 1 Michael De La Rue 2007-04-14 13:13:19 UTC
Created attachment 152612 [details]
Messages output during three attempts.

Comment 2 Pete Zaitcev 2007-04-15 06:56:49 UTC
It's fairly common for flash keys to go bad this way. Does it work in
other computers?


Comment 3 Michael De La Rue 2007-04-16 06:27:30 UTC
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.     

Comment 4 Michael De La Rue 2007-04-16 07:01:34 UTC
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

Comment 5 Michael De La Rue 2007-04-16 07:05:54 UTC
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.

Comment 6 Pete Zaitcev 2007-04-16 18:31:58 UTC
Does the key work when connected through an external hub?
(I suspect the port sharing between EHCI and its companion)


Comment 7 Michael De La Rue 2007-04-21 07:29:17 UTC
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).

Comment 8 Pete Zaitcev 2007-09-07 23:43:30 UTC
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?

Comment 9 Michael De La Rue 2007-09-19 21:48:11 UTC
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.

Comment 10 Michael De La Rue 2007-09-20 18:32:30 UTC
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


Comment 11 Pete Zaitcev 2007-09-20 18:57:15 UTC
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


Comment 12 Michael De La Rue 2007-09-21 06:39:42 UTC
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.

Comment 13 Pete Zaitcev 2007-09-21 17:07:11 UTC
You always have usbmon, it's just built statically. Just go ahead an mount
debugfs and you should see /sys/kernel/debug/usbmon/Nt.

Comment 14 Michael De La Rue 2007-09-21 22:57:56 UTC
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.

Comment 15 Pete Zaitcev 2007-09-21 23:55:08 UTC
OMG that's one monster trace. Thanks for geting it.
BTW, how about /proc/bus/usb/devices?

Comment 16 Michael De La Rue 2007-09-22 11:26:27 UTC
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.

Comment 17 Michael De La Rue 2007-10-09 20:48:10 UTC
I'm running 2.6.22.5-76.fc7 today and it seems that my device always works first
time...  Did someone fix something???

Comment 18 Pete Zaitcev 2007-10-09 21:30:33 UTC
But this is the same version as the one in devices file you posted above.

Comment 19 Michael De La Rue 2007-10-10 06:08:43 UTC
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..  



Comment 20 Chuck Ebbert 2007-10-10 16:47:29 UTC
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


Comment 21 Michael De La Rue 2007-12-25 09:27:10 UTC
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

Comment 22 Jon Stanley 2008-01-08 01:50:03 UTC
(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!

Comment 23 Michael De La Rue 2008-01-08 06:44:21 UTC
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.  

Comment 24 Bug Zapper 2008-05-14 12:12:42 UTC
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

Comment 25 Bug Zapper 2008-06-17 01:17:55 UTC
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.


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