Re: ATA errors corrupt other I/O & set / readonly

[Robert Hancock <hancockrwd@gmail.com>]

Sorry I missed your response initially. Please use reply-to-all.

On 05/19/2012 10:56 PM, Felix Miata wrote:
> On 2012/05/19 17:28 (GMT-0600) Robert Hancock composed:
>
>> On 2012/05/02 Felix Miata wrote:
>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=43128
> ...
>>> Please, what should I do?
>
>> It's hard to follow the discussion in the openSUSE bug report. I'm not
>> sure if there was any dmesg posted from the case where other IO was
>> being interfered with by the problems with the external device. In AHCI
>> mode that really shouldn't happen, but in IDE mode on Intel controllers
>> it may be more possible because of the PATA emulation that's effectively
>> being done by the controller.
>
> The "other" I/O being done while I'm attempting to use these is usually
> limited to tty I/O, either bash or MC running in bash running on
> tty[1-6] in runlevel 3 to copy files between one HD and another, usually
> both source and target in individual RX-358 units, often just from the
> NTFS partition to the EXT2 partition in the same RX-358 unit. The STB[1]
> that I bought the V2 to use with only writes to Windows partitions via
> USB connection, which complicates life by forcing me to move files off
> the NTFS partition to free up space.
>
> The V2 also produces trouble in USB mode, and when connected via SATA to
> WinXP, for which the only workaround I know is rebooting until it gets
> recognized. Connected via USB to the STB the NTFS partition would
> sometimes become marked so as to become unavailable to the STB. The only
> way to reenable access to it is to have WinXP run CHKDSK on it, which is
> how I would discover the unreliability of its connectibility to WinXP.
>
> I use these devices with multiple machines, many of which are Dells
> whose BIOS contain the string "AHCI" nowhere in setup. I never set any
> machine to use a legacy mode except temporarily for troubleshooting
> purposes, but this doesn't necessarily mean AHCI is used.
>
> IIRC, I was only ever asked for /var/log/messages, never dmesg. I can
> never remember what distinguishes the content provided by the two.

/var/log/messages contains non-kernel logging as well, but it sometimes 
doesn't show all log messages output in dmesg.

>
> If you want a dmesg attached to either bug, I need to know when and how
> you want me to try and get it. I say "try" because once corruption
> begins, getting dmesg is unlikely via keyboard on a tty, and potential
> methods of fetching it any other way are not known to me. It might be
> sitting on tty11 or elsewhere that I could copy manually from if I knew
> well enough what to copy or omit.

It's possible you may be able to use a previously-opened SSH login from 
another machine to see dmesg output even if the process running on the 
console is stalled due to an I/O problem. Also, you could try booting 
from a USB live image so that any ATA issues won't prevent the system 
from reading executables.

>
>> It's not possible to put in a blacklist entry for a specific SATA
>> enclosure because they're essentially a passive device and there's no
>> way to identify them through software (unless they have a custom ID
>> string like the WD MyBook drives). If it only works properly at 1.5 Gbps
>> then a module/boot parameter may be the best solution.
>
> It would be helpful if I knew a blanket cmdline parameter to use to cap
> everything at 1.5 instead of for each machine having to discover all the
> bus particulars and remember which go where on reboot to place them into
> effect only for the port the V2 is or might be connected to. I can't
> picture myself noticing on any of my machines whether I/O was capped at
> 1.5 or not. The maximum number of HDs used at once in any of them would
> be two in most, and three in two machines with RAID1 configured.

I haven't tested but AFAICS, using libata.force=1.5Gbps should force 1.5 
Gbps on all ports.

>
> A couple of weeks after filing the kernel.org bug I contacted the
> manufacturer again to provide the new information contained in the bugs.
> Again it offered to replace. Only yesterday I finally answered the offer
> that I'd probably prefer to keep it in lieu of wasting more money on
> shipping only to be left with no opportunity for further testing and bug
> follow-up, and yet another replacement no better than the original, or a
> store credit making me shop for something else with equivalent
> functionality.
>
> If there was a kernel dev interested in pursuing this it might be
> possible to get the manufacturer to provide a V2 device to test with.
> Considering the current delivered price of the V2 is roughly half that
> of the V1 it appears remaining stock is trying to be dumped.
>
> [1] http://www.manhattan-digital.net/rs1933.htm