From: Robert Hancock <hancockr@shaw.ca>
To: Chris Holvenstot <cholvenstot@comcast.net>
Cc: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Major SATA / EXT3 Issue?
Date: Sun, 28 Oct 2007 12:37:19 -0600 [thread overview]
Message-ID: <4724D6DF.4090602@shaw.ca> (raw)
In-Reply-To: <fa.g6cnSE4eZYP/DJbEoDA1gYUnPfo@ifi.uio.no>
Chris Holvenstot wrote:
> I am curious if anyone else has had major problems with SATA drives on
> the current series of kernels. I have (or rather had) two SATA drives
> on my system - the first was a Maxtor MaxLine 500 and the second was a
> Maxtor MaxLine 250.
>
> Both of these drives were plugged to the 1.5 Gigabyte / second mode.
>
> 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.
>
> The first drive "failed" about 10 days ago - and unfortunately I focused
> on hardware error and after several attempts to get the drive back
> online I physically pulled it from the system. This drive was used for
> backups and thus was not critical to day-to-day operations.
>
> However, tonight I "lost" a second SATA drive, this one I use on a daily
> basis for my kernel build and test processes. It failed in the same
> manner as the first, which makes me a little suspicious.
>
>
> The first drive “failed” while I was running a modified Ubuntu 7.04
> system. Because I focused on hardware as the reason for the failure I
> did not collect specific information about the version of the kernel
> being used, but it was likely to be 2.6.24-git8.
>
>
> The second drive “failed” tonight on what is, except for the kernel, a
> fairly standard Ubuntu 7.10 system (the same hardware - I upgraded my OS
> this past week) – the kernel in use tonight at the time of the second
> failure was 2.6.24-rc1-git1
>
>
> In each case the failure mode appears to have been the same – the system
> appears to lock up. When rebooted I get a long string of messages like:
>
>
> Oct 26 20:07:37 localhost kernel: [ 101.581091] ata2: timeout waiting
> for ADMA IDLE, stat=0x440
>
> Oct 26 20:07:37 localhost kernel: [ 101.581096] sd 1:0:0:0: [sda] Write
> Protect is off
>
> Oct 26 20:07:37 localhost kernel: [ 101.581174] res
> 71/04:08:00:00:00/04:00:1d:00:00/e0 Emask 0x1 (device error)
>
> Oct 26 20:07:37 localhost kernel: [ 101.644992] ata2.00: configured for
> UDMA/33
>
> Oct 26 20:07:37 localhost kernel: [ 101.644994] ata2: EH complete
>
> Oct 26 20:07:37 localhost kernel: [ 101.645006] sd 1:0:0:0: [sda] Write
> cache: disabled, read cache: enabled, doesn't support DPO or FUA
You should try and get some output from dmesg and not from the messages
log, as the log daemon seems to have a nasty habit of discarding
critical output from these errors. In this case the failing command is
missing and the message ordering even seems off.
>
>
> The hardware appears to be correctly identified by the BIOS during the
> power up sequence.
>
>
> Not much is seen in the dmesg log excpet for:
>
>
> [ 43.649673] scsi0 : sata_nv
>
> [ 43.649722] scsi1 : sata_nv
>
> [ 43.649776] ata1: SATA max UDMA/133 cmd 0x9f0 ctl 0xbf0 bmdma 0xcc00
> irq 19
>
> [ 43.649778] ata2: SATA max UDMA/133 cmd 0x970 ctl 0xb70 bmdma 0xcc08
> irq 19
There should be more than this at the very least.. As above, please try
to get output from dmesg itself.
>
>
> When I try to run a file system check on these devices I get:
>
>
>
>
> e2fsck 1.40.2 (12-Jul-2007)
>
> fsck.ext2: No such file or directory while trying to open /dev/sdb1
>
> The superblock could not be read or does not describe a correct ext2
>
> filesystem. If the device is valid and it really contains an ext2
>
> filesystem (and not swap or ufs or something else), then the superblock
>
> is corrupt, and you might try running e2fsck with an alternate
> superblock:
>
> e2fsck -b 8193 <device>
>
>
> I have a gut feeling that when the system appears to lock up what is
> really going on is that the contents of the drive are being trashed. But
> I have no proof of that.
I don't think that is the case, more like the drives have not been
detected at all. If this happens after a reboot when they were working
before, that sounds like some kind of a hardware issue most likely..
>
>
> When I try to do a parted to see what the system thinks is on the drive
> I get the error message:
>
>
> Error: Error opening /dev/sdb: No medium found
>
>
> I am not having any problems with my EXT3 file systems located on
> “standard” IDE / PATA drives.
>
>
> My config file, which has not changed in months beyond taking the
> defaults during make oldconfig looks like:
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
next parent reply other threads:[~2007-10-28 18:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.g6cnSE4eZYP/DJbEoDA1gYUnPfo@ifi.uio.no>
2007-10-28 18:37 ` Robert Hancock [this message]
2007-11-02 0:30 Major SATA / EXT3 Issue? Norbert Preining
-- strict thread matches above, loose matches on Subject: below --
2007-10-27 2:21 Chris Holvenstot
2007-10-27 12:47 ` Alan Cox
2007-10-31 10:08 ` Chris Holvenstot
2007-10-27 14:14 ` Clemens Koller
2007-10-30 13:59 ` Heikki Orsila
2007-10-31 7:25 ` Theodore Tso
2007-10-31 9:24 ` Heikki Orsila
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4724D6DF.4090602@shaw.ca \
--to=hancockr@shaw.ca \
--cc=cholvenstot@comcast.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.