USB mass storage stops working after a while
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.
Gustavo Carneiro (gjc) wrote : | #1 |
Gustavo Carneiro (gjc) wrote : | #2 |
John Dong (jdong) wrote : | #3 |
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 |
John Dong (jdong) wrote : | #4 |
http://
A pastebin of what I see... The connection was stable until I tried to copy a 5MB file into the MP3 player.
John Dong (jdong) wrote : | #5 |
UPDATE:
Setting max_sectors in /sys/block/
Maybe the kernel should have some sort of throttling mechanism.
John Dong (jdong) wrote : | #6 |
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?
John Dong (jdong) wrote : | #7 |
- lsusb output Edit (21.7 KiB, text/plain)
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.
Gustavo Carneiro (gjc) wrote : | #8 |
Your trick of setting max_sectors to 128 didn't work for me; same problem as before..
Gustavo Carneiro (gjc) wrote : | #9 |
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
Gustavo Carneiro (gjc) wrote : | #10 |
Alas.. max_sectors = 64 didn't work either. I give up.
Changed in linux-source-2.6.17: | |
status: | Confirmed → Fix Committed |
John Dong (jdong) wrote : | #11 |
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 |
John Dong (jdong) wrote : | #12 |
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_
BUS=="scsi", SYSFS{vendor}
Scott James Remnant (Canonical) (canonical-scott) wrote : | #13 |
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 |
Gustavo Carneiro (gjc) wrote : | #14 |
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...
John Dong (jdong) wrote : | #15 |
http://
"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."
Gustavo Carneiro (gjc) wrote : | #16 |
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.
Gustavo Carneiro (gjc) wrote : | #17 |
Problem remains in kernel 2.6.19-6.
Changed in linux-source-2.6.19: | |
importance: | Undecided → Medium |
status: | Unconfirmed → Confirmed |
Scott James Remnant (Canonical) (canonical-scott) wrote : | #18 |
Could people running feisty try this rule instead:
SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{vendor}
(Note that the use of plural vs singular and == vs = is deliberate)
Ben Collins (ben-collins) wrote : | #19 |
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 |
Gustavo Carneiro (gjc) wrote : | #20 |
Tested against 2.6.20-3; problem remains.
:-(
PetePete (peterrpeterr) wrote : | #21 |
I've been experiancing these problems, added the rule..
BUS=="scsi", SYSFS{vendor}
and it seems to be working fine (copied a 117mb file onto the disk, and read a 96mb file from the disk.
Gustavo Carneiro (gjc) wrote : | #22 |
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! :)
John Dong (jdong) wrote : Re: [Bug 61235] Re: USB mass storage stops working after a while | #23 |
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/
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! :)
>
taavi (taavioramo) wrote : | #24 |
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 |
krull_der_zerstoerer (ubuntu-boczki) wrote : | #25 |
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_
[ 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...
krull_der_zerstoerer (ubuntu-boczki) wrote : | #26 |
- stdout errors Edit (5.1 KiB, text/plain)
if i remove device after it hangs something is printed on stdout
see attachment
Sven Thomsen (sven-tumelum) wrote : | #27 |
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
Jansen Sena (jansen) wrote : | #28 |
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-
# cp /boot/config-
# cd /usr/src/
# make oldconfig
3) I ran the menuconfig and I enabled and disabled some options as showed after:
# cd /usr/src/
# make menuconfig
3.1) Disabled features (Device Drivers --> USB Support):
* FULL speed ISO transactions (USB_EHCI_
* Root Hub Transaction Translators (USB_EHCI_
* Improved Transaction Translator schedulling (USB_EHCI_
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>
Gustavo Carneiro (gjc) wrote : | #29 |
> 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.
pnd (philippdorner) wrote : | #30 |
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_
[ 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_
[ 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/
Jansen Sena (jansen) wrote : | #31 |
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
pnd (philippdorner) wrote : | #32 |
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
Jansen Sena (jansen) wrote : | #33 |
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
pnd (philippdorner) wrote : | #34 |
email sent- thanks very much!!
Jansen Sena (jansen) wrote : | #35 |
Hi friends,
there is a little mistake in my post about how I solved the problem. The followed command:
# cd /usr/src/
is wrong because ".config" is a file. The right thing to do is:
# cd /usr/src/
It was a kind of "copy-and-paste" problem! ;-)
Best regards,
Jansen
fernando (email-launchpad) wrote : | #36 |
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_
On the other hand, when USB_EHCI_SPLIT_ISO, USB_EHCI_
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.
Beefeater (beefeater) wrote : | #37 |
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...
Knitebane (knitebane) wrote : | #38 |
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
bNumConfigura
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurat
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Bulk
Synch Type None
Usage Type Data
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
bNumConfigura
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 ...
Andrew Pines (apines) wrote : | #39 |
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/
#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/
{
u8
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
Beefeater (beefeater) wrote : | #40 |
Andrew,
I changed to 0 in drivers/
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 |
45 comments hidden Loading more comments | view all 125 comments |
sebastian-s (sebastian-s) wrote : | #86 |
sebastian-s (sebastian-s) wrote : | #87 |
sebastian-s (sebastian-s) wrote : | #88 |
can one explain me how to use the script KEYofR ( https:/
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
Gustavo Carneiro (gjc) wrote : | #89 |
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
vencabot (vencabot-teppoo) wrote : | #90 |
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
Gerd (gerd-headlamps) wrote : | #91 |
modprobe -r ehci_hcd doesn't work for me :-(
alonso (honkkis) wrote : | #92 |
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
bNumConfigura
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]
Very old Compaq deskpro PIII 500 Mhz computer
I tried everything suggested in
https:/
What helped me was the combination of 1 and 2:
1. following patch to /drivers/
(found this solution in
http://
)
UNUSUAL_DEV( 0x059f, 0x1010, 0x0000, 0x0000,
"Lacie",
"USB to IDE Disk",
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
Guillaume AVRIL (guillaumeavril) wrote : | #93 |
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!
sebastian-s (sebastian-s) wrote : | #94 |
I am running fine with
/etc/udev/
write SUBSYSTEMS=
and
#!/bin/sh
echo 1 > /sys/class/
in /usr/local/
enigma_0Z (enigma-0za) wrote : | #95 |
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.
Alex (akruth) wrote : | #96 |
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=
Apr 11 12:01:10 ak2 kernel: [ 975.711525] end_request: I/O error, dev sdb, sector 4155884
Tom Nicoll (tnicoll) wrote : | #97 |
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.
skrpc (skrpc) wrote : | #98 |
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:/
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/
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
Jacob Jarick (mem-namefix) wrote : | #99 |
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-
dpkg -i linux*2.
To compile the kernel yourself download the latest from http://
https:/
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://
Note: I misnamed the archive when creating it it was ment to be linux-2.
Quick plug for my own program (cool batch file renamer):
http://
Any questions drop me a line - <email address hidden>
Jacob Jarick (mem-namefix) wrote : | #100 |
Files finished uploading, have at it.
kernel:
http://
root@cesspit:
9c0e457675b326a
root@cesspit:
bb22393ce57b31c
nvidia legacy driver:
http://
root@cesspit:
0ac4efc7b3bc37b
root@cesspit:
86e6fb93c254764
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.
Jacob Jarick (mem-namefix) wrote : | #101 |
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.
Leann Ogasawara (leannogasawara) wrote : | #102 |
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:/
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-
Changed in linux-source-2.6.24: | |
assignee: | nobody → ubuntu-kernel-team |
importance: | Undecided → Medium |
status: | New → Triaged |
Jacob Jarick (mem-namefix) wrote : | #103 |
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=
May 3 11:16:42 cesspit kernel: [155651.218803] sd 6:0:0:0: [sde] Result: hostbyte=DID_ERROR driverbyte=
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=
May 3 11:16:43 cesspit kernel: [155651.474249] sd 7:0:0:0: [sdf] Result: hostbyte=DID_ERROR driverbyte=
May 3 11:16:43 cesspit kernel: [155651.549534] sd 7:0:0:0: [sdf] Result: hostbyte=DID_ERROR driverbyte=
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=
May 3 11:16:43 cesspit kernel: [155651.660971] sd 7:0:0:0: [sdf] Result: hostbyte=DID_ERROR driverbyte=
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...
Jacob Jarick (mem-namefix) wrote : | #104 |
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/SuperCopie
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=
May 3 14:11:26 cesspit kernel: [168053.058638] sd 10:0:0:0: [sdc] Result: hostbyte=
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/
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...
Szabolcs Szakacsits (szaka) wrote : | #105 |
> 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.
Jacob Jarick (mem-namefix) wrote : | #106 |
> 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:/
Leann Ogasawara (leannogasawara) wrote : | #107 |
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://
Martin Emrich (emme) wrote : | #108 |
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{
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.
willisoften (will-copeland) wrote : | #109 |
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{
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:/
You received this bug notification because you are a direct subscriber
of a duplicate bug.
Leann Ogasawara (leannogasawara) wrote : | #110 |
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-
--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://
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.
con (conloos) wrote : | #111 |
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
con (conloos) wrote : | #112 |
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_
* Root Hub Transaction Translators (USB_EHCI_
* Improved Transaction Translator schedulling (USB_EHCI_
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
Leann Ogasawara (leannogasawara) wrote : | #113 |
The 18 month support period for Feisty Fawn 7.04 has reached it's end of life - http://
Changed in linux-source-2.6.20: | |
status: | Confirmed → Won't Fix |
Launchpad Janitor (janitor) wrote : Kernel team bugs | #114 |
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:/
Sergio Zanchetta (primes2h) wrote : | #115 |
The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://
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://
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-
Changed in linux-source-2.6.22 (Ubuntu): | |
status: | New → Won't Fix |
Changed in linux (Ubuntu): | |
status: | Triaged → Incomplete |
Leann Ogasawara (leannogasawara) wrote : | #116 |
After almost 7 weeks with no response to comment https:/
Changed in linux (Ubuntu): | |
status: | Incomplete → Won't Fix |
Nigel Pugh (nigel-pugh) wrote : | #117 |
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/
was required to get the drive working reliably.
Peter Schaefer (derschaefer) wrote : | #118 |
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/
KERNEL=="sdg"
SUBSYSTEM=
DRIVER==""
ATTR{
ATTR{
ATTR{
ATTR{ro}=="0"
ATTR{
ATTR{
ATTR{
ATTR{stat}==" 380490 385 15773797 14873260 65875 5634 8394456 26411760 4 759120 41284770"
looking at parent device '/devices/
KERNELS=
SUBSYSTEMS=
DRIVERS=="sd"
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
looking at parent device '/devices/
KERNELS=
SUBSYSTEMS=
DRIVERS==""
looking at parent device '/devices/
KERNELS=
SUBSYSTEMS=
DRIVERS==""
looking at parent device '/devices/
KERNELS=
SUBSYSTEMS=
DRIVERS=
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
looking at parent device '/devices/
KERNELS=="1-3"
SUBSYSTEMS=
DRIVERS=="usb"
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
ATTRS{
A...
sebastian-s (sebastian-s) wrote : | #119 |
@ Peter Schaefer:
as this seems like a regression between releases ... is there on special place to put a new bug on? e.g. https:/
tags: | added: regression-potential |
security vulnerability: | no → yes |
jawo (jawo) wrote : | #120 |
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://
another version of firmware and some useful information you’ll find here:
http://
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. ;)
Jools Wills (jools) wrote : | #121 |
- 0001-reverted-b963801164618e25fbdc0cd452ce49c3628b46c8.patch Edit (2.5 KiB, text/plain)
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 b963801164618e2
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)
Shane Kerr (shane-time-travellers) wrote : | #122 |
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/
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. :)
Q (thread13) wrote : | #123 |
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:/
http://
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://
( The obscure numbers behind this magic are described here : http://
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://
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://
nowadays things are probably better : http://
Back to limiting the connection speed. My favorite way to go is via cgroups ( http://
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...
Q (thread13) wrote : Re: [Bug 61235] Re: USB mass storage stops working after a while | #124 |
ссылка на этот текст :
https:/
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:/
> http://
>
> 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://
> hardware.
>
> ( The obscure numbers behind this magic are described here :
> http://
> <email address hidden>
> : http://
> introduction in sysfs:
> http://
>
> 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://
> 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://
> http://
> http://
> http://
>
> nowadays things are probably better :
> http://
> storage-
> .free-electrons
> one can pass certain parameters to the kernel at the boot time :
> http://
> parameters.txt#L9, e.g.
> http://
>
> Back to limiting the connection speed. My favorite way to go is via
> cgroups (
> http://
> -Resource_
> http://
> http://
> http://
> /resource-
> udev rule ; this seems to wor...
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.