USB mass storage stops working after a while

Bug #61235 reported by Gustavo Carneiro
456
This bug affects 12 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Medium
Unassigned
linux-source-2.6.17 (Ubuntu)
Fix Released
Undecided
Unassigned
linux-source-2.6.19 (Ubuntu)
Invalid
Undecided
Unassigned
linux-source-2.6.20 (Ubuntu)
Won't Fix
Medium
Unassigned
linux-source-2.6.22 (Ubuntu)
Won't Fix
Undecided
Unassigned
udev (Ubuntu)
Invalid
Wishlist
Unassigned

Bug Description

I just plugin an external USB 2.0 hard disk. It is detected and seems to work.
However, when I start copying large files it stops working (unmounts itself) after a while.

Revision history for this message
Gustavo Carneiro (gjc) wrote :

About this part:

[37974.978380] 0:0:0:0: rejecting I/O to dead device
[37974.978383] Buffer I/O error on device sda2, logical block 0
[37974.978385] lost page write due to I/O error on sda2
[38055.734000] usb 3-3: new high speed USB device using ehci_hcd and address 7
[38061.499838] usb 3-3: device not accepting address 7, error -110

I just power cycled the external disk, but after the first failure the "device not accepting address" errors are repeated and never again does mass storage work until reboot.

Revision history for this message
Gustavo Carneiro (gjc) wrote :
Revision history for this message
John Dong (jdong) wrote :

I can confirm this happening on two Centrino Duo laptops. The problem is quite fascinating in my testing: (fascinating meaning that the ubuntu kernel team should probably reach for aspirin before reading on)

(1) It happens only when certain USB mass storage devices AND certain USB controllers are combined. A RockChip USB MP3 player and the Centrino Duo causes this to happen, while a Sandisk MP3 player (or a no-name external hard drive) and the same USB chipset does not cause the problem.

(2) The problematic device, when connected to my NForce3 based desktop running an identical Ubuntu setup, does not cause this problem.

(3) The problematic device connected to another different brand laptop using the same USB chipset causes the problem.

(4) Under Windows XP, everything works happily.

(5) rmmodding ehci-hcd (disabling USB 2.0) prevents the device from unmounting or disconnecting, but transfers still stall and fill dmesg with abundant errors fairly quickly.

(6) Using ehci-hcd, if you dd from the block device, everything works fine with a bs=xxx where xxx < 900. Go above 900, and the device disconnects.

Changed in linux-source-2.6.17:
status: Unconfirmed → Confirmed
Revision history for this message
John Dong (jdong) wrote :

http://paste.ubuntu-nl.org/24737

A pastebin of what I see... The connection was stable until I tried to copy a 5MB file into the MP3 player.

Revision history for this message
John Dong (jdong) wrote :

UPDATE:

Setting max_sectors in /sys/block/sdb/device to 32 (default 240), in an attempt to throttle speed, fixes this issue... So it must be that the problem is triggered by writing to the USB device too fast?

Maybe the kernel should have some sort of throttling mechanism.

Revision history for this message
John Dong (jdong) wrote :

I did some more testing on this last night, and it seems like max_sectors is OK up to 128, but going any higher causes the device to disconnect. after some more investigation, it appears like 128 matches Windows XP's behavior, which explains why Windows doesn't bork on transfers.

The kernel appears to have workarounds for some devices already (Genesis USB-IDE adapters), but obviously there are other devices exhibiting this behavior. At a block size of 128, there does not appear to be a benchmarkable difference in transfer speed when testing with my USB2 external hard drive.

Can we have 128 be default?

Revision history for this message
John Dong (jdong) wrote :

Ben, here's the lsusb output for my device. It's the Domain Technologies one.

As far as the original bug reporter, I'm guessing he'll need to provide his lsusb, too.

Revision history for this message
Gustavo Carneiro (gjc) wrote :

Your trick of setting max_sectors to 128 didn't work for me; same problem as before..

Revision history for this message
Gustavo Carneiro (gjc) wrote :

dmesg output again:

[42466.244022] EXT3 FS on sda2, internal journal
[42466.244085] EXT3-fs: mounted filesystem with ordered data mode.
[42861.724469] usb 3-3: reset high speed USB device using ehci_hcd and address 2
[42867.492402] usb 3-3: device not accepting address 2, error -110
[42867.552344] usb 3-3: reset high speed USB device using ehci_hcd and address 2
[42873.322360] usb 3-3: device not accepting address 2, error -110
[42873.378304] usb 3-3: reset high speed USB device using ehci_hcd and address 2
[42878.584920] usb 3-3: device not accepting address 2, error -110
[42878.640867] usb 3-3: reset high speed USB device using ehci_hcd and address 2
[42883.847414] usb 3-3: device not accepting address 2, error -110
[42883.847437] usb 3-3: USB disconnect, address 2
[42883.847574] sd 0:0:0:0: scsi: Device offlined - not ready after error recovery
[42883.849631] sd 0:0:0:0: SCSI error: return code = 0x10000
[42883.849635] end_request: I/O error, dev sda, sector 15200048
[42883.849654] sd 0:0:0:0: rejecting I/O to device being removed

Revision history for this message
Gustavo Carneiro (gjc) wrote :

Alas.. max_sectors = 64 didn't work either. I give up.

Changed in linux-source-2.6.17:
status: Confirmed → Fix Committed
Revision history for this message
John Dong (jdong) wrote :

Unfortunately, GO_SLOW does not fix it. It needs max_sectors to be set to 128. This should either be done in the kernel or userspace. I understand that one class of USB mass storage controllers (the genesis series?) get max_sectors=64 set automagically.

