linux-kernel - Re: Major SATA / EXT3 Issue?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1193825330.6392.23.camel@localhost>
Date:	Wed, 31 Oct 2007 05:08:50 -0500
From:	Chris Holvenstot <cholvenstot@...cast.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: Major SATA / EXT3 Issue?

First, let me thank you for your response, and apologize for taking so
long to get back to you.  I have not been able to "cut loose" from my
day job for the past several days as I have been completly tied up
loading and configuring a dozen Thinkpads scheduled to be sacraficed
next week.

With this failure there was no data to be collected from the time of the
failure- as previously stated, the system "appeared" to lock up.  I
could not switch to an alternitive tty nor could I ssh into the system
from one of my other boxes. 

Nothing showed in the logs at the time of the failure.

On subsequent reboots I received "scrolling" errors on both of the
devices in question of the type previously reported.  This continued
through every attempt to reboot.

Attempts to clean things up with an fsck always resulted in the
following message

fsck.ext2: No such file or directory while trying to open /dev/sdb1

(or /dev/sda1 dependent on which device was being used)

I attempted to run gparted to see what if any file system the system
thought might be lurking on these drives, but gparted would always hang
up "scanning devices"

This morning I plugged the drives back in and brought the system up on a
2.6.24-rc1-git4 kernel and shazamm!  Both drives were seen by the system
and the only errors seen by fsck were a few unused / orphan inodes.  

I am not sure where to go from here - I have been in the game long
enough to be doubtful about multiple INDEPENDENT hardware failures -
which is why after "blowing off" the first dead SATA drive, I took
another look when I had a second one fail in the same manner within a
few days.

Both of the previously failed drives are up and running at this time.
Understandably I am not ready to put "real data" back on them but I will
button up the case, bring the system back up, and come up withsome way
to flow "test data" between these two devices looking for another
failure.

Once again thanks for your time.

Chris

On Sat, 2007-10-27 at 13:47 +0100, Alan Cox wrote:
> On Fri, 26 Oct 2007 21:21:52 -0500
> Chris Holvenstot <cholvenstot@...cast.net> wrote:
> 
> > My SATA controller is integrated on my MSI motherboard and sports four
> > ports.  It is implemented using the Nvidia CK804 chipset.  My processor
> > is an AMD64 X2 4600+ running the 32 bit version of Linux.  
> > 
> > I have had these drives up and running for about six months.=
> 
> You don't provide enough information to even guess. The whole of the
> relevant part of the ata messages would be a lot more useful than the
> cutting/pasting of bits you've provided.

> The BIOS finding the drive is indicating it responds to identify and the
> basic commands (and usually means your cabling is fine), but really the
> rest of the trace is needed to see what occurs next. If the drive has
> gone then the partition table read will fail and you won't
> get /dev/sdb[something] for it.
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/