Bug 145273 - USB Flash Disk Not Mounted 9 out of 10 times
USB Flash Disk Not Mounted 9 out of 10 times
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-16 09:39 EST by Brian G. Anderson
Modified: 2015-01-04 17:15 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-24 01:53:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian G. Anderson 2005-01-16 09:39:50 EST
Description of problem:
After upgrading to kernel 2.6.10-1.741_FC3 my flash disk isn't
recognized 9 out of time times.  Usually when plugging it in I get the
following errors in the log:
Jan 16 06:21:27 kelly kernel: usb 1-8: new high speed USB device using
ehci_hcd
and address 7
Jan 16 06:21:28 kelly kernel: usb 5-2: new full speed USB device using
uhci_hcd
and address 8
Jan 16 06:21:28 kelly kernel: usb 5-2: device descriptor read/64,
error -71
Jan 16 06:21:28 kelly kernel: usb 5-2: device descriptor read/64,
error -71
Jan 16 06:21:28 kelly kernel: usb 5-2: new full speed USB device using
uhci_hcd
and address 9
Jan 16 06:21:28 kelly kernel: usb 5-2: device descriptor read/64,
error -71
Jan 16 06:21:28 kelly kernel: usb 5-2: device descriptor read/64,
error -71



Version-Release number of selected component (if applicable):
2.6.10-1.741_FC3
however it also did this in the previous 2.6.10 kernels

How reproducible:
90% of the time.  It almost never recognizes the flash disk on the
first insertion.


Steps to Reproduce:
1. Start system
2. Plug in  flash disk
3.
  
Actual results:
Most of the time the disk won't mount

Expected results:
The disk should mount and I should get an icon on the desktop


Additional info:
If I boot with the disk in, it is recognized everytime.  I actually
run an AMD-64 with a 686 kernel and automatic mounting hasn't worked
for a while since there was a bug in the HAL daemon.  However, I was
alwasy able to mount the disk manually prior to the kernel 2.6.10 switch.
Comment 1 rob versluis 2005-01-18 01:52:13 EST
Since upgrading to kernel 2.6.10-1.741_FC3 I also have the same
problem; every fourth try is a hit:-)
Comment 2 Peter Lawler 2005-01-19 16:08:53 EST
2.6.10-1.741_FC3smp here. I haven't had one successful mount yet,
exactly the same error message, however. I guess I'll just have to
keep trying. Haven't tried a cold boot with the stick inserted, yet.
Maybe previous mounts were successful because it was inserted, I can't
be too sure.
Comment 3 Peter Lawler 2005-01-19 16:16:59 EST
OK, I tried several more times. It eventually mounted. Here's the log
messages (my apologies for the qc-usb noise in here, but I guess it's
best for you to have all the info than none). One thing I notice, is
that I've never named the device. The last system I had it in was a
Mac, which called it 'Noname', or similar. This is the second time
I've noticed it's been named something I never gave it (last time, it
was C_).

Jan 20 08:11:28 dhcppc1 kernel: usb 1-8: new high speed USB device
using ehci_hcd and address 12
Jan 20 08:11:28 dhcppc1 kernel: quickcam: frame lost
Jan 20 08:11:29 dhcppc1 kernel: Initializing USB Mass Storage driver...
Jan 20 08:11:29 dhcppc1 kernel: scsi2 : SCSI emulation for USB Mass
Storage devices
Jan 20 08:11:29 dhcppc1 kernel: usbcore: registered new driver usb-storage
Jan 20 08:11:29 dhcppc1 kernel: USB Mass Storage support registered.
Jan 20 08:11:34 dhcppc1 kernel:   Vendor: STF       Model: Flash Drive
2.0   Rev: 2.00
Jan 20 08:11:34 dhcppc1 kernel:   Type:   Direct-Access              
       ANSI SCSI revision: 02