This device needs the same workaround (though it'll take 128, faster than 64). Whether it's more "correct" to do it from udev or the kernel, that's not for me to decide.

P.S. I started trying to write a udev rule for this, but am failing miserably. Can anyone point me to the right direction for setting max_sectors from udev?

Changed in linux-source-2.6.17:
status: Fix Committed → Confirmed
Revision history for this message
John Dong (jdong) wrote :

The following udev rule fixes the bug for me. It's currently the best way I've found to set max_sectors from udev (for some reason SYSFS{max_sectors}="128" does nothing)

BUS=="scsi", SYSFS{vendor}=="RockChip", RUN+="/bin/sh -c '/bin/echo 128 > /sys/block/%k/device/max_sectors'"

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

What does this sysfs attribute do? limit the size of the disk?

Changed in udev:
assignee: nobody → keybuk
importance: Undecided → Wishlist
status: Unconfirmed → Needs Info
Revision history for this message
Gustavo Carneiro (gjc) wrote :

I should point out that max_sectors = 128 doesn't solve my problem at all, so it is certainly not the solution to _this_ bug; maybe it fixes the other bug which was marked as dup of this one, maybe they're not the same bug after all...

Revision history for this message
John Dong (jdong) wrote :

http://www.linux-usb.org/FAQ.html#i5

"For USB Mass Storage devices (that is, devices which use the usb-storage driver) max_sectors controls the maximum amount of data that will be transferred to or from the device in a single command."

Revision history for this message
Gustavo Carneiro (gjc) wrote :

A few days back I did a test for the external USB disk, which failed in the middle of a backup as usual. Without rebooting, today I inserted a simple USB flash disk, and it doesn't work:

[172878.782917] usb 3-5: new high speed USB device using ehci_hcd and address 7
[172885.168523] usb 3-5: device not accepting address 7, error -110

To me this proves that the problem is not at all related to the external USB hard drive; it is a problem with the USB controller alone.

Revision history for this message
Gustavo Carneiro (gjc) wrote :

Problem remains in kernel 2.6.19-6.

Changed in linux-source-2.6.19:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Could people running feisty try this rule instead:

SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{vendor}=="RockChip", ATTR{max_sectors}="128"

(Note that the use of plural vs singular and == vs = is deliberate)

Revision history for this message
Ben Collins (ben-collins) wrote :

Please retest against 2.6.20-2 when it is available in the feisty archive.

Changed in linux-source-2.6.19:
status: Confirmed → Needs Info
Revision history for this message
Gustavo Carneiro (gjc) wrote :

Tested against 2.6.20-3; problem remains.
:-(

Revision history for this message
PetePete (peterrpeterr) wrote :

I've been experiancing these problems, added the rule..

BUS=="scsi", SYSFS{vendor}=="RockChip", RUN+="/bin/sh -c '/bin/echo 128 > /sys/block/%k/device/max_sectors'"

and it seems to be working fine (copied a 117mb file onto the disk, and read a 96mb file from the disk.

Revision history for this message
Gustavo Carneiro (gjc) wrote :

I already tried that in the past and it made no difference.

I think I must be stress-testing the USB disk a lot more than anyone else here. Try backing up your home directory to an USB disk using rdiff-backup! :)

Revision history for this message
John Dong (jdong) wrote : Re: [Bug 61235] Re: USB mass storage stops working after a while

No, I don't think it's just stress; I regularly run an entire Ubuntu OS
off my external 160GB for days and days of usage, including backports
work, video encoding/copying/transcoding, backing up, you name it....
On Fri, 2007-01-05 at 22:24 +0000, Gustavo Carneiro wrote:
> I already tried that in the past and it made no difference.
>
> I think I must be stress-testing the USB disk a lot more than anyone
> else here. Try backing up your home directory to an USB disk using
> rdiff-backup! :)
>

Revision history for this message
taavi (taavioramo) wrote :

I have this issue not only with a USB mass storage device but also with an Artec T14 DVB stick. I'm using the newest kernel from feisty repos. My issue is different from the description. My devices aren't recognized at all.

Changed in linux-source-2.6.19:
status: Unconfirmed → Rejected
Changed in linux-source-2.6.20:
assignee: nobody → ubuntu-kernel-team
status: Needs Info → Confirmed
Changed in udev:
assignee: keybuk → nobody
Revision history for this message
krull_der_zerstoerer (ubuntu-boczki) wrote :
Download full text (3.3 KiB)

Having the same problem:

dmesg output:

[ 69.464000] EXT3 FS on sdc5, internal journal
[ 69.468000] EXT3-fs: mounted filesystem with ordered data mode.
[ 172.012000] sdc: Current: sense key: No Sense
[ 172.012000] Additional sense: No additional sense information
[ 202.124000] usb 4-1: reset high speed USB device using ehci_hcd and address 2
[ 232.396000] usb 4-1: reset high speed USB device using ehci_hcd and address 2
[ 262.668000] usb 4-1: reset high speed USB device using ehci_hcd and address 2
[ 283.244000] usb 4-1: USB disconnect, address 2
[ 283.244000] sd 2:0:0:0: SCSI error: return code = 0x00010000
[ 283.244000] end_request: I/O error, dev sdc, sector 315884110
[ 283.244000] Buffer I/O error on device sdc5, logical block 38207590
[ 283.244000] lost page write due to I/O error on sdc5
[ 283.244000] sd 2:0:0:0: SCSI error: return code = 0x00010000
[ 283.244000] end_request: I/O error, dev sdc, sector 12662
[ 283.244000] journal_bmap: journal block not found at offset 12 on sdc5
[ 283.244000] Aborting journal on device sdc5.
[ 283.244000] Buffer I/O error on device sdc5, logical block 1555
[ 283.244000] lost page write due to I/O error on sdc5
[ 283.252000] Buffer I/O error on device sdc5, logical block 37847042
[ 283.252000] lost page write due to I/O error on sdc5
[ 283.252000] Buffer I/O error on device sdc5, logical block 38207563
[ 283.252000] lost page write due to I/O error on sdc5
[ 283.252000] Buffer I/O error on device sdc5, logical block 38862888
[ 283.252000] lost page write due to I/O error on sdc5
[ 283.252000] Buffer I/O error on device sdc5, logical block 1037
[ 283.252000] lost page write due to I/O error on sdc5
[ 283.264000] EXT3-fs error (device sdc5): ext3_get_inode_loc: unable to read inode block - inode=19744535, block=39485498
[ 283.264000] scsi 2:0:0:0: rejecting I/O to dead device
[ 283.264000] scsi 2:0:0:0: rejecting I/O to dead device
[ 283.264000] ext3_abort called.
[ 283.264000] EXT3-fs error (device sdc5): ext3_journal_start_sb: Detected aborted journal
[ 283.264000] Remounting filesystem read-only
[ 283.540000] scsi 2:0:0:0: rejecting I/O to dead device
[ 589.332000] usb 4-1: new high speed USB device using ehci_hcd and address 8
[ 589.672000] usb 4-1: configuration #1 chosen from 1 choice
[ 589.672000] scsi4 : SCSI emulation for USB Mass Storage devices
[ 589.672000] usb-storage: device found at 8
[ 589.672000] usb-storage: waiting for device to settle before scanning
[ 594.672000] usb-storage: device scan complete
[ 594.672000] scsi 4:0:0:0: Direct-Access Maxtor 6 Y200P0 YAR4 PQ: 0 ANSI: 0
[ 594.672000] SCSI device sdc: 390721969 512-byte hdwr sectors (200050 MB)
[ 594.676000] sdc: Write Protect is off
[ 594.676000] sdc: Mode Sense: 03 00 00 00
[ 594.676000] sdc: assuming drive cache: write through
[ 594.676000] SCSI device sdc: 390721969 512-byte hdwr sectors (200050 MB)
[ 594.676000] sdc: Write Protect is off
[ 594.676000] sdc: Mode Sense: 03 00 00 00
[ 594.676000] sdc: assuming drive cache: write through
[ 594.676000] sdc:<6>usb 4-1: reset high speed USB device using ehci_hcd and address 8
[ 655.060000] usb 4-1: reset high speed...

Read more...

Revision history for this message
krull_der_zerstoerer (ubuntu-boczki) wrote :

if i remove device after it hangs something is printed on stdout

see attachment

Revision history for this message
Sven Thomsen (sven-tumelum) wrote :

Same here.

I'm running a vmware-player session from a Iomega USB Harddisk.

Upon connect:

[ 2475.208541] usb 4-4: new high speed USB device using ehci_hcd and address 37
[ 2475.434483] usb 4-4: configuration #1 chosen from 1 choice
[ 2475.434732] scsi6 : SCSI emulation for USB Mass Storage devices
[ 2475.434861] usb-storage: device found at 37
[ 2475.434863] usb-storage: waiting for device to settle before scanning
[ 2480.434812] usb-storage: device scan complete
[ 2480.470174] scsi 6:0:0:0: Direct-Access ST350084 1A 3.AA PQ: 0 ANSI: 0
[ 2480.472020] SCSI device sdf: 976773168 512-byte hdwr sectors (500108 MB)
[ 2480.472896] sdf: Write Protect is off
[ 2480.472900] sdf: Mode Sense: 03 00 00 00
[ 2480.472903] sdf: assuming drive cache: write through
[ 2480.473891] SCSI device sdf: 976773168 512-byte hdwr sectors (500108 MB)
[ 2480.474768] sdf: Write Protect is off
[ 2480.474772] sdf: Mode Sense: 03 00 00 00
[ 2480.474774] sdf: assuming drive cache: write through
[ 2480.474780] sdf: sdf1
[ 2480.494850] sd 6:0:0:0: Attached scsi disk sdf
[ 2480.494901] sd 6:0:0:0: Attached scsi generic sg4 type 0

After copying a big file (max 10secs after start of copy-job):

[ 2595.675860] scsi 6:0:0:0: rejecting I/O to dead device

Setting max_sectors to 128 doesn't work for me either.

$ uname -r
2.6.20-15-generic

Revision history for this message
Jansen Sena (jansen) wrote :

Hi friends,

I was having the same problem. My external hard drive stopped work after try to copy a lot of file to it. I got this message in "dmesg":

"rejecting I/O to dead device"

I am able to copy a couple of large files (like DVD images) without problems. The problem just happens when I try to copy a lot of files (small or large ones).

I am using a Compaq Presario V2000 laptop with Ubuntu Feisty Fawn (7.04) and one Iomega External HD (320GB). In the first time, I removed the ehci_hcd using the followed command as commented before:

# modprobe -r ehci_hcd

This kernel module is the responsible for the USB 2.0 support. After ran this command, I was able to copy a lot of files to my external hard drive and it was not suddenly dead anymore. But, as I removed the USB 2.0 support the transfer was running in a very low rate and it was not a definitive solution because I wanted to copy more than 120GB in one time.

Then, I loaded the ehci_module again and tried to change the value included in the max_sectors from 240 (default) to 128, 64 and 32. In my desktop (a IBM Think Centre with Ubuntu Fesity Fawn) this solution worked perfectly! But, in my laptop the problem stays happening. Then, I tried to change the file system from VFAT to EXT3, but the problem was not solved.

Finally, on last sunday night, I recompiled my kernel following these steps:

1) I installed the 2.6.20 kernel souce code using apt-get:

         # apt-get install linux-source-2.6.20

2) I loaded the more recent kernel configuration copying the /boot/config-2.6.20-15-generic file to kernel source directory naming the file as ".config" and process this file to select the options marked in my running kernel:

         # cp /boot/config-2.6.20-15-generic /usr/src/linux-source-2.6.20/.config
         # cd /usr/src/linux-source-2.6.20/.config
         # make oldconfig

3) I ran the menuconfig and I enabled and disabled some options as showed after:

        # cd /usr/src/linux-source-2.6.20/.config
        # make menuconfig

       3.1) Disabled features (Device Drivers --> USB Support):

               * FULL speed ISO transactions (USB_EHCI_SPLIT_ISO)
               * Root Hub Transaction Translators (USB_EHCI_ROOT_HUB_IT)
               * Improved Transaction Translator schedulling (USB_EHCI_TT_NEWSCHED)

       3.2) Enabled features (Device Drivers --> USB Support):

               * USB verbose debug messages (USB_DEBUG)
               * Enforce USB bandwith allocation (USB_BANDWITH)

