Problems with the new Seagate 1.5TB hard drives

[jafa]

My system has been running Hardy with 3 x 500GB Seagate SATA drives. This worked well.

I have just replaced the drives with 2 x 1.5TB Seagate SATA drives.

Now the system freezes for 30 seconds every so often. Each time it freezes the kernel log indicates an error "ata frozen", "resetting" and the command looks to be a flush-cache-to-disk command. The exact text is below.

This is the same OS install (direct disk copy) that worked with the Seagate 500GB drives.

I have seen the error on both 1.5TB drives.

Any ideas?

Nick

ata1.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x6 frozen
ata1: SError: { HostInt }
ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 40/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x44 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
sd 0:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[prshah]

ata1.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x6 frozen
ata1: SError: { HostInt }
ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 40/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x44 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link

Surprisingly, this is sometimes due to logical filesystem damage (not physical). I often get this error if the system is not shutdown properly. To resolve it, I boot off a live CD, and run fsck on the filesystem

sudo fsck -a /dev/sdb

If you get an error such as "Unexpected inconsistency - run fsck manually", then you have to run it without the "-a" switch. The status messages when running fsck will be interspread with messages similar to the one above; you can ignore them. When asked to fix anything, give "y" (in fact, I just pres Y+Enter 15 times and then leave the system to do it's thing). You can also try the "-y" flag (assume "Yes").

There is a very real possibility of data loss; so you do this at your own risk. In my own case, I have often lost package information, but luckily enough no data and/or critical files. YMMV.

Post back with your results.

[jafa]

Hi,

There are two files systems, both ext3, and both passed a force check without error.

Nick

[jafa]

Ok, must be a kernel bug in Hardy 2.6.24... upgrading to a stock 2.6.26 kernel fixed the problem.

[jafa]

Scratch that.

With the Hardy kernel the error occurs every 20 mins watching TV (mythtv) but each time recovers after 20-30 seconds.

With the 2.6.26 kernel the error doesn't occur as often, but when it hits it takes the machine down (any disk access returns an IO error).

The motherboard is an AMD based chipset. I added a PCI-E SATA controller (different chipset) and the same errors occur.

Nick

[jafa]

Ok, workaround...

The specific ATA command each freeze turned out to always be a cache-flush command.

Disabling write cache on the drive avoided the problem:
hdparm -W0 /dev/sda

For other people seeing ATA errors - check if the command is exactly "cmd ea/00:00:00:00:00/00:00:00:00:00/a0" - if you are seeing different numbers then you are probably seeing a different error and the above workaround probably won't apply.

Still no idea why the cache flush command causes Ubuntu to freeze with these drives.

Nick

[AndreMiller]

You are not alone in your frustrations with this drive. I was running a 4 drive RAID5 with Seagate 1TB drives and are in process of swapping them out for Seagate 1.5TB drives.

The array has been running fine until I replaced one of the drives. To replace I simply pulled out one of the drives to let the array run in a degraded mode, plugged in the new 1.5TB drive, added it as a spare and then had md rebuild the array.

I received no errors while rebuilding, but now when I watch video off the array I get a couple of seconds lockup and then it would continue.

I saw similar errors in the log file:

[73993.695861] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[73993.695887] ata6.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[73993.695891] res 40/00:00:00:4f:c2/00:00:00:00:00/40 Emask 0x4 (timeout)
[73993.695913] ata6.00: status: { DRDY }
[73993.695934] ata6: hard resetting link
[73994.336493] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[73994.405922] ata6.00: configured for UDMA/133
[73994.405940] ata6: EH complete
[73994.406323] sd 5:0:0:0: [sdc] 2930277168 512-byte hardware sectors (1500302 MB)
[73994.415687] sd 5:0:0:0: [sdc] Write Protect is off
[73994.415696] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[73994.441321] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

I swapped cables, controllers, slots in the hotswap bay, power rails and even bypassed the bay and plugged it in directly. The errors always occur only on the 1.5TB drive.

I'm going to try your suggestion disabling the write cache to see if it resolves the problem, but I'm also curious as to why this is happening.

I'm running Kernel 2.6.24-16.

PS: I also noticed that the drive is always in 3.0 Gbps SATA II mode. I tried forcing it to 1.5 Gbps mode to see if that would help, but putting the jumper in doesn't make a difference, the controller (and Linux) still reports it running in SATA II mode.

[AndreMiller]

Just some feedback.. since making that quick fix of yours jafa the problem has gone away. Although I'm sure it has some impact on performance.

I have also noticed something else in my logs:

[ 46.025256] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 46.027051] ata2.00: failed to set max address (err_mask=0x1)
[ 46.027054] ata2.00: device aborted resize (2930277168 -> 18446744072344861488), skipping HPA handling
[ 46.027060] ata2.00: ATA-8: ST31500341AS, SD17, max UDMA/133
[ 46.027062] ata2.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[ 46.028493] ata2.00: configured for UDMA/133