Jan 20 08:11:34 dhcppc1 kernel: sdc: Unit Not Ready, sense:
Jan 20 08:11:34 dhcppc1 kernel: Current : sense key Unit Attention
Jan 20 08:11:34 dhcppc1 kernel: Additional sense: Not ready to ready
change, medium may have changed
Jan 20 08:11:34 dhcppc1 kernel: sdc : READ CAPACITY failed.
Jan 20 08:11:34 dhcppc1 kernel: sdc : status=1, message=00, host=0,
driver=08
Jan 20 08:11:34 dhcppc1 kernel: Current sd: sense key Unit Attention
Jan 20 08:11:34 dhcppc1 kernel: Additional sense: Not ready to ready
change, medium may have changed
Jan 20 08:11:34 dhcppc1 kernel: sdc: test WP failed, assume Write Enabled
Jan 20 08:11:34 dhcppc1 kernel: sdc: assuming drive cache: write through
Jan 20 08:11:34 dhcppc1 kernel: sdc: Unit Not Ready, sense:
Jan 20 08:11:34 dhcppc1 kernel: Current : sense key Unit Attention
Jan 20 08:11:34 dhcppc1 kernel: Additional sense: Not ready to ready
change, medium may have changed
Jan 20 08:11:34 dhcppc1 kernel: sdc : READ CAPACITY failed.
Jan 20 08:11:34 dhcppc1 kernel: sdc : status=1, message=00, host=0,
driver=08
Jan 20 08:11:34 dhcppc1 kernel: Current sd: sense key Unit Attention
Jan 20 08:11:34 dhcppc1 kernel: Additional sense: Not ready to ready
change, medium may have changed
Jan 20 08:11:34 dhcppc1 kernel: sdc: test WP failed, assume Write Enabled
Jan 20 08:11:34 dhcppc1 kernel: sdc: assuming drive cache: write through
Jan 20 08:11:34 dhcppc1 kernel: sdc: Unit Not Ready, sense:
Jan 20 08:11:34 dhcppc1 kernel: Current : sense key Unit Attention
Jan 20 08:11:34 dhcppc1 kernel: Additional sense: Not ready to ready
change, medium may have changed
Jan 20 08:11:34 dhcppc1 kernel: sdc : READ CAPACITY failed.
Jan 20 08:11:34 dhcppc1 kernel: sdc : status=1, message=00, host=0,
driver=08
Jan 20 08:11:34 dhcppc1 kernel: Current sd: sense key Unit Attention
Jan 20 08:11:34 dhcppc1 kernel: Additional sense: Not ready to ready
change, medium may have changed
Jan 20 08:11:34 dhcppc1 kernel: sdc: test WP failed, assume Write Enabled
Jan 20 08:11:34 dhcppc1 kernel: sdc: assuming drive cache: write through
Jan 20 08:11:34 dhcppc1 kernel:  sdc:end_request: I/O error, dev sdc,
sector 0
Jan 20 08:11:34 dhcppc1 kernel: Buffer I/O error on device sdc,
logical block 0
Jan 20 08:11:34 dhcppc1 udev[26138]: configured rule in
'/etc/udev/rules.d/10-qcam.rules' at line 1 applied, added symlink
'qcam%e'
Jan 20 08:11:34 dhcppc1 scsi.agent[26140]: disk at
/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0/host2/target2:0:0/2:0:0:0
Jan 20 08:11:35 dhcppc1 kernel: Buffer I/O error on device sdc,
logical block 0
Jan 20 08:11:35 dhcppc1 udev[26138]: configured rule in
'/etc/udev/rules.d/10-qcam.rules' at line 1 applied, 'sdc' becomes '%k'
Jan 20 08:11:35 dhcppc1 kernel: Buffer I/O error on device sdc,
logical block 0
Jan 20 08:11:35 dhcppc1 udev[26138]: creating device node '/dev/sdc'
Jan 20 08:11:35 dhcppc1 kernel:  unable to read partition table
Jan 20 08:11:35 dhcppc1 05-pam_console.dev[26161]: Restoring console
permissions for /dev/sdc  /dev/qcam4
Jan 20 08:11:35 dhcppc1 kernel: Attached scsi removable disk sdc at
scsi2, channel 0, id 0, lun 0
Jan 20 08:11:35 dhcppc1 kernel: SCSI device sdc: 1024000 512-byte hdwr
sectors (524 MB)
Jan 20 08:11:35 dhcppc1 kernel: sdc: Write Protect is off
Jan 20 08:11:35 dhcppc1 kernel: sdc: assuming drive cache: write through
Jan 20 08:11:35 dhcppc1 udev[26171]: configured rule in
'/etc/udev/rules.d/10-qcam.rules' at line 1 applied, added symlink
'qcam%e'
Jan 20 08:11:35 dhcppc1 kernel: SCSI device sdc: 1024000 512-byte hdwr
sectors (524 MB)
Jan 20 08:11:35 dhcppc1 udev[26171]: configured rule in
'/etc/udev/rules.d/10-qcam.rules' at line 1 applied, 'sdc1' becomes '%k'
Jan 20 08:11:35 dhcppc1 kernel: sdc: Write Protect is off
Jan 20 08:11:35 dhcppc1 udev[26171]: creating device node '/dev/sdc1'
Jan 20 08:11:35 dhcppc1 05-pam_console.dev[26178]: Restoring console
permissions for /dev/sdc1  /dev/qcam5
Jan 20 08:11:35 dhcppc1 kernel: sdc: assuming drive cache: write through
Jan 20 08:11:35 dhcppc1 kernel:  sdc: sdc1
Jan 20 08:11:35 dhcppc1 fstab-sync[26188]: added mount point /media/D_
for /dev/sdc1
Comment 4 Brian G. Anderson 2005-01-20 07:37:58 EST
I'm wondering if it is a USB 2.0 issue.  I tried with an older USB 1.0
flash stick and it mounts every time.
Comment 5 Peter Lawler 2005-01-24 15:35:32 EST
from the FC mail-list (I haven't tried this yet)
----
If you google a bit you'll discover that the problem is a supposedly
"smart" change in the way usbcore probes new devices (now done "a la
Windows, ah, ah, at least on Windows they mount...)

Try with (as root)

echo -n "Y" > /sys/module/usbcore/parameters/old_scheme_first
echo -n "Y" > /sys/module/usbcore/parameters/use_both_schemes

which should revert to the "old" way. After these changes my pens all
mount with no problem, including those which ran into the same issue
you had.

                     Alfredo
Comment 6 Thomas Walker 2005-01-24 20:37:17 EST
an additional helpful bit (to those using the stock RH kernels which
have usbcore compiled in), add to your boot params
(/boot/grub/grub.conf)  "usbcore.old_scheme_first=y" which takes care
of things.
I understand from various mailinglists that there is a nondefault "try
both schemes" option (I forget the option name exactly) which probably
*should* have been the default here.  Any chance RH would push for
that upstream?
I can try looking it up again if need be...
Comment 7 Peter Lawler 2005-01-24 20:45:04 EST
Thanks Thomas. I'll try that next boot.

Something i did notice, was that
echo -n "Y" > /sys/module/usbcore/parameters/blinkenlights

produced a permission denied (when executed as root). I know this post
may be moving OT, but thought I might mention it if it were of any value.
Comment 8 Michael Katzmann 2005-01-30 23:14:42 EST
I'm getting this problem with a USB hard disk ME-720

device descriptor read/64, error -71

the usbcore.old_scheme_first=y causes the boot to hang (at cups I think)
Comment 9 Michael Katzmann 2005-01-30 23:31:00 EST
I tried again, and it does boot OK if I include BOTH the parameters
usbcore.old_scheme_first=y AND usbcore.use_both_schemes=y
however the drive will still not mount.
The following is the /var/log/messages output.
I can mount the drive sucessfully if I use the slow speed USB, or the
firewire (the drive has both USB and Firewire).

Jan 30 23:23:09 industrynumbers kernel: sda : READ CAPACITY failed.
Jan 30 23:23:09 industrynumbers kernel: sda : status=0, message=00,
host=7, driver=00
Jan 30 23:23:09 industrynumbers kernel: sda : sense not available.
Jan 30 23:23:09 industrynumbers kernel: sda: Write Protect is off
Jan 30 23:23:09 industrynumbers kernel: sda: assuming drive cache:
write through
Jan 30 23:23:09 industrynumbers kernel: sda : READ CAPACITY failed.
Jan 30 23:23:09 industrynumbers kernel: sda : status=0, message=00,
host=7, driver=00
Jan 30 23:23:09 industrynumbers kernel: sda : sense not available.
Jan 30 23:23:09 industrynumbers kernel: sda: Write Protect is off
Jan 30 23:23:09 industrynumbers kernel: sda: assuming drive cache:
write through
Jan 30 23:23:09 industrynumbers kernel:  sda:<3>Buffer I/O error on
device sda, logical block 0
Jan 30 23:23:09 industrynumbers kernel: Buffer I/O error on device
sda, logical block 0
Jan 30 23:23:09 industrynumbers kernel: Buffer I/O error on device
sda, logical block 0
Jan 30 23:23:09 industrynumbers kernel:  unable to read partition table
Jan 30 23:23:09 industrynumbers kernel: sdb : READ CAPACITY failed.
Jan 30 23:23:09 industrynumbers kernel: sdb : status=0, message=00,
host=7, driver=00
Jan 30 23:23:09 industrynumbers kernel: sdb : sense not available.
Jan 30 23:23:09 industrynumbers kernel: sdb: Write Protect is off
Jan 30 23:23:09 industrynumbers kernel: sdb: assuming drive cache:
write through
Jan 30 23:23:09 industrynumbers kernel: sdb : READ CAPACITY failed.
Jan 30 23:23:09 industrynumbers kernel: sdb : status=0, message=00,
host=7, driver=00
Jan 30 23:23:09 industrynumbers kernel: sdb : sense not available.
Jan 30 23:23:09 industrynumbers kernel: sdb: Write Protect is off
Jan 30 23:23:09 industrynumbers kernel: sdb: assuming drive cache:
write through
Jan 30 23:23:09 industrynumbers kernel:  sdb:<3>Buffer I/O error on
device sdb, logical block 0
Jan 30 23:23:09 industrynumbers kernel: Buffer I/O error on device
sdb, logical block 0
Jan 30 23:23:09 industrynumbers kernel: Buffer I/O error on device
sdb, logical block 0
Jan 30 23:23:09 industrynumbers kernel:  unable to read partition table
Comment 10 rob versluis 2005-02-03 01:44:54 EST
kernel-2.6.10-1.760_FC3 did not fix the problem:

usb 3-2: new full speed USB device using uhci_hcd and address 11
usb 3-2: device descriptor read/64, error -71


After serveral tries it's surrenders:

usb 1-4: new high speed USB device using ehci_hcd and address 7
SCSI subsystem initialized
Initializing USB Mass Storage driver...
Comment 11 Marek Kassur 2005-02-05 20:20:33 EST
Same problem with Samsung USB 2.0 pen (ID 04e8:0111). It always work
when connected to USB 1.1 Hub, so it appears as 2.0 issue. 

Take a look at this post:
http://www.spinics.net/lists/usb/msg02644.html

I also think that old_scheme and use_both should be the default.
Comment 12 Dave Jones 2005-02-24 02:09:23 EST
I made this change in the 766 errata. any improvement ?
Comment 13 Marek Kassur 2005-02-24 13:36:02 EST
use_both_schemes is not enough in my case, old_scheme_first is also required.
Comment 14 Brian G. Anderson 2005-02-24 15:00:06 EST
I need to enable old_scheme_first also.
Comment 15 Dave Jones 2005-02-24 15:12:59 EST
ok, I made this change too in cvs. it'll be in the next build.
Comment 16 Peter Lawler 2005-02-24 15:45:41 EST
Just woke up to these updates. My situation is the same as #comment 13 (need
both). It also 'makes sense' to me that one should try the 'Proper' method
before the 'Windows only' method. Hopefully that won't break real dumb devices.

