From: Grant Edwards on
On 2010-04-10, David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote:
> On Fri, 09 Apr 2010 22:50:04 -0400, Grant Edwards <invalid(a)invalid.invalid> wrote:
>
>> Can somebody explain why IDE DMA timing would affect a USB attached
>> drive?
>
> As I understand it, even though the usb-storage module is being used
> to provide the raw access, the ide modules are used to actually do
> the data transfer.

No, the drivers for the USB controller do the data trasfer. Above
that is the USB mass storage driver, and above that is the SCSI disk
driver. AFAIK, the IDE modules have nothign to do with it.

> I may be wrong in this, which is why I'd like to know if either of
> the workarounds I suggested actually work.
>
> Both of those workarounds were from when the ata module(s) were
> detecting 80 wire ide cables when 40 wire ide cables were actually
> installed. In that case, the kernel module selected udma transfer
> rates, that the cables could not handle.
>
> This may have no impact in this case, but I can't think of any other
> reason why the use of usb to access the drive would fail, while the
> same drive works fine when internally connected, other then a problem
> with the enclosure.

I think you've hit the nail on the head: the USB<->IDE chip in the
enclosure is buggy.

> Note that usb uses dma access too.

Yes, but it has nothing to do with the IDE settings.

--
Grant

From: Robert Heller on
At Sat, 10 Apr 2010 13:33:47 +0000 (UTC) Grant Edwards <invalid(a)invalid.invalid> wrote:

>
> On 2010-04-10, David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote:
> > On Fri, 09 Apr 2010 22:50:04 -0400, Grant Edwards <invalid(a)invalid.invalid> wrote:
> >
> >> Can somebody explain why IDE DMA timing would affect a USB attached
> >> drive?
> >
> > As I understand it, even though the usb-storage module is being used
> > to provide the raw access, the ide modules are used to actually do
> > the data transfer.
>
> No, the drivers for the USB controller do the data trasfer. Above
> that is the USB mass storage driver, and above that is the SCSI disk
> driver. AFAIK, the IDE modules have nothign to do with it.
>
> > I may be wrong in this, which is why I'd like to know if either of
> > the workarounds I suggested actually work.
> >
> > Both of those workarounds were from when the ata module(s) were
> > detecting 80 wire ide cables when 40 wire ide cables were actually
> > installed. In that case, the kernel module selected udma transfer
> > rates, that the cables could not handle.
> >
> > This may have no impact in this case, but I can't think of any other
> > reason why the use of usb to access the drive would fail, while the
> > same drive works fine when internally connected, other then a problem
> > with the enclosure.
>
> I think you've hit the nail on the head: the USB<->IDE chip in the
> enclosure is buggy.

Or the motherboard's DMA controller and/or USB controller and/or the
motherboard's USB<=>DMA interface logic...

It might also be that some *newer* IDE disks are using a more advanced
IDE spec (ATA-6?) and the USB<->IDE chip in the enclosure does not
really support this and the disk(s) are not downgrading themselves
properly.

>
> > Note that usb uses dma access too.
>
> Yes, but it has nothing to do with the IDE settings.
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/

From: Kevin the Drummer on
Grant Edwards <invalid(a)invalid.invalid> wrote:

> > This may have no impact in this case, but I can't think of any other
> > reason why the use of usb to access the drive would fail, while the
> > same drive works fine when internally connected, other then a problem
> > with the enclosure.
>
> I think you've hit the nail on the head: the USB<->IDE chip in the
> enclosure is buggy.

Is there a USB<->IDE chip in my enclosure if it supports SATA
drives and not ATA (IDE) drives?

Thanks....

--
PLEASE post a SUMMARY of the answer(s) to your question(s)!
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.
From: Kevin the Drummer on
David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote:
> On Fri, 09 Apr 2010 12:28:57 -0400, Kevin the Drummer <nobody(a)cosgroves.us> wrote:
>
> > Apr 8 23:21:22 : sd 9:0:0:0: SCSI error: return code = 0x8000002
> > Apr 8 23:21:22 : sdf: Current: sense key: Aborted Command
> > Apr 8 23:21:22 : Additional sense:
> > Apr 8 23:21:22 : Logical unit communication CRC error (Ultra-DMA/32)
> > Apr 8 23:21:22 : end_request: I/O error, dev sdf, sector 96238085
> > Apr 8 23:21:22 : Buffer I/O error on device sdf8, logical block 2168
>
> Try booting with the kernel option "all_generic_ide=1", then running
> the mkfs commands again.