I only get that error message on the 1.5TB drive, the other drives don't seem to have that problem:

[ 45.386592] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 45.388155] ata1.00: ATA-8: ST31000340AS, SD15, max UDMA/133
[ 45.388160] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[ 45.390115] ata1.00: configured for UDMA/133
[ 46.664930] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 46.666465] ata3.00: ATA-8: ST31000340AS, SD15, max UDMA/133
[ 46.666468] ata3.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[ 46.668379] ata3.00: configured for UDMA/133
[ 47.304586] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 47.306191] ata4.00: ATA-8: ST31000340AS, SD15, max UDMA/133
[ 47.306195] ata4.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[ 47.308167] ata4.00: configured for UDMA/133

Are you noticing the same thing jafa?

[tigertech]

As an additional data point: I am a Debian etch user (etch-and-a-half, kernel 2.6.24) having the exact same problem with the new Seagate 1.5 TB ST31500341A drives.

I have tested two of them, and with write caching enabled (the default), they both fail in a RAID 1 array within minutes of applying heavy disk write load to them, with the same symptoms you're seeing:

Oct 11 22:27:57 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
Oct 11 22:27:57 kernel: ata4.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Oct 11 22:27:57 kernel:          res 40/00:01:09:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Oct 11 22:27:57 kernel: ata4.00: status: { DRDY }
Oct 11 22:28:02 kernel: ata4: port is slow to respond, please be patient (Status 0xd0)
Oct 11 22:28:07 kernel: ata4: prereset failed (errno=-16)
Oct 11 22:28:07 kernel: ata4: reset failed, giving up
Oct 11 22:28:07 kernel: ata4.00: disabled
Oct 11 22:28:07 kernel: ata4: EH complete
Oct 11 22:28:07 kernel: sd 3:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Oct 11 22:28:07 kernel: end_request: I/O error, dev sdd, sector 2929677503
Oct 11 22:28:07 kernel: md: super_written gets error=-5, uptodate=0
Oct 11 22:28:07 kernel: raid1: Disk failure on sdd1, disabling device.

Disabling the write cache solves the problem.

This is specifically related to the new 1.5 TB disks: the server also has some 1 TB Seagate drives in it (model ST31000340AS) that do not have this problem.

In answer to AndreMiller seeing a "device aborted resize (2930277168 -> 1844674407234486148), skipping HPA handling" message -- I do not have that problem. That part of my logs looks normal:

ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.00: HPA detected: current 2930277168, native 18446744072344861488

--
Robert L Mathews

[AndreMiller]

I did some more searching and found that there are loads more users with this problem:

Mac User Thread: http://forums.macrumors.com/showthread.php?t=571843
Synlogy Users Thread: http://www.synology.com/enu/forum/vi...p?f=26&t=10746
Toms Hardware Users Thread: http://www.tomshardware.com/forum/24...s-st31500341as
Netgear ReadyNAS (They removed it from their compatibility list after user complaints): http://www.readynas.com/forum/viewto...st=0&sk=t&sd=a

Hopefully Seagate gets on the ball here and releases a firmware fix.