After recompile the kernel and rebot my system, I connected my external Iomega external drive and everything is working fine and I was finally able to go to bed rest for some hours! :-)

I don't know with this solution will work for others people... But here is the solution I found to me. I will be happy to know with these steps help you to solve the problem as well!

Best regards,

Jansen Sena
<email address hidden>

Revision history for this message
Gustavo Carneiro (gjc) wrote :

> Then, I loaded the ehci_module again and tried to change the value included in the max_sectors from 240 (default) to 128, 64 and 32. In my desktop (a IBM Think Centre with Ubuntu Fesity Fawn) this solution worked perfectly! But, in my laptop the problem stays happening. Then, I tried to change the file system from VFAT to EXT3, but the problem was not solved.

This might explain why everyone else claims that changing max_sectors solves the problem, except for me. I also use EXT3 as file system in my external HDD.

Revision history for this message
pnd (philippdorner) wrote :

I have experienced the same problem with a TEAC external HDD usb 2.0. It took me quite a while finding this thread as the problem is rather difficult to describe in abstract terms.

The teac usb controller is only supported from 2.6.20, I'm running 2.6.20-16-generic

00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)

upon transfer of a large number of files / large quantity of data the following occurs:

dmesg

[ 3453.603279] sd 97:0:0:0: rejecting I/O to offline device
[ 3453.603344] sd 97:0:0:0: SCSI error: return code = 0x00010000
[ 3453.603349] end_request: I/O error, dev sda, sector 268784559
[ 3453.759089] Aborting journal on device sda1.
[ 3453.768324] journal commit I/O error
[ 3453.768586] ext3_abort called.
[ 3453.768590] EXT3-fs error (device sda1): ext3_journal_start_sb: Detected aborted journal
[ 3453.768595] Remounting filesystem read-only
[ 3454.006594] usb 4-3: new high speed USB device using ehci_hcd and address 100
[ 3454.139545] usb 4-3: configuration #1 chosen from 1 choice
[ 3454.139791] scsi98 : SCSI emulation for USB Mass Storage devices
[ 3454.140033] usb-storage: device found at 100
[ 3454.140037] usb-storage: waiting for device to settle before scanning
[ 3459.131249] usb-storage: device scan complete
[ 3464.734779] usb 4-3: reset high speed USB device using ehci_hcd and address 100
[ 3466.967411] __journal_remove_journal_head: freeing b_committed_data
[ 3466.968067] scsi 97:0:0:0: rejecting I/O to dead device
[ 3466.968087] printk: 15477 messages suppressed.
[ 3466.968093] Buffer I/O error on device sda1, logical block 1545
[ 3466.968096] lost page write due to I/O error on sda1
[ 3474.963719] usb 4-3: reset high speed USB device using ehci_hcd and address 100
[ 3478.894188] usb 4-3: USB disconnect, address 100
[ 3478.894207] scsi 98:0:0:0: scsi: Device offlined - not ready after error recovery

after this, the device led keeps blinking, and there is an endless loop of the following, without /dev/sda appearing-

[ 3666.270093] usb 4-3: reset high speed USB device using ehci_hcd and address 108
[ 3676.499028] usb 4-3: reset high speed USB device using ehci_hcd and address 108
[ 3680.429515] usb 4-3: USB disconnect, address 108
[ 3680.429533] scsi 106:0:0:0: scsi: Device offlined - not ready after error recovery
[ 3680.704840] usb 4-3: new high speed USB device using ehci_hcd and address 109
[ 3680.837796] usb 4-3: configuration #1 chosen from 1 choice
[ 3680.838103] scsi107 : SCSI emulation for USB Mass Storage devices
[ 3680.838346] usb-storage: device found at 109
[ 3680.838350] usb-storage: waiting for device to settle before scanning
[ 3685.829503] usb-storage: device scan complete

changing MAX_SECTORS in /sys/block/sdb/device to 128 did NOT help

Revision history for this message
Jansen Sena (jansen) wrote :

Hi pnd,

did you see my post showed two before yours?

Maybe, the steps I described there can help you to solve the problem.

Best regards,

Jansen

Revision history for this message
pnd (philippdorner) wrote :

Boa tarde Jansen!

Thanks very much for your quick response.

modprobe -r ehci_hcd

I have tried this, and although it makes transfers unbearably slow, it seems to stop the usbdisk from hanging up.

recompiling kernel looks a bit scary..

are there any ideas for a solution through userspace settings?

BH, MG
pnd

Revision history for this message
Jansen Sena (jansen) wrote :

Hi "pnd",

Ok... you don't need to recompile your kernel.. I did this job for you! :-D I recompiled the kernel just adjusting the features to make my external HDD works fine. The other features are default in Ubuntu. Because of that, just send an email to me and I can send to you my ".deb" kernel package and all you will want to do is install this package using "dpkg" or even a graphical interface like Synaptic. If you want to do this, just email me in <email address hidden>.

Best regards,

Jansen

Revision history for this message
pnd (philippdorner) wrote :

email sent- thanks very much!!

Revision history for this message
Jansen Sena (jansen) wrote :

Hi friends,

there is a little mistake in my post about how I solved the problem. The followed command:

# cd /usr/src/linux-source-2.6.20/.config

is wrong because ".config" is a file. The right thing to do is:

# cd /usr/src/linux-source-2.6.20

It was a kind of "copy-and-paste" problem! ;-)

Best regards,

Jansen

Revision history for this message
fernando (email-launchpad) wrote :

Bad news: Jansen's solution seems to delay the problem, but not fix it for me.

I got a new 500GB drive which dies when I try this:

# mke2fs -c /dev/sda1

The block at which it dies depends on whether I run a kernel with Jansen's suggestion or not.
With USB_EHCI_SPLIT_ISO, USB_EHCI_ROOT_HUB_IT or USB_EHCI_TT_NEWSCHED enabled and USB_BANDWITH disabled, it dies pretty soon.
On the other hand, when USB_EHCI_SPLIT_ISO, USB_EHCI_ROOT_HUB_IT and USB_EHCI_TT_NEWSCHED are disabled and USB_BANDWITH is enabled, it takes
as much as 10 times longer for the USB connection to die, but it dies at the end all the same.

It is definitely a bug in the handling of USB controllers. I gathered some evidence that this is the case using a different machine and a 300 GB disk. I have two different generic
USB enclosures. The same disk mounted on one of them works perfectly, while mounted on the other it exhibits the connection problems and eventually dies.

Finally, a caveat: Creating a partition in the 500GB disk without badblock checking worked fine. I could also copy some large movie files into the disk, but when it eventually died,
it killed the partition. The data in the disk was totally destroyed and I could not recover it. Maybe this is a particularly bad controller (reported as "Samsung" by sysfs) but the
severing of the USB bus connection should never have the effect of totally destroying all the data stored in a device. Too bad.

Revision history for this message
Beefeater (beefeater) wrote :
Download full text (5.0 KiB)

Ubuntu Edgy kernel 2.6.17-11-generic

I'm pretty much having the same problem. At first I thought modprobe -r ehci_hcd solved the issue (of course with lower speed).
But after plugging my Seagate FreeAgent 320GB in and trying to transfer a dvd-image I get the following error.
Does anyone have an idea on when this issue will be solved?

dmesg output:

[17179878.068000] usb 3-1: new full speed USB device using uhci_hcd and address 2
[17179878.236000] usb 3-1: configuration #1 chosen from 1 choice
[17179878.344000] usbcore: registered new driver libusual
[17179878.360000] Initializing USB Mass Storage driver...
[17179878.360000] scsi2 : SCSI emulation for USB Mass Storage devices
[17179878.360000] usbcore: registered new driver usb-storage
[17179878.360000] USB Mass Storage support registered.
[17179878.360000] usb-storage: device found at 2
[17179878.360000] usb-storage: waiting for device to settle before scanning
[17179883.360000] usb-storage: device scan complete
[17179883.364000] Vendor: Seagate Model: FreeAgentDesktop Rev: 100D
[17179883.364000] Type: Direct-Access ANSI SCSI revision: 04
[17179883.380000] sdb: Spinning up disk....ready
[17179890.596000] SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
[17179890.600000] sdb: Write Protect is off
[17179890.600000] sdb: Mode Sense: 1c 00 00 00
[17179890.600000] sdb: assuming drive cache: write through
[17179890.604000] SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
[17179890.608000] sdb: Write Protect is off
[17179890.608000] sdb: Mode Sense: 1c 00 00 00
[17179890.608000] sdb: assuming drive cache: write through
[17179890.608000] sdb: sdb1
[17179890.636000] sd 2:0:0:0: Attached scsi disk sdb
[17179890.636000] sd 2:0:0:0: Attached scsi generic sg2 type 0
[17179914.760000] kjournald starting. Commit interval 5 seconds
[17179914.768000] EXT3 FS on sdb1, internal journal
[17179914.768000] EXT3-fs: mounted filesystem with ordered data mode.
[17182358.672000] sd 2:0:0:0: Device not ready: <6>: Current: sense key: Not Ready
[17182358.672000] Additional sense: Logical unit not ready, initializing cmd. required
[17182358.672000] end_request: I/O error, dev sdb, sector 12479
[17182358.672000] EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0
[17182358.672000] Aborting journal on device sdb1.
[17182358.688000] sd 2:0:0:0: Device not ready: <6>: Current: sense key: Not Ready
[17182358.688000] Additional sense: Logical unit not ready, initializing cmd. required
[17182358.688000] end_request: I/O error, dev sdb, sector 12527
[17182358.688000] Buffer I/O error on device sdb1, logical block 1558
[17182358.688000] lost page write due to I/O error on sdb1
[17182358.696000] sd 2:0:0:0: Device not ready: <6>: Current: sense key: Not Ready
[17182358.696000] Additional sense: Logical unit not ready, initializing cmd. required
[17182358.696000] end_request: I/O error, dev sdb, sector 63
[17182358.696000] Buffer I/O error on device sdb1, logical block 0
[17182358.696000] lost page write due to I/O error on sdb1
[17182556.500000] SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
[17182556.504000] sdb: Write Prot...

