You guys seem to be my last chance. How guru are you?

I have 2 Reds. Sometimes one fails, sometimes the other, some - rare - times both. Other times they both work.

My hardware:
* Asus M2nPV-VM motherboard - BIOS version 5005 (this was the last version ever released)
* Phenom II X4 910e CPU
* 8GiB DDR2 RAM (dual-channel 800MHz)
* 4 SATA drives:
** 2 Toshiba DTACA100 (ports SATA1 and 3)
** 2 WD Reds WD10EFRX (ports SATA2 and 4)
* ATI/AMD Radeon HD 5450 on a PCIe slot

The symptoms:
* the BIOS will show a drive's data as Cylinder: 4095, Head: 240, Landing Zone: 65534, Sector 255
* the sector count will be 268435455 instead of 1953525168
* LBA instead of LBA48

An example from dmesg (on a Debian wheezy, attached):
[ 1.025094] ata4: SATA max UDMA/133 cmd 0x960 ctl 0xb60 bmdma 0xf308 irq 20
[ 2.464068] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2.473058] ata4.00: ATA-9: WDC WD10EFRX-68PJCN0, 01.01A01, max UDMA/133
[ 2.473061] ata4.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 31/32)
[ 2.481046] ata4.00: n_sectors mismatch 1953525168 != 268435455
[ 2.481048] ata4.00: revalidation failed (errno=-19)
[ 2.481094] ata4: limiting SATA link speed to 1.5 Gbps
[ 2.481097] ata4.00: limiting speed to UDMA/133:PIO3
[ 7.932494] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 7.940661] ata4.00: n_sectors mismatch 1953525168 != 268435455
[ 7.940664] ata4.00: revalidation failed (errno=-19)
[ 7.940707] ata4.00: disabled

Forcing the SATA driver to rescan (echo - - - > /sys/class/scsi_host/hostX/scan) does the trick:
[ 169.394406] ata4: hard resetting link
[ 170.272371] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 170.281149] ata4.00: ATA-9: WDC WD10EFRX-68PJCN0, 01.01A01, max UDMA/133
[ 170.281159] ata4.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 31/32)
[ 170.288893] ata4.00: configured for UDMA/133
[ 170.288910] ata4: EH complete

What i've tried:
* switching cables and ports
* activating large drive in the BIOS (for 4KiB isntead of the 512 emulation) and other BIOS toggles
* activating PUIS on one of the drives to troubleshoot a possible PSU spike on boot or something
* enabling (but not using) the BIOS NVRAID feature (to eventually set the driver into AHCI mode)
* SMART tests are ok

What i haven't done yet:
* set /boot outside the RAID1 that's on the Toshibas - a /boot inside an LVM inside a software RAID could apparently confuse the BIOS, but the system has always booted. Besides, the WDs are empty and not bootable, they're data disks.
* sell the WDs, get another DCACA100, set-up a RAID5 instead of a RAID1 and a ZFS VOL.

The Toshibas have never failed to boot.

The folks at linux-ide have contributed some suggestions, WD support was useless and the WD comunity forums guys suggested what seems to be the most likely cause: the BIOS and the WD firmware don't get along. Either the BIOS is buggy - and i'm outta luck - or the WD FW is; or neither is and i don't know what else to do. Enter the hddguru people.

Any suggestions? My current workaround is to hack a script to count enabled disks on boot, which i'd rather avoid.

When the problem occurs, does the drive have a HPA?

See http://en.wikipedia.org/wiki/Host_prote ... on_methods

_________________
A backup a day keeps DR away.

There's nothing referring HPAs in dmesg on both failed and successful boots. As far as hdparm goes,

# hdparm -N /dev/disk/by-id/ata-WDC_WD10EFRX-68PJCN0_WD-SERIAL1

/dev/disk/by-id/ata-WDC_WD10EFRX-68PJCN0_WD-SERIAL1:
max sectors = 1953525168/1953525168, HPA is disabled

This was a clean boot, all disks were detected.
From hdparm -I:

Commands/features:
Enabled Supported:
* Host Protected Area feature set

So it does support it. I'll check if it's anything there next time it fails.
However, if the drive fails to boot it won't show up in my /dev. I guess i'll find out if hdparm can access the drive regardless.

Can you use dd to copy 4000 sectors, say, from the end of each drive to a file? If it is a BIOS issue, then we may see BIOS related text strings, which would in turn suggest that BIOS is writing a backup of itself to the end of the drive.

_________________
A backup a day keeps DR away.

Yup, if libata kicks the drive it won't be in /dev so there's no way for hdparm to find it.



This is becoming interesting, i never thought of what lies beyond the addressable space...
From hdparm -I:

Ha, there's "intellispeed" for you... Anyway, since drive manufacturers use SI, i went with this:


I was expecting an EndOfDisk or something. Am i to assume there are an extra 205MB of space beyond the declared 1TB of drive size?
Then i had fun with hexdump -C. At the very begining i got this:
(from hexdump's man page the * means it just repeats, so empy stuff) Then
from 0ba32fd0 to 0ba33580 it's ZFS data from my experiments with zpools (the drives have been failling way before this, and i only recently have partitioned them)
from 0ba33590 to 0ba335a0 again empty space
from 0ba4efd0 to 0ba72fd0 random stuff that may or may not be garbage, like:


from 0ba72fd0 to 0ba73580 again ZFS data which seems to be a repetition of the first part
from 0ba73590 to 0c361230 more empty/random data

And then the last bit:


And for the sake of completeness, the same last bit from the other WD:
I was exited to see this, but this may be GRUB's doing, not the BIOS's, dunno. Then again GRUB writes to the MBR, not the ass-end of the drive...
I can pm you the full dump if you want.

However, neither drive is even flaged as bootable, these are data drives only. The Toshibas are the bootable ones with the OS, so the BIOS shouldn't be messing with the WDs (which doesn't mean it isn't).

EFI PART is the backup copy of GPT header which is supposed to be in, well, the last physical sector of the drive.

So the BIOS is not writing to the end of the disks.

It doesn't look like it. ISTM that you may have some other problem.

_________________
A backup a day keeps DR away.

Well, as a wrap-up, what would the BIOS dump at the end of the drive? What would it look like under a hexdump? Would there be a string with the manufacture's name?

Here is your BIOS:

http://dlcdnet.asus.com/pub/ASUS/mb/soc ... M/5005.zip

When you examine the 5005.bin file with a hex editor, you will see text strings such as the following. If your BIOS were being backed up to your drive, then you would find those same strings, after exposing the Host Protected Area (HPA).

_________________
A backup a day keeps DR away.