syslog says HPA detected, hdparm says HPA disabled. Which one do I believe?

[muzo178]

running 5.0 beta6 on an ECS A780GM-A (V1.1). no parity errors.

 

Jun 11 23:33:26 Xserve kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) (Drive related)
Jun 11 23:33:26 Xserve kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) (Drive related)
Jun 11 23:33:26 Xserve kernel: ata1.00: HPA detected: current 2930275055, native 2930277168 (Errors)
Jun 11 23:33:26 Xserve kernel: ata1.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 (Drive related)
Jun 11 23:33:26 Xserve kernel: ata1.00: 2930275055 sectors, multi 0: LBA48 NCQ (depth 31/32) (Drive related)
Jun 11 23:33:26 Xserve kernel: ata4.00: ATA-8: ST31500341AS, CC3H, max UDMA/133 (Drive related)
Jun 11 23:33:26 Xserve kernel: ata4.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) (Drive related)
Jun 11 23:33:26 Xserve kernel: ata1.00: configured for UDMA/133 (Drive related)
Jun 11 23:33:26 Xserve kernel: ata4.00: configured for UDMA/133 (Drive related)

 

My syslog says that there is HPA voodoo going on at ata1 which is one of two identical Seagate 1.5TB drives I have in the system. One of the drives was used with a Gigabyte board previously, but I had removed it with the hdparm command when I brought it in unRaid before preclear.

 

The funny thing is when I run hdparm -N on this drive it says that the HPA is disabled. Actually the output is identical for both of these identical drives:

 

root@Xserve:~# hdparm -N /dev/sda

/dev/sda:
max sectors   = 2930277168/2930277168, HPA is disabled
root@Xserve:~# hdparm -N /dev/sdd

/dev/sdd:
max sectors   = 2930277168/2930277168, HPA is disabled

 

So which one is right?  I have a Seagate 2TB Green drive arriving tomorrow. I am leaning in the way of swapping it for the one with the HPA.. But if hdparm is to be believed, I'd like to keep the 1.5 in there as well.

 

 

 

[muzo178]

is this so weird that no one has any ideas?

[Joe L.]

is this so weird that no one has any ideas?

There is no way from what you have posted for me to know that the drive with the detected HPA is the same one you are running hdparm on.

 

Please post a full syslog, and hdparm -N commands for all your drives.  The actual drive letter can change from one boot to another, do not assume that /dev/sda is always the same physical disk.  Linux assigns the drive letters in the order the disks spin up and initialize.  Since that is done in parallel for all the disks and disk controller, it can change if several are nearly identical in their initialization speed.

[muzo178]

syslog is attached.

 

hdparm output for the drives in the array (sda, sdd, sde, sdf) are posted below. sdb is the flash and sdc is a drive going through preclear right now.

 

root@Xserve:~# hdparm -N /dev/sda

/dev/sda:
max sectors   = 2930277168/2930277168, HPA is disabled
root@Xserve:~# hdparm -N /dev/sdd

/dev/sdd:
max sectors   = 3907029168/3907029168, HPA is disabled
root@Xserve:~# hdparm -N /dev/sde

/dev/sde:
max sectors   = 2930277168/2930277168, HPA is disabled
root@Xserve:~# hdparm -N /dev/sdf

/dev/sdf:
max sectors   = 1953525168/1953525168, HPA is disabled

 

thanks for your help joe.

 

syslog-2011-06-14.txt.zip

[Joe L.]

Your disk does have an HPA, but the linux kernel is doing what it thinks is correct in your situation

 

The HPA is detected here:

Jun 13 20:15:11 Xserve kernel: ata1.00: HPA detected: current 2930275055, native 2930277168

Jun 13 20:15:11 Xserve kernel: ata1.00: ATA-8: ST31500341AS, CC1H, max UDMA/133

Jun 13 20:15:11 Xserve kernel: ata1.00: 2930275055 sectors, multi 0: LBA48 NCQ (depth 31/32)

Jun 13 20:15:11 Xserve kernel: ata1.00: configured for UDMA/133

Jun 13 20:15:11 Xserve kernel: scsi 0:0:0:0: Direct-Access     ATA      ST31500341AS     CC1H PQ: 0 ANSI: 5

It is, as you said, /dev/sda  and here it shows the artificially shorter size.

Jun 13 20:15:11 Xserve kernel: sd 0:0:0:0: [sda] 2930275055 512-byte logical blocks: (1.50 TB/1.36 TiB)

Jun 13 20:15:11 Xserve kernel: sd 0:0:0:0: [sda] Write Protect is off

Jun 13 20:15:11 Xserve kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00

Jun 13 20:15:11 Xserve kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Here the first partition (p1) on the disk is detected, BUT, since it is defined as larger than the artificial "end-of-disk" allows, linux is enabling the use of the native capacity (basically ignoring the HPA)

Jun 13 20:15:11 Xserve kernel:  sda: sda1

Jun 13 20:15:11 Xserve kernel: sda: p1 size 2930277104 extends beyond EOD, enabling native capacity

Jun 13 20:15:11 Xserve kernel: ata1: hard resetting link

 

It seems to be making the size change on a non-permanent basis, otherwise, when you boot up next time it would be gone.

 

I'd try issuing

hdparm -N p2930277168 /dev/sda

and see if you can get rid of the HPA permanently.  Clearly this is one case where the partition was created using the full size of the drive and the HPA clobbered the tail end of it.  (in other words, your BIOS might be still trying to create and store an image of itself there since the odds are the partition was created in unRAID when it saw originally the full size of the drive)

 

I guess what I'm trying to say is, double check your MB BIOS.  It might be still trying to create an HPA.  You might need to update it.

 

Joe L.

[muzo178]

i had actually issued

 

hdparm -N p2930277168 /dev/sda

 

when i first brought this drive in from an HTPC with a Gigabyte board after seeing the HPA issue in the logs.

 

I'd try issuing it again, but would issuing the command again invalidate my array in any way? Just wanna be sure, cause if it will; then I think I'd be better off swapping this drive with a 2TB green and then try and sort this issue out.

 

The ECS board I am using does not have a BIOS function that would create HPA. I am quite positive that it is coming from the older Gigabyte board.

[muzo178]

issuing hdparm -N p2930277168 /dev/sda solved the issue. i tried rebooting a couple times and no HPA warnings in the syslog.

 

Thanks for the help Joe.

[SSD]

This is a scary issue. Can't believe BIOS would insert a HPA when partition table indicates the entire disk is partitioned.