Read more...

Revision history for this message
Knitebane (knitebane) wrote :
Download full text (3.3 KiB)

Chiming in on this...

Feisty on kernel 2.6.20-16-generic #2

System is a Dell Inspiron 600m

lspci -v says the USB interface is thus:

USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller

Device is a low-profile laptop HD USB adapter.

lsusb -v says:

Bus 002 Device 005: ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x04b4 Cypress Semiconductor Corp.
  idProduct 0x6830 USB-2.0 IDE Adapter
  bcdDevice 0.01
  iManufacturer 56 Cypress Semiconductor
  iProduct 78 USB2.0 Storage Device
  iSerial 100 DEF106F1A17F
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xc0
      Self Powered
    MaxPower 0mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 8 Mass Storage
      bInterfaceSubClass 6 SCSI
      bInterfaceProtocol 80 Bulk (Zip)
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x88 EP 8 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
Device Qualifier (for other device speed):
  bLength 10
  bDescriptorType 6
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  bNumConfigurations 1
Device Status: 0x0001
  Self Powered

Plugging it in gives me:

[ 124.064000] usb 4-1.1: new high speed USB device using ehci_hcd and address 4
[ 124.156000] usb 4-1.1: configuration #1 chosen from 1 choice
[ 124.336000] usbcore: registered new interface driver libusual
[ 124.348000] Initializing USB Mass Storage driver...
[ 124.348000] scsi2 : SCSI emulation for USB Mass Storage devices
[ 124.348000] usbcore: registered new interface driver usb-storage
[ 124.348000] USB Mass Storage support registered.
[ 124.348000] usb-storage: device found at 4
[ 124.348000] usb-storage: waiting for device to settle before scanning
[ 129.348000] usb-storage: device scan complete
[ 134.920000] usb 4-1.1: reset high speed USB device using ehci_hcd and address 4
[ 145.084000] usb 4-1.1: reset high speed USB device using ehci_hcd and address 4
[ 150.248000] usb 4-1.1: reset high speed USB device using ehci_hcd and address 4
[ 160.412000] usb 4-1.1: reset high speed USB device ...

Read more...

Revision history for this message
Andrew Pines (apines) wrote :

I believe we have found a real solution to this problem. Please try it out and post your results so we can verify how well it works. We found two issues which seem to contribute to this problem:

1) The EHCI controller has a setting for number of retries (1, 2, 3, or endless). The kernel sets it to 3. Try setting it to 0 (endless retries). This setting is in drivers/usb/host/ehci-hcd.c, line 107:
     #define EHCI_TUNE_CERR 3 /* 0-3 qtd retries; 0 == don't stop */
Simply change the 3 to a 0. This will cause it to retry failed transactions endlessly until they succeed. I don't know if this will have an adverse effect on non-mass storage devices (the only USB devices we have in our system are flash drives).

2) The BIOS may not be setting the Frame Length Adjustment register. This one is a little more obscure. See page 10 of the EHCI specification, available on Intel's web site. Our motherboard (ECS P4M800PRO-M478) is not setting a value for this register. ECS seemed to not know what we were talking about when we asked about it. The kernel should not have to set this but it can, by inserting the following code into the top of ehci_pci_setup() in drivers/usb/host/ehci-pci.c (about line 74):

    {
        u8
            fladj;

        pci_read_config_byte(pdev,0x61,&fladj);
        printk("FLADJ was=%02X\n",fladj);
        pci_write_config_byte(pdev,0x61,0x00);
        pci_read_config_byte(pdev,0x61,&fladj);
        printk("FLADJ is now=%02X\n",fladj);
    }

The FLADJ register's address is 0x61. This will set the value to 0x00 (worked well for us, may be totally wrong for you). Since this is a function of the specific motherboard you'll probably have to find the right number empirically. You can verify if your motherboard is writing its own value by booting once to set your value then rebooting (without powering off) and noting if the "was=" in the logs is what you previously set or if it's something different. If it's different then the BIOS wrote to it and probably knows the correct value and you should leave this alone. The valid range is 0x00 through 0x3F. The default is 0x20.

Build the kernel in your usual fashion, give it a spin, and let me know how it goes. I hope this helps.

     -Andrew

Revision history for this message
Beefeater (beefeater) wrote :

Andrew,

I changed to 0 in drivers/usb/host/ehci-hcd.c and built my kernel, 2.6.20.3.

Haven't had time to do a lot of testing yet. However it was working the few hours I tested it. I moved a lot of data back and forth and also let it rest for +30 min before going again.
The sessions dmesg-output

[ 173.352000] usb 5-5: new high speed USB device using ehci_hcd and address 2
[ 173.500000] usb 5-5: configuration #1 chosen from 1 choice
[ 173.616000] usbcore: registered new interface driver libusual
[ 173.684000] Initializing USB Mass Storage driver...
[ 173.684000] scsi2 : SCSI emulation for USB Mass Storage devices
[ 173.684000] usb-storage: device found at 2
[ 173.684000] usb-storage: waiting for device to settle before scanning
[ 173.684000] usbcore: registered new interface driver usb-storage
[ 173.684000] USB Mass Storage support registered.
[ 178.684000] usb-storage: device scan complete
[ 178.684000] scsi 2:0:0:0: Direct-Access Seagate FreeAgentDesktop 100D PQ: 0 ANSI: 4
[ 178.692000] sdb: Spinning up disk....ready
[ 185.960000] SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
[ 185.960000] sdb: Write Protect is off
[ 185.960000] sdb: Mode Sense: 1c 00 00 00
[ 185.960000] sdb: assuming drive cache: write through
[ 185.964000] SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
[ 185.964000] sdb: Write Protect is off
[ 185.964000] sdb: Mode Sense: 1c 00 00 00
[ 185.964000] sdb: assuming drive cache: write through
[ 185.964000] sdb: sdb1
[ 185.988000] sd 2:0:0:0: Attached scsi disk sdb
[ 185.988000] sd 2:0:0:0: Attached scsi generic sg2 type 0
[ 220.784000] kjournald starting. Commit interval 5 seconds
[ 220.784000] EXT3 FS on sdb1, internal journal
[ 220.784000] EXT3-fs: mounted filesystem with ordered data mode.
[ 1893.564000] usb 5-5: reset high speed USB device using ehci_hcd and address 2
[ 1893.816000] usb 5-5: reset high speed USB device using ehci_hcd and address 2
[ 1894.068000] usb 5-5: reset high speed USB device using ehci_hcd and address 2
[ 3947.860000] usb 5-5: reset high speed USB device using ehci_hcd and address 2
[ 3948.112000] usb 5-5: reset high speed USB device using ehci_hcd and address 2
[ 3948.364000] usb 5-5: reset high speed USB device using ehci_hcd and address 2

Changed in linux-source-2.6.17:
status: Confirmed → Fix Released
Changed in udev:
status: Incomplete → Invalid
44 comments hidden view all 124 comments
Revision history for this message
sebastian-s (sebastian-s) wrote :

hi all,
I added a truecrypt ext3 partition to my recently-purchased Seagate FreeAgent Go 160GB external disk. The driver was ntfs pre-formatted and auto mount worked with no probs. unmounting was not really possible as the drive was remounted a few seconds after unmounting (klick, no console).