I'll update here once a new kernel's out.
Comment 17 Joe Harrington 2005-04-07 21:42:50 EDT
There are reports of similar problems over on bug 150605, and a few others. 
They are not being solved by

echo -n "Y" > /sys/module/usbcore/parameters/old_scheme_first
echo -n "Y" > /sys/module/usbcore/parameters/use_both_schemes

and they persist in kernel-2.6.10-1.770_FC3.  In my case they are 100%
reproducible: no usb device has ever mounted at 2.0 speeds for me under FC3, and
I have tried a 2GB Corsair memory stick and a Sony DRX-500 ULX DVD +- RW drive.
If I 
rmmod ehci_hcd
and plug the devices in, they work fine at USB 1.1 speeds.  But, a DVD writer is
useless at that speed.

When I plug a device in, these messages get generated until the device is unplugged:

Apr  4 22:37:59 glup kernel: usb 1-3: new high speed USB device using ehci_hcd
and address 41
Apr  4 22:37:59 glup kernel: usb 1-3: device not accepting address 41, error -71
Apr  4 22:38:00 glup kernel: usb 1-3: new high speed USB device using ehci_hcd
and address 46
Apr  4 22:38:01 glup kernel: usb 1-3: device not accepting address 46, error -71
Apr  4 22:38:07 glup kernel: usb 1-3: new high speed USB device using ehci_hcd
and address 74
Apr  4 22:38:08 glup kernel: usb 1-3: device not accepting address 74, error -71
Apr  4 22:38:09 glup kernel: usb 1-3: new high speed USB device using ehci_hcd
and address 78
Apr  4 22:38:09 glup kernel: usb 1-3: device not accepting address 78, error -71

