Bug 123622
Summary: | (USB SCSI)USB storage does not work at all | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nicholas Allen <nick.allen> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED NEXTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | pfrields |
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: | 2005-04-16 05:34:46 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: |
Description
Nicholas Allen
2004-05-19 18:30:29 UTC
Here is the output of /var/log/messages at the time I plugged the USB disk in: May 21 15:49:27 localhost kernel: usb 1-2: new full speed USB device using address 2 May 21 15:49:27 localhost kernel: scsi1 : SCSI emulation for USB Mass Storage devices May 21 15:49:27 localhost kernel: Vendor: SigmaTel Model: MSCN Rev: 0001 May 21 15:49:27 localhost kernel: Type: Direct-Access ANSI SCSI revision: 02 May 21 15:49:28 localhost kernel: SCSI device sdb: 256001 512-byte hdwr sectors (131 MB) May 21 15:49:28 localhost kernel: sdb: assuming Write Enabled May 21 15:49:28 localhost kernel: sdb: assuming drive cache: write through May 21 15:49:28 localhost kernel: sdb:<6>Device not ready. Make sure there is a disc in the drive. May 21 15:49:28 localhost kernel: end_request: I/O error, dev sdb, sector 256000 May 21 15:49:28 localhost kernel: Buffer I/O error on device sdb, logical block 256000 May 21 15:49:28 localhost kernel: Device not ready. Make sure there is a disc in the drive. I have the same problem with an USB to IDE mass storage device. The device, when being plugged into an arbitrary USB port on my SONY VAIO FR-285 notebook, is not correctly recognized and refuses to take any of the kernel offered device addresses. The kernel probes seemingly endlessly for subsequent device addresses, which all will fail. Now I have tried my USB mouse, too and that working fine, I re-tried to install the mass storage device. And now it worked, the device was recognized (with the mouse being plugged in first) and was even listed by /sbin/lsusb. However, the partition table could not be read and the data on the drive was not accessible (I verified this using /sbin/fdisk -l /dev/sda). Since I did not want to destroy the current partitioning scheme and subsequently the data I have backed up onto the drive, I did not verify if I was able to partition the drive and then mkfs-ing and mounting the newly created filesystems. Perhaps this gives you some clues on where to look for a hotfix for this badly needed feature! I will soon attach some output when trying to plug in the drive when no mouse is being attached to the usb port... Here is some sample output when plugging in the USB mass storage device (USB to IDE) without the mouse being attached: usb 1-5: control timeout on ep0out usb 1-5: Device not accepting address 2, error -110 usb 1-5: control timeout on ep0out usb 1-5: control timeout on ep0out usb 1-5: Device not accepting address 3, error -110 [...] usb 1-5: control timeout on ep0out usb 1-5: control timeout on ep0out usb 1-5: Device not accepting address <n>, error -110 Now, the kernel tries seemingly endlessly (at least I waited one time until <n> reached 27) to install the driver and the device. I have tried to plug in the mouse on that occasion and as soon as it is plugged in the kernel stops trying to install the USB to IDE device and will not continue to do so until it is unplugged and then being plugged into the USB port again. Then the kernel will continue with the above error reporting. I could not reproduce the state of the device being installed and recognized by the kernel, however. It seems that that was an unwanted and non-reproducible, but most-wanted side-effect of the above bug ;-)... Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you. |