So I searched arround and found this bug. To help out I followed this (https://wiki.ubuntu.com/DebuggingRemovableDevices) guide to give some logs who might help.

my system is 7.04, running 2.6.20-16 kernel and 99.9% updated

id
uid=1000(seb) gid=1000(seb) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(scanner),112(netdev),113(lpadmin),115(powerdev),117(admin),1000(seb)
:~$ id hal
id: hal: No such user
:~$ id haldaemon
uid=107(haldaemon) gid=114(haldaemon) groups=114(haldaemon),24(cdrom),25(floppy),46(plugdev),115(powerdev)

Revision history for this message
sebastian-s (sebastian-s) wrote :
Revision history for this message
sebastian-s (sebastian-s) wrote :
Revision history for this message
sebastian-s (sebastian-s) wrote :

can one explain me how to use the script KEYofR ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/61235/comments/71 ) did.

where do I have to place the UDEV thing...
I figured out to place the script file in /usr/sbin

I am keen on learning but this is to much at a time for me... so thanks for helping

Revision history for this message
Gustavo Carneiro (gjc) wrote :

I am still being affected by this bug, in this kernel version (gutsy amd64):

2.6.22-14-generic #1 SMP Sun Oct 14 21:45:15 GMT 2007 x86_64 GNU/Linux

Revision history for this message
vencabot (vencabot-teppoo) wrote :

After fixing the problem with some of the advice here, I started having the problem again after I upgraded to Gutsy. I solved the problem the same way that I did last time: modprobe -r ehci_hcd , restart.

-David

Revision history for this message
Gerd (gerd-headlamps) wrote :

modprobe -r ehci_hcd doesn't work for me :-(

Revision history for this message
alonso (honkkis) wrote :

I would like to add that I had similar problem with USB HD through kernels 2.6.18-2.6.22 using the combination of Lacie USB 500 GB HD and VIA VT6212L USB chip in an old PIII 500 Mhz machine using debian 4.0 (also tried ubuntu live CDs for gutsy and hardy to no avail)

USB 2.0 Device: Lacie black desktop USB 500 GB hard disk

Jan 20 15:27:43 localhost kernel: Vendor: ST350083 Model: 0AS R

us 001 Device 002: ID 059f:1010 LaCie, Ltd
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 64
  idVendor 0x059f LaCie, Ltd
  idProduct 0x1010
  bcdDevice c6.83
  iManufacturer 2 LaCie
  iProduct 3
  iSerial 1 ST3500830A 9QG616JN
  bNumConfigurations 1

USB Host is prodige USB 2.0 pci-card with VIA VT6212L chip:

00:10.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65) (prog-if 20 [EHCI])
        Subsystem: VIA Technologies, Inc. USB 2.0
        Flags: bus master, medium devsel, latency 66, IRQ 11
        Memory at 42000000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2

Very old Compaq deskpro PIII 500 Mhz computer

I tried everything suggested in

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/61235

What helped me was the combination of 1 and 2:

1. following patch to /drivers/usb/storage/unusual_devs.h
(found this solution in
http://bugzilla.kernel.org/show_bug.cgi?id=6817
)

UNUSUAL_DEV( 0x059f, 0x1010, 0x0000, 0x0000,
        "Lacie",
        "USB to IDE Disk",
        US_SC_DEVICE, US_PR_DEVICE, NULL,
        US_FL_GO_SLOW | US_FL_MAX_SECTORS_64 ),

2. in ehci-hcd.c:

#define EHCI_TUNE_CERR 0 /* 0-3 qtd retries; 0 == don't stop */

I still see occasional high speed usb device resets, but so far no disconnects. There is definitely something strange going on with this setup, but I'm happy to have solved it. Also the transfer rate is pretty ok, for such an old machine:

hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 88 MB in 3.03 seconds = 29.01 MB/sec

Revision history for this message
Guillaume AVRIL (guillaumeavril) wrote :

sudo modprobe -r ehci_hcd also worked for me, I am using ubuntu 7.10 with a Asus M2V motherboard.

My dmesg gives:
[ 5638.148000] usb 5-1: new high speed USB device using ehci_hcd and address 2
[ 5643.148000] ehci_hcd 0000:00:10.4: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
[ 5653.692000] usb 5-1: device not accepting address 2, error -110
[ 5653.804000] usb 5-1: new high speed USB device using ehci_hcd and address 3
[ 5669.348000] usb 5-1: device not accepting address 3, error -110
[ 5669.460000] usb 5-1: new high speed USB device using ehci_hcd and address 4
[ 5679.884000] usb 5-1: device not accepting address 4, error -110
[ 5679.996000] usb 5-1: new high speed USB device using ehci_hcd and address 5
[ 5690.420000] usb 5-1: device not accepting address 5, error -110
[ 5711.732000] usb 5-1: new high speed USB device using ehci_hcd and address 6

I am using the usual 2.6.22-14-generic #1 SMP linux kernel provided with Ubuntu 7.10.

Good luck with this bug!

Revision history for this message
sebastian-s (sebastian-s) wrote :

I am running fine with
/etc/udev/rules.d/85-ext_hd.rules
     write SUBSYSTEMS==“scsi”,DRIVERS==“sd”,KERNEL==”[0-9]*”,ATTRS{model}==“FreeAgent Go ”,ATTRS{vendor}==“Seagate ”,RUN+=”/usr/local/bin/fixFreeAgent.sh %k”

and
  #!/bin/sh
  echo 1 > /sys/class/scsi_disk/$1/allow_restart

in /usr/local/bin/fixFreeAgent.sh

Revision history for this message
enigma_0Z (enigma-0za) wrote :

I'm also experiencing this on Gutsy (7.10) with the 2.6.22-14-generic kernel

My system is a Dell Vostro 1400, and the USB devices in question are connected via a Kensington hub.