Well, I tried that. Same story again. When I did my rsync to the
external drive it appeared to work for many files, then I got a bunch
of this

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: \
Broken pipe (32)
rsync: write failed on \
"/media/disk/mirror/music/etc/gconf/schemas/evolution-mail.schemas": \
Read-only file system (30)
rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.6]
rsync: recv_generator: mkdir \
"/media/disk/mirror/music/etc/locale/en_CA/LC_MESSAGES" failed: \
Read-only file system (30)
*** Skipping any contents from this failed directory ***
rsync: failed to set times on \
"/media/disk/mirror/music/etc/locale/en_DK.ISO-8859-1": \
Read-only file system (30)
rsync: symlink \
"/media/disk/mirror/music/etc/locale/en_DK.ISO-8859-1/LC_COLLATE" -> \
"../ISO-8859-1/LC_COLLATE" failed: Read-only file system (30)
rsync: symlink \
"/media/disk/mirror/music/etc/locale/en_DK.ISO-8859-1/LC_CTYPE" -> \
"../ISO-8859-1/LC_CTYPE" failed: Read-only file system (30)
rsync: recv_generator: mkdir \
"/media/disk/mirror/music/etc/locale/en_DK.ISO-8859-1/LC_MESSAGES" \
failed: Read-only file system (30)
*** Skipping any contents from this failed directory ***
rsync: failed to set times on \
"/media/disk/mirror/music/etc/locale/en_DK.UTF-8":

While rsync was reporting a read-only file system, 'mount' claimed

/dev/sdh8 on /media/disk type ext3 (rw,nosuid,nodev,uhelper=hal)

Also, /var/log/messages reported a huge number of lines like these:

Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Sense Key : Aborted
Command [current]
Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Add. Sense: Logical unit
communication CRC error (Ultra-DMA/32)
Apr 10 13:00:43 music klogd: end_request: I/O error, dev sdh, sector
127315565
Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Sense Key : Aborted
Command [current]
Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Add. Sense: Logical unit
communication CRC error (Ultra-DMA/32)
Apr 10 13:00:43 music klogd: end_request: I/O error, dev sdh, sector
127315661
Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Apr 10 13:00:43 music klogd: sd 7:0:0:0: [sdh] Sense Key : Aborted
Command [current]

The good news is that files actually got transferred to the drive, unlike
last time when rsync reported that, but the files weren't actually
there. The bad news is that a few minutes later the drive can't talk to
the computer at all. That situation doesn't change with multiple
combinations of rebooting and power cycling.


My very unprovable hunch is that this is an enclosure problem, or a
compatibility problem between the enclosure chips/firmware and the
USB/ATA stuff in each of my two computers. If I knew whether my two
computers were using the same chipsets, then I might be able to pile
more evidence for or against this hunch.

I think I'll return my external drive enclosures. One person suggested
that I try a Vantec NexStar as he's used numerous enclosures from them
over the years and had zero problems.

Thanks for the suggestions!!!

--
PLEASE post a SUMMARY of the answer(s) to your question(s)!
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.
From: Kevin the Drummer on
David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote:
> Another option to try, is addin a line to /etc/modprobe.conf with
> options libata force=2:udma33
> and then rebooting.

I didn't try that. My drive is messed up enough now (actually both of
them) that I'd need to reinstall them internally on the SATA bus
(again!) in order to return them to a usable state.

> Both of these are attempts to try to get the kernel to use a slower
> dma mode.

But, what if I don't want a slower DMA mode on my internal drives?
I'd take a slower transfer rate on the external drives, if it was
absolutely required. But, I'd like to rule out oddities with my
enclosure first.

> Either way, a bug report should probably be raised at
> https://qa.mandriva.com/index.cgi

I've tried so many things, with such unrepeatable failures. Only the
fact that it fails is repeatable. I'm not sure I could come up with a
cogent report, at least not with out hours of very clear experimentation
in order to see what is repeatable. Your thoughts on that?

Thanks again....

--
PLEASE post a SUMMARY of the answer(s) to your question(s)!
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.