Ubuntu

USB mass storage stops working after a while

Reported by Gustavo Carneiro on 2006-09-19
450
This bug affects 11 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned
linux-source-2.6.17 (Ubuntu)
Undecided
Unassigned
linux-source-2.6.19 (Ubuntu)
Undecided
Unassigned
linux-source-2.6.20 (Ubuntu)
Medium
Unassigned
linux-source-2.6.22 (Ubuntu)
Undecided
Unassigned
udev (Ubuntu)
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 :

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.

Gustavo Carneiro (gjc) wrote :
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
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.

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.

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?

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.

Gustavo Carneiro (gjc) wrote :

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

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

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
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
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'"

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 :

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 :

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."

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.

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

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)

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
Gustavo Carneiro (gjc) wrote :

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

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.

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! :)

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! :)
>

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
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...

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

see attachment

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

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>

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.

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

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

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

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

pnd (philippdorner) wrote :

email sent- thanks very much!!

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

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.

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...

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...

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

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
41 comments hidden view all 121 comments
John (j-eitens) wrote :

The most discussion here is changing the interfacing between hdd and the os. What for me worked was simpel; Changing the jumpers.
Use the manufactuars website to be sure youve got the jumpers is the wright settings. The jumpers (in case of connecting hdd through usb) must be set to master.

good luck.

John

Nelson Benitez (gnel) wrote :
Download full text (3.2 KiB)

Hi, my problem is not a hard disk but my nokia n73, when I plugged the usb cable and select mass-storage mode in the phone, the phone does not get mounted, I put at the end of this comment the relevant dmesg output. I can't set allow_restart or max_sectors because it says "permission denied" but I do it with sudo so it's not a problem of being root, and I havent been able to test at setting it from udev because the model and vendor attributes are empty so I can't match on those...

[65507.480000] usb 3-1: new full speed USB device using uhci_hcd and address 50
[65507.644000] usb 3-1: configuration #1 chosen from 1 choice
[65507.652000] scsi17 : SCSI emulation for USB Mass Storage devices
[65507.652000] usb-storage: device found at 50
[65507.652000] usb-storage: waiting for device to settle before scanning
[65512.652000] usb-storage: device scan complete
[65512.656000] scsi 17:0:0:0: Direct-Access PQ: 0 ANSI: 0
[65512.668000] sd 17:0:0:0: [sdc] 3994377 512-byte hardware sectors (2045 MB)
[65512.668000] sd 17:0:0:0: [sdc] Write Protect is off
[65512.668000] sd 17:0:0:0: [sdc] Mode Sense: 03 00 00 00
[65512.668000] sd 17:0:0:0: [sdc] Assuming drive cache: write through
[65512.680000] sd 17:0:0:0: [sdc] 3994377 512-byte hardware sectors (2045 MB)
[65512.680000] sd 17:0:0:0: [sdc] Write Protect is off
[65512.680000] sd 17:0:0:0: [sdc] Mode Sense: 03 00 00 00
[65512.680000] sd 17:0:0:0: [sdc] Assuming drive cache: write through
[65512.680000] sdc:
[65512.720000] sd 17:0:0:0: [sdc] Attached SCSI removable disk
[65512.720000] sd 17:0:0:0: Attached scsi generic sg3 type 0
[65512.912000] sd 17:0:0:0: [sdc] Device not ready: <6>: Sense Key : Not Ready [current]
[65512.912000] : Add. Sense: No additional sense information
[65512.912000] end_request: I/O error, dev sdc, sector 3994369
[65512.912000] printk: 334 messages suppressed.
[65512.912000] Buffer I/O error on device sdc, logical block 3994369
[65512.912000] Buffer I/O error on device sdc, logical block 3994370
[65512.912000] Buffer I/O error on device sdc, logical block 3994371
[65512.912000] Buffer I/O error on device sdc, logical block 3994372
[65512.912000] Buffer I/O error on device sdc, logical block 3994373
[65512.912000] Buffer I/O error on device sdc, logical block 3994374
[65512.912000] Buffer I/O error on device sdc, logical block 3994375
[65512.916000] sd 17:0:0:0: [sdc] Device not ready: <6>: Sense Key : Not Ready [current]
[65512.916000] : Add. Sense: No additional sense information
[65512.916000] end_request: I/O error, dev sdc, sector 3994369
[65512.916000] Buffer I/O error on device sdc, logical block 3994369
[65512.924000] sd 17:0:0:0: [sdc] Device not ready: <6>: Sense Key : Not Ready [current]
[65512.924000] : Add. Sense: No additional sense information
[65512.924000] end_request: I/O error, dev sdc, sector 3994370
[65512.924000] Buffer I/O error on device sdc, logical block 3994370
[65512.924000] Buffer I/O error on device sdc, logical block 3994371
[65512.932000] sd 17:0:0:0: [sdc] Device not ready: <6>: Sense Key : Not Ready [current]
[65512.932000] : Add. Sense: No additional sense information
[65512.932000] end_request: I/O error, dev ...

Read more...

Nelson Benitez (gnel) wrote :

I forgot to say I'm on ubuntu gutsy.

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)

sebastian-s (sebastian-s) wrote :
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

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

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

Gerd (gerd-headlamps) wrote :

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

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

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 :

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

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.

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

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.

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

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>

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.

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.

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
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...

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...

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.

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

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.

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.

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.

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.

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

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

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

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.

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

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
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.

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...

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
Partha (partha1b) on 2010-01-14
security vulnerability: no → yes
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. ;)

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)

Displaying first 40 and last 40 comments. View all 121 comments or add a comment.
This report contains Public Security information  Edit
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.