The devices are an Apple iPod, and a USB IDE drive enclosure made by Initio (It's a generic store brand one).

After a while (approx. 2 hours) the devices will simply unmount themselves and go away. I never noticed this until I got the external hard disk, but I believe this is just because I'm watching for it now. Both devices unmount at the same time, and I can't seem to see anything useful in dmesg. I can mount them again w/o any problems or errors.

Revision history for this message
Alex (akruth) wrote :

Bug also occurs in hardy with the following syslog:
Apr 11 12:01:10 ak2 kernel: [ 975.711507] sd 3:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
Apr 11 12:01:10 ak2 kernel: [ 975.711525] end_request: I/O error, dev sdb, sector 4155884

Revision history for this message
Tom Nicoll (tnicoll) wrote :

Bug seems to have resurfaced for me after upgrading to Hardy. Listening to MP3s stored on an Iomega 500 GB external usb HD and the drive unmounts after maybe 10, 15 minutes. Can sometimes reconnected by powering off the HD and switching it back on but not always.

Revision history for this message
skrpc (skrpc) wrote :

I too have had a problem which sounds similar whereby my USB device would spin down and wait 10 or so seconds before spinning back on every segment of a large file copy and after more research came across a thread for bug #88746 (https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746) which after reading this thread may apply to some of the scenarios descibed above.

This thread has two fixes both of which worked for me as follows

1. This one can be done without the need to rebuild a kernel (I would try this first and if it works for you either build a udev rule so that it is always included at boot or look at the second option).

    modprobe -r ehci_hcd
    echo -n -1 > /sys/module/usbcore/parameters/autosuspend
    modprobe ehci_hcd

2. The second one requires applying a patch and rebuilding the kernel, I also recreated my initrd file as the ehci_hcd driver is also preloaded in these on my system

    http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.24/usb-ehci-add-a-short-delay-to-the-bus_suspend-routine.patch

Revision history for this message
Jacob Jarick (mem-namefix) wrote :

Well after alot of searching via google I came across this thread, not much in the way of answers but enough research done to dismiss the "faulty caddy/usb controller/ hardware" excuse. Seems its just an issue with ubuntu's current kernel. 2.6.25 does not have the issue. I have created the needed deb's for people who do not like compiling their own kernel (hosted via rapidshare due to size). A side note for people who do upgrade to the latest kernel beware that the nvidia drivers currently do not work without patching them, check the link below on howto patch the driver yourself or just download the 1 I have uploaded to rapidshare.

I will post the links to the files once the upload has finished (hopefully tonight but I do only have 25kb upstream).

To install the new kernel simply do the following commands:
tar xjvf linux-headers-2.6.25-custom.tar.bz2
dpkg -i linux*2.6.25-custom*.deb

To compile the kernel yourself download the latest from http://www.kernel.org and then follow this very nice ubuntu howto:
https://help.ubuntu.com/6.10/ubuntu/installation-guide/i386/kernel-baking.html

If you happen to have a nvidia card like I mentioned before and wish to manually patch the driver yourself read this forum thread:
http://www.nvnews.net/vbulletin/showthread.php?t=110088

Note: I misnamed the archive when creating it it was ment to be linux-2.6.25-custom.tar.bz2 not linux-headers-2.6.25-custom.tar.bz2, but I assure you it has the debs you want.

Quick plug for my own program (cool batch file renamer):
http://namefix.blogspot.com

Any questions drop me a line - <email address hidden>

Revision history for this message
Jacob Jarick (mem-namefix) wrote :

Files finished uploading, have at it.

kernel:
http://rapidshare.de/files/39283576/linux-headers-2.6.25-custom.tar.bz2.html

root@cesspit:/usr/src# sha1 linux-headers-2.6.25-custom.tar.bz2
9c0e457675b326af59c615a6423682441bf366f4 linux-headers-2.6.25-custom.tar.bz2
root@cesspit:/usr/src# md5 linux-headers-2.6.25-custom.tar.bz2
bb22393ce57b31cd4ffb92d0208763ef linux-headers-2.6.25-custom.tar.bz2

nvidia legacy driver:
http://rapidshare.de/files/39283713/NVIDIA-Linux-x86-71.86.04-pkg1-custom.run.html

root@cesspit:/home/mem/downloads# sha1 NVIDIA-Linux-x86-71.86.04-pkg1-custom.run
0ac4efc7b3bc37b9944257620e80b6a5f22f6093 NVIDIA-Linux-x86-71.86.04-pkg1-custom.run
root@cesspit:/home/mem/downloads# md5 NVIDIA-Linux-x86-71.86.04-pkg1-custom.run
86e6fb93c254764f6978984eda3c9e11 NVIDIA-Linux-x86-71.86.04-pkg1-custom.run

note:
I run a asus tnt2 ultra - hence legacy driver, people needing a driver for a later model card will need to do the patch themselves.

Revision history for this message
Jacob Jarick (mem-namefix) wrote :

Transfer test worked excellent last night, I shifted 140gb from 1 welland caddy to the other welland caddy (Welland caddies are one of the ones containing the chipset pre 2.6.25 has issues with). So solution can be confirmed.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Thanks Jacob. You mentioned this is resolved for you in upstream 2.6.25. I'd like to also point people to test the personal package archive of one of our kernel devs who is helping pull the next Intrepid Ibex 8.10 kernel together which is currently rebased with upstream 2.6.25 - https://edge.launchpad.net/~timg-tpi/+archive .

I'm also reassigning this bug to be against the "linux" source package since beginning with the Hardy development cycle, kernel bugs should be reported against the linux package instead of linux-source-2.6.xx. Sorry for any confusion. Thanks.

Changed in linux-source-2.6.24:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Jacob Jarick (mem-namefix) wrote :
Download full text (5.8 KiB)

I have had both welland power saving drives fail with the errors since the 140gb copy. Interestingly the failures only seem to happen after the drives have been idle for a long time (~ 1 hour +). Seems doing a ls /mnt/usb3 will fail or return a weird listing. The devices will resume working (which never used to on earlier kernels) after doing this:
umount drive
Power cycle drive
mount drive.

here is my /var/log/messages from when I was getting the drive back online:
May 3 11:16:39 cesspit kernel: [155646.665581] usb 2-4: reset high speed USB device using ehci_hcd and address 10
May 3 11:16:42 cesspit kernel: [155650.930383] usb 2-4: reset high speed USB device using ehci_hcd and address 10
May 3 11:16:42 cesspit kernel: [155651.218163] usb 2-4: device firmware changed
May 3 11:16:42 cesspit kernel: [155651.218198] usb 2-4: USB disconnect, address 10
May 3 11:16:42 cesspit kernel: [155651.218594] sd 6:0:0:0: [sde] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
May 3 11:16:42 cesspit kernel: [155651.218803] sd 6:0:0:0: [sde] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
May 3 11:16:42 cesspit kernel: [155651.321842] usb 2-5: reset high speed USB device using ehci_hcd and address 11
May 3 11:16:43 cesspit kernel: [155651.474080] usb 2-5: device firmware changed
May 3 11:16:43 cesspit kernel: [155651.474080] sd 7:0:0:0: [sdf] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
May 3 11:16:43 cesspit kernel: [155651.474249] sd 7:0:0:0: [sdf] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
May 3 11:16:43 cesspit kernel: [155651.549534] sd 7:0:0:0: [sdf] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
May 3 11:16:43 cesspit kernel: [155651.582133] usb 2-4: new high speed USB device using ehci_hcd and address 16
May 3 11:16:43 cesspit kernel: [155651.613836] sd 7:0:0:0: [sdf] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
May 3 11:16:43 cesspit kernel: [155651.660971] sd 7:0:0:0: [sdf] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
May 3 11:16:43 cesspit kernel: [155652.130060] usb 2-4: new high speed USB device using ehci_hcd and address 17
May 3 11:16:44 cesspit kernel: [155652.699106] usb 2-4: configuration #1 chosen from 1 choice
May 3 11:16:44 cesspit kernel: [155652.751997] scsi10 : SCSI emulation for USB Mass Storage devices
May 3 11:16:44 cesspit kernel: [155652.811351] usb 2-5: USB disconnect, address 11
May 3 11:16:44 cesspit kernel: [155652.811351] lost page write due to I/O error on sdf1
May 3 11:16:44 cesspit kernel: [155652.969331] usb 2-5: new high speed USB device using ehci_hcd and address 18
May 3 11:16:44 cesspit kernel: [155653.105750] usb 2-5: configuration #1 chosen from 1 choice
May 3 11:16:44 cesspit kernel: [155653.117219] scsi11 : SCSI emulation for USB Mass Storage devices
May 3 11:16:49 cesspit kernel: [155658.678815] scsi 10:0:0:0: Direct-Access WDC WD30 00JB-00KFA0 PQ: 0 ANSI: 2 CCS
May 3 11:16:49 cesspit kernel: [155658.687351] sd 10:0:0:0: [sdc] 586070255 512-byte hardware sectors (300068 MB)
May 3 11:16:49 cesspit kernel: [155658.688338] sd 10:0:0:0: [sdc] Write Protect is off
May 3 11:16:49 cesspit k...

Read more...

Revision history for this message
Jacob Jarick (mem-namefix) wrote :
Download full text (3.7 KiB)

Failure again, while copying from a welland psc (power saving caddy) to a normal firewire caddy. 5gb into copy.

Here is the strange ls output:

root@cesspit:/mnt# ls -la usb2/
total 4
drwxrwxrwx 1 mem root 4096 2008-05-03 14:02 .
drwxr-xr-x 8 root root 88 2008-05-01 21:08 ..
drwxrwxrwx 1 mem root 0 2008-05-02 00:01 Media
?--------- ? ? ? ? ? usb2/Incomming
?--------- ? ? ? ? ? usb2/SuperCopier2beta1-9.exe
root@cesspit:/mnt# cat /etc/fstab | grep usb2
LABEL=sleepy2 /mnt/usb2 ntfs-3g defaults,uid=1000 0 0

var/log/messages output:

May 3 13:59:56 cesspit kernel: [167270.573707] XFS mounting filesystem sdb1
May 3 14:07:33 cesspit kernel: [167789.981969] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:19 cesspit kernel: [167973.291042] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:49 cesspit kernel: [168009.169512] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:10:59 cesspit kernel: [168021.281996] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:15 cesspit kernel: [168040.401488] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:16 cesspit kernel: [168040.778268] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:26 cesspit kernel: [168052.821977] usb 2-4: reset high speed USB device using ehci_hcd and address 17
May 3 14:11:26 cesspit kernel: [168053.058472] sd 10:0:0:0: Device offlined - not ready after error recovery
May 3 14:11:26 cesspit kernel: [168053.058508] sd 10:0:0:0: [sdc] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK
May 3 14:11:26 cesspit kernel: [168053.058638] sd 10:0:0:0: [sdc] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
May 3 14:11:39 cesspit kernel: [168068.578563] printk: 28 messages suppressed.

While watching the copy, I noticed the psc power down during a copy, the kde copy dialog stalled while the messages "usb 2-4: reset high speed USB device using ehci_hcd and address 17" were printing to var/log. The copy did resume once, picked back up normal speed but powered down again a 2nd time and failed to come back online.

trying to remount the device has been working over the past few days but not today, output (note I use labels for mounting):

root@cesspit:/mnt# umount usb2
root@cesspit:/mnt# mount usb2
Error opening '/dev/sdc1': No such device or address
Failed to mount '/dev/sdc1': No such device or address
You seem to have a SoftRAID/FakeRAID hardware and must use an activated,
different device under /dev/mapper/, (e.g. /dev/mapper/nvidia_eahaabcc1)
to mount NTFS. Please see the 'dmraid' documentation for help.

Power cycling fixed the device. I will note this drive is a bit old and noisy but has never presented any issues when in use on my fileserver (connected internally). The issues are also not present in windows xp on any machines. I would suspect ntfs to be contributing to the issue but the other identical psc has the same issue though it doesnt not need to be power cycled as often.

I did contact welland regarding the issue...

Read more...

Revision history for this message
Szabolcs Szakacsits (szaka) wrote :

> I would suspect ntfs to be contributing to the issue but the other identical
> psc has the same issue though it doesnt not need to be power cycled as often.

I can assure you the issue absolutely has nothing to do with NTFS.

Revision history for this message
Jacob Jarick (mem-namefix) wrote :

> I can assure you the issue absolutely has nothing to do with NTFS.

Yes as I said in my previous post, fault ntfs-3g is not at fault in this case.

I emailed the manufacturer of my drives and this was their response (unfortunately):

Fw: GreenStarME-740PS linux support
from Tiffany <email address hidden>
to <email address hidden>,
date Mon, May 12, 2008 at 4:43 PM
subject Fw: GreenStarME-740PS linux support
mailed-by welland.com.tw

Hello Sir

ME-740PS don't support Linux, please kindly know!!

Thanks,
Tiffany

From: Jacob Jarick [mailto:<email address hidden>]
Sent: Saturday, May 03, 2008 5:38 PM
To: sales; <email address hidden>
Subject: Fwd: GreenStarME-740PS linux support

The bug does persist with your power saving caddies and the linux kernel in 2.6.25, is their a linux version of your tool available to adjust the drive idle times ?.

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/61235/comments/104

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Everyone,

Unfortunately it seems this bug did not get resolved in time for the Hardy release. Developers are currently working on the upcoming Intrepid Ibex 8.10 release. Would anyone care to confirm this issue with the 2.6.26 based kernel provided with Intrepid. Information regarding the most recent Alpha release for Intrepid can be found at http://www.ubuntu.com/testing . Please let us know your results if you are able to test. Thanks.

Revision history for this message
Martin Emrich (emme) wrote :

I already built the disk of one of my external USB drive directly into my PC (connected via SATA now) and gave the enclosure to a friend. The other USB disk I have is still external, but I had never problems with it.

So could it be possible that the problem depends on the actual USB-to{PATA,SATA,flash} chipset used in the external storage device?
If so, I could test several external hard drives from different vendors at work with my laptop (i855GM chipset), and we could invite others to to the same, and build a "compatibility matrix" out of e.g. USB-ID,PC-chipset, USB controller, USB drive chipset, attached drive model and kernel version. Of course there must be a way to determine the USB drive chipset without opening the enclosure (and thus voiding warranty). If there is enough test data, also hardware defects (defective USB chipset, broken cables, etc.) could be ruled out.

Revision history for this message
willisoften (will-copeland) wrote :

I haven't noticed any problems since Hardy - but I've built a new system so it could be a chipset related issue I guess - no idea what chipset unfortunately ....

Martin Emrich <email address hidden> wrote: I already built the disk of one of my external USB drive directly into
my PC (connected via SATA now) and gave the enclosure to a friend. The
other USB disk I have is still external, but I had never problems with
it.

So could it be possible that the problem depends on the actual USB-to{PATA,SATA,flash} chipset used in the external storage device?
If so, I could test several external hard drives from different vendors at work with my laptop (i855GM chipset), and we could invite others to to the same, and build a "compatibility matrix" out of e.g. USB-ID,PC-chipset, USB controller, USB drive chipset, attached drive model and kernel version. Of course there must be a way to determine the USB drive chipset without opening the enclosure (and thus voiding warranty). If there is enough test data, also hardware defects (defective USB chipset, broken cables, etc.) could be ruled out.

--
USB mass storage stops working after a while
https://bugs.launchpad.net/bugs/61235
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
con (conloos) wrote :

I tested my external USB disk (Bus 001 Device 002: ID 05e3:0702 Genesys Logic, Inc. USB 2.0 IDE Adapter), which have still the same problem, with the new kernel 2.6.27.

I tested the problem with "badblock" and the bug is still present on 2.6.27.

Now i try with uhci_hcd and have a slow but working connection.

con

Revision history for this message
con (conloos) wrote :

Hello (again),

i tryed the way of Jansen Sena and compiled my own kernel.

_Disabled features (Device Drivers --> USB Support):_

  * FULL speed ISO transactions (USB_EHCI_SPLIT_ISO)
  * Root Hub Transaction Translators (USB_EHCI_ROOT_HUB_IT)
  * Improved Transaction Translator schedulling (USB_EHCI_TT_NEWSCHED)

And the Kernel/Device works like a charm :o)