See more on bug 150605.  Let me know what other info you need for this one, or
if there is an new version to try.

Thanks,

--jh--
Comment 18 Joe Harrington 2005-04-13 10:28:19 EDT
Both my devices still fail the same way for the rebased kernel,
kernel-2.6.11-1.14_FC3.  The memory stick works in USB 2.0 under Windows XP
(couldn't test the DVD writer, the XP machine is at home, but it worked under FC1).

--jh--
Comment 19 Dave Jones 2005-07-15 15:43:39 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 20 Joe Harrington 2005-07-19 11:12:52 EDT
Same problem under new kernel (see bug 150605 for messages attachment).

--jh--
Comment 21 Bryn M. Reeves 2005-09-19 05:54:05 EDT
same problem under fc4, with an IBM thinkpad T41, using Intel EHCI. 

Relevant bits of lspci:

00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI
Controller (rev 01)

Both old & new scheme fail for me with better than 99% reproducibility,
regardless of the setting of old_scheme_first - USB2.0 is basically unusable on
this machine. 

Errors in both cases return -71 (protocol error?)

A variety of USB2.0 devices have been tested (flash, HD, ipod etc.), some are
less prone to the problem, but the variation is marginal at best.

This issue has suddenly become more critical for me (storage needs now mean
fallback to USB1.1 is not practical), so more than happy to test any potential
workarounds. 

kernels tested so far:

kernel-2.6.11-1.1369_FC4
kernel-2.6.12-1.1398_FC4
kernel-2.6.12-1.1447_FC4
kernel-2.6.12-1.1450_FC4

Will try 2.6.13 today.

Regards,
bmr.
Comment 22 Bryn M. Reeves 2005-09-19 11:00:46 EDT
Just confirmed upstream 2.6.13 has the same issue. Will try 2.6.13.1, but I'm
not hopeful - early 2.6's did not suffer from this (before the
usbcore/usb-skeleton re writes I think, but I'm guessing there :)

Regards,
bmr.
Comment 23 Bryn M. Reeves 2005-09-19 14:07:34 EDT
OK, well this is fixed for me - it's a power issue. 

Some googling indicated this could be the case. Using a powered USB2.0 hub
(taking the power of the second USB port on the T41) completely eliminates the
'device not accepting address' errors, and allows the devices to successfuly
register as high speed devices - hurrah! 

Also tested with an external PSU to be sure.

What's interesting is that the previous user of the laptop claimed to have used
USB2.0 without issue on older kernels - I'll try to verify this and update if
this is the case. 

Comment 24 Dipjyoti Bharali 2013-07-25 00:38:22 EDT
Seen again in Fedora 19. Had to add the two usbcore parameters to grub2 CMDLINE.
After rebooting, it finally worked like before.

Was happening for only certain devices, not all. Well, after the change things are normal again.

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