Problems with USB harddrives

[andyluton]

Hi,

Bought a sheevaplug back in december, however ever since buying it have had issues with USB harddisks.

Have tried multiple external hard discs and a couple of those cheap USB 2 SATA adapters.

2 of the USB hard drives (whilst connected to my old Linkstation Pro) have worked flawlessly.

The issue is that usually after a decent amount of usage, say unraring a few gigabytes or downloading that much it just seems to lose the external drive (though occasionally can have straight away). I inititally assumed it was an issue with NTFS-3g so used EXT2 and 3 - but found teh same issues with these file systems.

I've tried multiple kernel versions and multiple external drives as i said above.

an example of a dmesg output, obviously if you need more information to help me i'd be more than happy to send anything you need :

sd 1:0:0:0: Attached scsi generic sg4 type 0

sd 1:0:0:0: [sde] 1465149168 512-byte logical blocks: (750 GB/698 GiB)

usb-storage: device scan complete

sd 1:0:0:0: [sde] Write Protect is off

sd 1:0:0:0: [sde] Mode Sense: 34 00 00 00

sd 1:0:0:0: [sde] Assuming drive cache: write through

sd 1:0:0:0: [sde] Assuming drive cache: write through

 sde: sde3 < sde5 >

sd 1:0:0:0: [sde] Assuming drive cache: write through

sd 1:0:0:0: [sde] Attached SCSI disk

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sde5, internal journal

EXT3-fs: mounted filesystem with writeback data mode.

eth0: link up, 1000 Mb/s, full duplex, flow control disabled

usb 1-1.4: USB disconnect, address 4

EXT3-fs error (device sde5): ext3_get_inode_loc: unable to read inode block - in                                                                                                ode=31949320, block=63897618

EXT3-fs error (device sde5): ext3_get_inode_loc: unable to read inode block - in                                                                                                ode=51970049, block=103940098

------------[ cut here ]------------

WARNING: at fs/buffer.c:1159 mark_buffer_dirty+0x38/0xe4()

Modules linked in:

[<c0032d30>] (unwind_backtrace+0x0/0xe0) from [<c004428c>] (warn_slowpath_common                                                                                                +0x50/0x68)

[<c004428c>] (warn_slowpath_common+0x50/0x68) from [<c00e8380>] (mark_buffer_dir                                                                                                ty+0x38/0xe4)

[<c00e8380>] (mark_buffer_dirty+0x38/0xe4) from [<c0120860>] (ext3_commit_super+                                                                                                0x5c/0x78)

[<c0120860>] (ext3_commit_super+0x5c/0x78) from [<c0121258>] (ext3_handle_error+                                                                                                0x9c/0xc0)

[<c0121258>] (ext3_handle_error+0x9c/0xc0) from [<c0121348>] (ext3_error+0x4c/0x                                                                                                5c)

[<c0121348>] (ext3_error+0x4c/0x5c) from [<c0119098>] (__ext3_get_inode_loc+0x34                                                                                                0/0x374)

[<c0119098>] (__ext3_get_inode_loc+0x340/0x374) from [<c011c36c>] (ext3_iget+0x4                                                                                                8/0x400)

[<c011c36c>] (ext3_iget+0x48/0x400) from [<c011f7f8>] (ext3_lookup+0x88/0xe8)

[<c011f7f8>] (ext3_lookup+0x88/0xe8) from [<c00ccb10>] (do_lookup+0xcc/0x194)

[<c00ccb10>] (do_lookup+0xcc/0x194) from [<c00cebb8>] (__link_path_walk+0x9ac/0x                                                                                                e94)

[<c00cebb8>] (__link_path_walk+0x9ac/0xe94) from [<c00cf0f0>] (path_walk+0x50/0x                                                                                                9c)

[<c00cf0f0>] (path_walk+0x50/0x9c) from [<c00cf1d8>] (do_path_lookup+0x2c/0x54)

[<c00cf1d8>] (do_path_lookup+0x2c/0x54) from [<c00cfaf0>] (user_path_at+0x60/0x9                                                                                                4)

[<c00cfaf0>] (user_path_at+0x60/0x94) from [<c00c7a50>] (vfs_fstatat+0x38/0x68)

[<c00c7a50>] (vfs_fstatat+0x38/0x68) from [<c00c7b7c>] (sys_stat64+0x20/0x3c)

[<c00c7b7c>] (sys_stat64+0x20/0x3c) from [<c002da20>] (ret_fast_syscall+0x0/0x28                                                                                                )

---[ end trace 0757b0bbc9235df2 ]---

EXT3-fs error (device sde5): ext3_find_entry: reading directory #31948805 offset                                                                                                0

[NewIT_Marcus]

Is there anything that is common to the problem scenarios that you haven't swapped? If you hadn't also tested USB to SATA devices I'd make a point of suggesting the cable. You're not for instance running all the drives from the same power supply?

If it's all tested except for the Sheevaplug, please send an e-mail to jason@newit.co.uk linking to this thread, with some link to your original order information (ie writing from the e-mail address you originally used for the purchase, and quoting your Order number).

[andyluton]

i tried a bunch of different sata / usb cables. The usb 2 sata devcices i've used were 2 of those USB 2 SATA plugs, both with their own power supplies.
I also used a sumvision media centre which has its own powersupply and usb cable.
another device i can remember testing was a SATA adapter that you put the hard drive into the top, takes 2.5 and 3.5 inch drives.. same problem with all of them (eventually)..

does anyone else have any ideas or are we definitely in returns territory?

[nr]

That looks, and sounds very like the symptoms I was suffering from. I had an external WD unit, with its own power supply. Tried different USB cables, and a new power supply for the disk unit, with no change. The disk unit, when plugged into another computer worked faultlessly. The mean time between failures gradually got less and less, until it got to the point the thing was pretty much unusable, with it sometimes failing to mount at all, and other times mounting for just a few minutes before the 'USB disconnect' message. I also tried connecting the USB drive via a powered hub, so there were two power sources. No change.

The bad news is that it seems to be caused by a power supply failure. Of course, to check this, you need to open the case, which voids your warranty. That said, after seeing the state of mine, I'm happy that I opened it up when I did, as it must have been getting pretty toasty in there.

The good news is that if you're willing, you can hack an external 5V supply to feed the plug so you can carry on working while NewIT attempt to source new power supplies.