Should i compile my kernel again, and select in chungs the upper in - to bordering the failure?

Con

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The 18 month support period for Feisty Fawn 7.04 has reached it's end of life - http://www.ubuntu.com/news/ubuntu-7.04-end-of-life . As a result, we are closing the linux-source-2.6.20 kernel task. However, I'm adding a "linux "task so that this will remain open against the actively developed kernel. Thanks.

Changed in linux-source-2.6.20:
status: Confirmed → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
linux-source-2.6.22 kernel task. It would be helpful if you could test the
new Jaunty Jackalope 9.04 release and confirm if this issue remains -
http://www.ubuntu.com/getubuntu/releasenotes/904overview. If the issue still exists with the Jaunty
release, please update this report by changing the Status of the "linux (Ubuntu)"
task from "Incomplete" to "New". Also please be sure to run the command below
which will automatically gather and attach updated debug information to this
report. Thanks in advance.

apport-collect -p linux-image-2.6.28-11-generic 61235

Changed in linux-source-2.6.22 (Ubuntu):
status: New → Won't Fix
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

After almost 7 weeks with no response to comment https://bugs.edge.launchpad.net/ubuntu/+bug/61235/comments/115 I'm closing this bug. Please feel free to reopen (by setting the status back to New) if this issue remains in the latest release. Thanks.

Changed in linux (Ubuntu):
status: Incomplete → Won't Fix
Revision history for this message
Nigel Pugh (nigel-pugh) wrote :

Using Seagate FreeAgent Go 500Gb drive, unable to perform sustained data transfer.

Can confirm this issue is still in Karmic:
Linux nigel-laptop 2.6.31-9-generic #29-Ubuntu SMP Sun Aug 30 17:39:23 UTC 2009 i686 GNU/Linux

As mentioned above, this:

echo 1024 > /sys/block/sdb/device/max_sectors

was required to get the drive working reliably.

Revision history for this message
Peter Schaefer (derschaefer) wrote :
Download full text (5.1 KiB)

Seeing this still on Karmic Beta:
Linux version 2.6.31-11-generic (buildd@yellow) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu4) ) #38-Ubuntu SMP Fri Oct 2 11:06:40 UTC 2009

It's a 1TB Toshiba USB drive and it also needs the afm. "max_sectors" trick. However, i'm under the expression that the drive worked flawless under Jaunty (since i managed to put a few hundred gigs onto it...).

~$ udevadm info --attribute-walk --name=/dev/sdg

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host8/target8:0:0/8:0:0:0/block/sdg':
    KERNEL=="sdg"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{range}=="16"
    ATTR{ext_range}=="256"
    ATTR{removable}=="0"
    ATTR{ro}=="0"
    ATTR{size}=="1953525168"
    ATTR{alignment_offset}=="0"
    ATTR{capability}=="52"
    ATTR{stat}==" 380490 385 15773797 14873260 65875 5634 8394456 26411760 4 759120 41284770"

  looking at parent device '/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host8/target8:0:0/8:0:0:0':
    KERNELS=="8:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{device_blocked}=="0"
    ATTRS{type}=="0"
    ATTRS{scsi_level}=="3"
    ATTRS{vendor}=="TOSHIBA "
    ATTRS{model}=="USB 3.5"-HDD "
    ATTRS{rev}=="100 "
    ATTRS{state}=="running"
    ATTRS{timeout}=="30"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0x6cfb7"
    ATTRS{iodone_cnt}=="0x6cfb7"
    ATTRS{ioerr_cnt}=="0x8"
    ATTRS{modalias}=="scsi:t-0x00"
    ATTRS{evt_media_change}=="0"
    ATTRS{queue_depth}=="1"
    ATTRS{queue_type}=="none"
    ATTRS{max_sectors}=="128"

  looking at parent device '/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host8/target8:0:0':
    KERNELS=="target8:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host8':
    KERNELS=="host8"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0':
    KERNELS=="1-3:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb-storage"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bNumEndpoints}=="02"
    ATTRS{bInterfaceClass}=="08"
    ATTRS{bInterfaceSubClass}=="06"
    ATTRS{bInterfaceProtocol}=="50"
    ATTRS{modalias}=="usb:v0930p0B09d0112dc00dsc00dp00ic08isc06ip50"
    ATTRS{supports_autosuspend}=="0"
    ATTRS{interface}=="Bulk Only Interface"

  looking at parent device '/devices/pci0000:00/0000:00:12.2/usb1/1-3':
    KERNELS=="1-3"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}=="Bulk Only Configuration"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="c0"
    ATTRS{bMaxPower}==" 2mA"
    ATTRS{urbnum}=="3077626"
    ATTRS{idVendor}=="0930"
    ATTRS{idProduct}=="0b09"
    ATTRS{bcdDevice}=="0112"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceSubClass}=="00"
    A...

Read more...

Revision history for this message
sebastian-s (sebastian-s) wrote :

@ Peter Schaefer:
as this seems like a regression between releases ... is there on special place to put a new bug on? e.g. https://bugs.launchpad.net/ubuntu/karmic/+bugs?field.tag=regression-potential

tags: added: regression-potential
security vulnerability: no → yes
Revision history for this message
jawo (jawo) wrote :

I’ve checked the mp3 player with all ubuntu versions since 8.04. Now I have connected (to 10.10) and it works correctly. Seems that there is a problem with firmweare of the device, unfortunately there isn’t new updates on entryx support page so I’ve installed different firmwere created by TEAC.
here is the support page for TEAC MP-380 which is very similar to ENTRYX EM-850
http://www.teac-europe.eu/index.php?id=525
another version of firmware and some useful information you’ll find here:
http://wiki.birth-online.de/know-how/hacking/teac-mp380

I’ve tested both firmwares on two devices ENTRYX EM-850, both works fine, moreover I was able to roll-back to previous version of ENTRYX firmware and than upgrade it again.
I think it should work for other versions of linux as well, but I had tested it just with xubuntu 10.10. Unfortunately I had to use M$ windows to change the firmware. ;)

Revision history for this message
Jools Wills (jools) wrote :

I was having disconnects after kernel 2.6.26 with a usb harddrive on an intel mac mini. No USB quirks, or max sector changes helped. in the end I traced the issue to kernel commit b963801164618e25fbdc0cd452ce49c3628b46c8

I reverted the commit (had to be done manually), and everything is rock solid for me on kernel 2.6.32 - 2.6.38

Attached is the patch I am using currently. applies to 2.6.37/2.6.38 (and maybe earlier)

Revision history for this message
Shane Kerr (shane-time-travellers) wrote :

I know the last comment on this ticket was more than 3 years ago, but I thought I would add a note that this *still* seems to apply to some devices.

I'm running the 3.14 kernel, and hooked up my old Lacie USB 500 GB hard disk. I got identical behavior to that described in this bug report: things would work fine for a while, then disconnect.

Setting /sys/block/sdX/device/max_sectors to 128 (from the default of 240) solves the problem. I was able to run a full "badblocks" and "badblocks -n" across the device without problem.

I'm going to add the udev rule to the computers where I plan on using the disk, so this is a minor issue for me, but I figured I'd just make a note that it is still an issue for folks with certain crappy old hardware. :)

Revision history for this message
Q (thread13) wrote :
Download full text (3.8 KiB)

I am seeing this problem in one or another form since ~2006, and it looks like it will be with us for a while.

My understanding is that there may be a *number* of issues with USB 2.0 + that end with more or less similar symptoms, producing lots of confusion.

A number of workarounds exist, the above is just one of them; basically it all goes down to some way of limiting the connection speed, after what the USB connection seems to survive; the most robust ( and the worst in the terms of efficiency ) is switching down to USB 1.0 :

https://help.ubuntu.com/community/Mount/USB#USB_2_Issues
http://www.thinkwiki.org/wiki/Problem_with_USB_2.0

Please note that for the most of the distributions we can't just do "rmmod ehci_hcd" anymore and have to "unbind" the driver from the usb hub -- or even from a specific port :

http://lists.en.qi-hardware.com/pipermail/discussion/2011-August/008508.html

( The obscure numbers behind this magic are described here : http://www.makelinux.net/ldd3/?u=chp-12-sect-1, here : http://<email address hidden>/msg16895.html and here : http://www.linux-usb.org/FAQ.html#i6 ; this also contains a great introduction in sysfs: http://www.reactivated.net/writing_udev_rules.html )

At USB 2.* level, limiting the speed normally solves most of the issues except for some "intellectual" hardware that likes to go offline to save power etc and never wakes up ; one of these is changing the "max_sectors" value: http://www.linux-usb.org/FAQ.html#i5 ; it may have to do something with setting the proper buffer size as well )

in old days one have had to either write an udev rule ( see the link above ), or add the device into "unusual devs" and then recompile the kernel: http://www.phildev.net/linux/usb-unusualdevs-notes.html, http://lxr.free-electrons.com/source/include/linux/usb_usual.h, http://lxr.free-electrons.com/source/drivers/usb/storage/unusual_devs.h, http://yarchive.net/comp/linux/quirks.html ;

nowadays things are probably better : http://ftp.dei.uc.pt/pub/linux/kernel/people/gregkh/usb/2.6/2.6.28/usb-storage-make-the-quirks-module-parameter-writable.patch, http://lxr.free-electrons.com/source/Documentation/kernel-parameters.txt#L3444 and one can pass certain parameters to the kernel at the boot time : http://lxr.free-electrons.com/source/Documentation/kernel-parameters.txt#L9, e.g. http://anythingbutipod.com/forum/showthread.php?t=49138 .

Back to limiting the connection speed. My favorite way to go is via cgroups ( http://linux.oracle.com/documentation/EL6/Red_Hat_Enterprise_Linux-6-Resource_Management_Guide-en-US.pdf, http://www.mjmwired.net/kernel/Documentation/cgroups.txt, http://www.kernel.org/doc/Documentation/cgroups/devices.txt, http://www.oracle.com/technetwork/articles/servers-storage-admin/resource-controllers-linux-1506602.html, etc ) along with a related udev rule ; this seems to work well in most of the cases.

I will skip a number of related workarounds to keep this comment at a reasonable size ; returning back to the "intellectual" hardware, there are at least two quirk parameters to mention: "autosuspend" and "old_scheme_first" .

First allows us to d...

Read more...

Revision history for this message
Q (thread13) wrote : Re: [Bug 61235] Re: USB mass storage stops working after a while
Download full text (5.0 KiB)

ссылка на этот текст :

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/61235/comments/123

On Sun, Sep 7, 2014 at 4:16 PM, Q <email address hidden> wrote:

> I am seeing this problem in one or another form since ~2006, and it
> looks like it will be with us for a while.
>
> My understanding is that there may be a *number* of issues with USB 2.0
> + that end with more or less similar symptoms, producing lots of
> confusion.
>
> A number of workarounds exist, the above is just one of them; basically
> it all goes down to some way of limiting the connection speed, after
> what the USB connection seems to survive; the most robust ( and the
> worst in the terms of efficiency ) is switching down to USB 1.0 :
>
> https://help.ubuntu.com/community/Mount/USB#USB_2_Issues
> http://www.thinkwiki.org/wiki/Problem_with_USB_2.0
>
> Please note that for the most of the distributions we can't just do
> "rmmod ehci_hcd" anymore and have to "unbind" the driver from the usb
> hub -- or even from a specific port :
>
> http://lists.en.qi-
> hardware.com/pipermail/discussion/2011-August/008508.html
>
> ( The obscure numbers behind this magic are described here :
> http://www.makelinux.net/ldd3/?u=chp-12-sect-1, here : http://www.mail-
> <email address hidden>/msg16895.html and here
> : http://www.linux-usb.org/FAQ.html#i6 ; this also contains a great
> introduction in sysfs:
> http://www.reactivated.net/writing_udev_rules.html )
>
> At USB 2.* level, limiting the speed normally solves most of the issues
> except for some "intellectual" hardware that likes to go offline to save
> power etc and never wakes up ; one of these is changing the
> "max_sectors" value: http://www.linux-usb.org/FAQ.html#i5 ; it may have
> to do something with setting the proper buffer size as well )
>
> in old days one have had to either write an udev rule ( see the link
> above ), or add the device into "unusual devs" and then recompile the
> kernel: http://www.phildev.net/linux/usb-unusualdevs-notes.html,
> http://lxr.free-electrons.com/source/include/linux/usb_usual.h,
> http://lxr.free-electrons.com/source/drivers/usb/storage/unusual_devs.h,
> http://yarchive.net/comp/linux/quirks.html ;
>
> nowadays things are probably better :
> http://ftp.dei.uc.pt/pub/linux/kernel/people/gregkh/usb/2.6/2.6.28/usb-
> storage-make-the-quirks-module-parameter-writable.patch, http://lxr
> .free-electrons.com/source/Documentation/kernel-parameters.txt#L3444 and
> one can pass certain parameters to the kernel at the boot time :
> http://lxr.free-electrons.com/source/Documentation/kernel-
> parameters.txt#L9, e.g.
> http://anythingbutipod.com/forum/showthread.php?t=49138 .
>
> Back to limiting the connection speed. My favorite way to go is via
> cgroups (
> http://linux.oracle.com/documentation/EL6/Red_Hat_Enterprise_Linux-6
> -Resource_Management_Guide-en-US.pdf,
> http://www.mjmwired.net/kernel/Documentation/cgroups.txt,
> http://www.kernel.org/doc/Documentation/cgroups/devices.txt,
> http://www.oracle.com/technetwork/articles/servers-storage-admin
> /resource-controllers-linux-1506602.html, etc ) along with a related
> udev rule ; this seems to wor...

Read more...

Displaying first 40 and last 40 comments. View all 124 comments or add a comment.
This report contains Public Security information  
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.