GIGABYTE GA-MA74GM-S2 - Thumbs up

[razmajazz]

Forgot about that. Yes, it's a self extracting zip so run on a Windows machine and put the extracted BIOS image on the USB stick, not the exe.

[spinbot]

Looks good, so far.

 

I've got the new firmware installed and I *think* I got all my setting back into the Bios that weren't defaults.

 

I did see something like "save copy of Bios to hard drive" option and it is DISABLED ( this must be the layman's for HPA )

 

I can see all my drives in UnRaid after booting it up.

 

My next task is to reset the sector size of one of the HPA "infected" data drives

 

I've got a similar posting in a different thread

( http://lime-technology.com/forum/index.php?topic=6759.0 )

 

I've run the following command, to find the sector size, however it comes back with two numbers.

 

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

 

/dev/sda:

max sectors  = 18446744072344859375/2930277168, HPA setting seems invalid

 

root@Tower:~# hdparm -N /dev/sdf

/dev/sdf:

max sectors  = 18446744072344859375/2930277168, HPA setting seems invalid

 

 

Which one would it be:

18446744072344859375

OR

2930277168

[Joe L.]

Which one would it be:

18446744072344859375

OR

2930277168

The second (in blue)

[Chris Pollard]

Finally got around to upgrading my rev 2.0 board to FC.  Looking good.  Save BIOS feature is disabled by default.

[spinbot]

I ran the command:

 

root@Tower:~# hdparm -N p2930277168 /dev/sda

 

And instantly got this response:

 

/dev/sda:

setting max visible sectors to 2930277168 (permanent)

Use of -Nnnnnn is VERY DANGEROUS.

You have requested reducing the apparent size of the drive.

This is a BAD idea, and can easily destroy all of the drive's contents.

Please supply the --yes-i-know-what-i-am-doing flag if you really want this.

Program aborted.

root@Tower:~#

 

I'm guessing it didn't do what I wanted it to do as although it ask for the "Yes I know what I am doing" flag, I didn't have a chance to enter it.

 

Do I have something wrong in the command I initially entered ( extra space or something ) ?

[Joe L.]

I ran the command:

 

root@Tower:~# hdparm -N p2930277168 /dev/sda

 

And instantly got this response:

 

/dev/sda:

setting max visible sectors to 2930277168 (permanent)

Use of -Nnnnnn is VERY DANGEROUS.

You have requested reducing the apparent size of the drive.

This is a BAD idea, and can easily destroy all of the drive's contents.

Please supply the --yes-i-know-what-i-am-doing flag if you really want this.

Program aborted.

root@Tower:~#

 

I'm guessing it didn't do what I wanted it to do as although it ask for the "Yes I know what I am doing" flag, I didn't have a chance to enter it.

 

Do I have something wrong in the command I initially entered ( extra space or something ) ?

If you know that is the correct number of sectors, then it is just protecting you from the fact that it thinks the huge number it is currently reading incorrectly as sectors is larger than the number you provided.

Take a look in your syslog for lines like these:

Jul 17 15:20:10 AVFILES kernel: ata7.00: HPA detected: current 1953523055, native 1953525168

Jul 17 15:20:10 AVFILES kernel: ata7.00: ATA-8: ST31000340AS, SD15, max UDMA/133

Jul 17 15:20:10 AVFILES kernel: ata7.00: 1953523055 sectors, multi 0: LBA48 NCQ (depth 31/32)

 

If the current does not end in 168, and looks just 1056 shorter than the native value, then it is a valid "native" value, and a HPA that can be removed.

 

However, it the  "native value" looks really huge,as in the following disk, it is being mis-interperted by the kernel, and is not to be used to set the HPA.

Also, since the "current value" does end in 168, there is no HPA added by the Gigabyte BIOS.

Jul 17 15:20:10 AVFILES kernel: ata7.00: configured for UDMA/133

Jul 17 15:20:10 AVFILES kernel: ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Jul 17 15:20:10 AVFILES kernel: ata8.00: HPA detected: current 3907029168, native 18446744073321613488

Jul 17 15:20:10 AVFILES kernel: ata8.00: ATA-8: WDC WD20EADS-00R6B0, 01.00A01, max UDMA/133

Jul 17 15:20:10 AVFILES kernel: ata8.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32)

 

If the "current value" ends in something other than 168, you can usually get the correct "native" value by adding 1056.  That is the number you need to use with the "-N" option to hdparm.

 

Of course, you can use any of the other utilities available to reset the HPA if the "hdparm -N pXXXXXXXXXXX" does not do it for you.

 

Joe L.

[spinbot]

I don't see "AVFILES kernel" in my syslog at all.

 

Attached a copy for you.

 

Thanks for the assistance.

 

( I've presently sitting with the UnRaid array as "Stopped", logged into telnet as I was doing the hdparm command, in case that explains why my syslog doesn't show the above info )

syslog-2010-07-19.txt

[Joe L.]

I don't see "AVFILES kernel" in my syslog at all.

 

Attached a copy for you.

 

Thanks for the assistance.

 

( I've presently sitting with the UnRaid array as "Stopped", logged into telnet as I was doing the hdparm command, in case that explains why my syslog doesn't show the above info )

You would not unless you named your server "AVFILES"

 

You would see a line with your server name.

[spinbot]

hahaha .....  as you can see my understanding of the syslog is limited to what you tell me

 

I will look for something similar to what you posted ( I never changed my server name from 'Tower' )

 

The hundreds of lines starting "Tower Kernel" should have given this away

[spinbot]

OK... so here are the lines that you were referring to:

 

Jul 18 09:04:37 Tower kernel: ata3.00: HPA detected: current 1465147055, native 1465149168

Jul 18 09:04:37 Tower kernel: ata3.00: ATA-7: ST3750330AS, SD04, max UDMA/133

Jul 18 09:04:37 Tower kernel: ata3.00: 1465147055 sectors, multi 16: LBA48 NCQ (depth 31/32)

 

Jul 18 09:04:37 Tower kernel: ata1.00: HPA detected: current 2930275055, native 2930277168

Jul 18 09:04:37 Tower kernel: ata1.00: ATA-8: ST31500341AS, CC1H, max UDMA/133

Jul 18 09:04:37 Tower kernel: ata1.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 31/32)

 

Jul 18 09:04:37 Tower kernel: ata6.00: HPA detected: current 2930275055, native 2930277168

Jul 18 09:04:37 Tower kernel: ata6.00: ATA-8: ST31500341AS, CC1G, max UDMA/133

Jul 18 09:04:37 Tower kernel: ata6.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 31/32)

 

These are the only 3 entries that have "HPA Detected"

 

If you look at the image below, I can tell the first item above corresponds to Disk 3 ( the 750GB drive ).

 

The other two items "ata1" and "ata6" , have to be Disk 2 and Disk 5 (not sure which is which, not sure it matters either.  I just assume these are the two drives because you can see their size is slight smaller than the parity drive , which is the same model of drive ).

 

So, the difference between the current and native values is 2113 for all 3 drives ( which is 1056.5 X 2 )

You suggested "If the current does not end in 168, and looks just 1056 shorter than the native value, then it is a valid "native" value, and a HPA that can be removed."  The example you showed was also showing a difference of 2113.   

 

So, here are the 3 commands I come up with, noticing that the current+1056 < native

 

1465147055+1056

hdparm -N p1465148111 /dev/sdc

 

2930275055+1056

hdparm -N p2930276111 /dev/sda

 

2930275055+1056

hdparm -N p2930276111 /dev/sdf

 

How's things look? 

 

[Joe L.]

OK... so here are the lines that you were referring to:

 

Jul 18 09:04:37 Tower kernel: ata3.00: HPA detected: current 1465147055, native 1465149168

Jul 18 09:04:37 Tower kernel: ata3.00: ATA-7: ST3750330AS, SD04, max UDMA/133

Jul 18 09:04:37 Tower kernel: ata3.00: 1465147055 sectors, multi 16: LBA48 NCQ (depth 31/32)

 

Jul 18 09:04:37 Tower kernel: ata1.00: HPA detected: current 2930275055, native 2930277168

Jul 18 09:04:37 Tower kernel: ata1.00: ATA-8: ST31500341AS, CC1H, max UDMA/133

Jul 18 09:04:37 Tower kernel: ata1.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 31/32)

 

Jul 18 09:04:37 Tower kernel: ata6.00: HPA detected: current 2930275055, native 2930277168

Jul 18 09:04:37 Tower kernel: ata6.00: ATA-8: ST31500341AS, CC1G, max UDMA/133

Jul 18 09:04:37 Tower kernel: ata6.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 31/32)

 

These are the only 3 entries that have "HPA Detected"

 

If you look at the image below, I can tell the first item above corresponds to Disk 3 ( the 750GB drive ).

 

The other two items "ata1" and "ata6" , have to be Disk 2 and Disk 5 (not sure which is which, not sure it matters either.  I just assume these are the two drives because you can see their size is slight smaller than the parity drive , which is the same model of drive ).

 

So, the difference between the current and native values is 2113 for all 3 drives ( which is 1056.5 X 2 )

You suggested "If the current does not end in 168, and looks just 1056 shorter than the native value, then it is a valid "native" value, and a HPA that can be removed."  The example you showed was also showing a difference of 2113.     

 

So, here are the 3 commands I come up with, noticing that the current+1056 < native

 

1465147055+1056

hdparm -N p1465148111 /dev/sdc

 

2930275055+1056

hdparm -N p2930276111 /dev/sda

 

2930275055+1056

hdparm -N p2930276111 /dev/sdf

 

How's things look? 

 

Before you do anything,,, ONLY DO THIS ON ONE DRIVE AT A TIME WITH THE ARRAY STOPPED.  IT WILL CAUSE UNRAID TO THINK YOU REPLACED THE DRIVE AND IT WILL WANT TO RE-CONSTUCT IT.    If you do it on two drives at the same time it will not be able to reconstruct anything.

 

I would use the "native" value exactly as specified in the syslog for each disk.  "hdparm" should also show that same value as the "native" if you type:

hdparm -N /dev/sdc

hdparm -N /dev/sda

hdparm -N /dev/sdf

 

The commands would then be:

 

hdparm -N p1465149168 /dev/sdc

hdparm -N p2930277168 /dev/sda

hdparm -N p2930277168 /dev/sdf

 

 

 

[spinbot]

I definitely understand the only doing one drive at a time!

 

The problem now is that I am basically back to where I was on post #79 where I said:

 

I ran the command:

 

root@Tower:~# hdparm -N p2930277168 /dev/sda

 

And instantly got this response:

 

/dev/sda:

setting max visible sectors to 2930277168 (permanent)

Use of -Nnnnnn is VERY DANGEROUS.

You have requested reducing the apparent size of the drive.

This is a BAD idea, and can easily destroy all of the drive's contents.

Please supply the --yes-i-know-what-i-am-doing flag if you really want this.

Program aborted.

root@Tower:~#

 

Reboot and try again?

[spinbot]

Interesting humour of the programmers to make us type "-yes-i-know-what-i-am-doing"

 

Going to start the process now.  If all goes well, 3 - 4 days later I should have an array without HPA on any of the 3 drives it sneaked its way on to!

 

I did run the command:

root@Tower:~# hdparm  --yes-i-know-what-i-am-doing  -N p2930277168  /dev/sda

 

and got the response:

 

/dev/sda:

setting max visible sectors to 2930277168 (permanent)

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

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

 

I hate when it gives me warnings like "HPA setting seems invalid" as I start second guessing myself.

 

[glow=red,2,300]I should just disregard this warning -- Right?[/glow]

 

And then, as Joe L. likes to make us 100% clear on:

Click on "Start" to begin the re-construction.

[Joe L.]

Interesting humour of the programmers to make us type "-yes-i-know-what-i-am-doing"

Yes, and we all feel really dumb typing that when we are not sure....

 

The complication is that hdparm is incorrectly reporting the size as 18446744072344861488, so it thinks it is invalid.

[spinbot]

It appears I must have done something incorrectly as the drive did not come up as "invalid" or "new" or however it should have reported it because of the change in size.

 

After running hdparm commend and getting the associated response:

 

root@Tower:~# hdparm  --yes-i-know-what-i-am-doing  -N p2930277168  /dev/sda

 

/dev/sda:

setting max visible sectors to 2930277168 (permanent)

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

 

I then started up my array.  The first time I fired it up, for some odd reason only one of the 6 drives mounted.  I stopped the array and re-started it again, however this time everything came back up , yet my Disk2 (sda) did not report as new.

 

Syslog attached.

 

I do recall reading something like you can only make one hdparm change per session, so I may have to reboot the server after completing each of the 3 drives in need of repair.  Might that be my only problem right now ( although I haven't completed the first drive ) ?

 

On a side note, my server was having trouble keeping track of time pretty much since I got it, however I believe since I did the firmware upgrade, it has somehow fixed itself

syslog-2010-07-20.txt

[spinbot]

OK... so I must completely shutdown between drives that I "repair", however as for my current issue (ie. I've run the hdpram command, restarted the array yet it loaded fine, not identifying the drive as new/different size), do I need to shutdown and start up again to get the array to recognize the hpa removed from it?

 

I realize I could just try it, however I don't want to make matters worse, so I am deferring to the experts

[Joe L.]

OK... so I must completely shutdown between drives that I "repair", however as for my current issue (ie. I've run the hdpram command, restarted the array yet it loaded fine, not identifying the drive as new/different size), do I need to shutdown and start up again to get the array to recognize the hpa removed from it?

 

I realize I could just try it, however I don't want to make matters worse, so I am deferring to the experts

All I know is what I've read.  I've never typed the "hdparm -N" command you are describing, never owned a Gigabyte motherboard, and likely never will.

 

If the hdparm command you are trying does not work, then you'll be forced to use one of the other utilities mentioned in the wiki to reset the HPA. 

 

With that in mind, I'd power cycle, run the command, and see if the size was reset.  The "danger" it describes is if you artificially shorten a drive to where the existing file-system cannot fully be accessed.  Making the drive its full native size is not as risky.

 

Joe L.

[spinbot]

Doing a cold boot after running the hdparm  --yes-i-know-what-i-am-doing  -N p2930277168  /dev/sda was the next step I needed!

 

Once I booted back up, my "sda" drive came up with a blue bullet beside it.  I was then able to start the array and rebuild the data on the drive its treating as "new".

 

It's going to take 8 hours to re-build, so I will know at that time if the process worked!   If so, only 2 more drive to complete this on.

 

Hopefully adding my 8 port controller on this motherboard doesn't give me any grief as I've had enough of it for a while!

 

EDIT:  I've removed the HPA on 2 of my 3 drives that were "infected".  It would be more reassuring if I got a response for all the drives as "HPA is Disabled".  You can see sda, sdb, sde and sdf have all the same numbers.  I removed the HPA from sda and sdf only.  So.... it looks good.  I just have to remove it from sdc and then I am back to where everyone else without a Gigabyte motherboard is ( sigh ) 

 

 

 

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

 

/dev/sda:

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

root@Tower:~# hdparm -N /dev/sdb

 

/dev/sdb:

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

root@Tower:~# hdparm -N /dev/sdc

 

/dev/sdc:

max sectors  = 1465147055/1465149168, HPA is enabled

root@Tower:~# hdparm -N /dev/sdd

 

/dev/sdd:

max sectors  = 1953525168/1953525168, HPA is disabled

root@Tower:~# hdparm -N /dev/sde

 

/dev/sde:

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

root@Tower:~# hdparm -N /dev/sdf

 

/dev/sdf:

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

[spinbot]

I've removed the HPA from the first two drives without any errors, however the 3rd drive presented me with:

 

disk3   ata-ST3750330AS_5QK00GT5   *   732,574,552   44,378,984   56   1,829,554   288

 

 

Where 288 represents the "Errors".

 

It appears to be as a results of overheating:

 

Jul 22 21:58:02 Tower emhttp: disk_temperature: ioctl (smart_enable): Input/output error

Jul 22 21:59:56 Tower emhttp: disk_temperature: ioctl (smart_enable): Input/output error

 

At the moment, the drive is disabled by UnRaid.

 

Would you recommend I just do a parity check and let it repair the drive ?   I can stick an external fan in front of the case to cool it more ( plus the ambient temp. is much cooler now ).

 

[Joe L.]

I've removed the HPA from the first two drives without any errors, however the 3rd drive presented me with:

 

disk3   ata-ST3750330AS_5QK00GT5   *   732,574,552   44,378,984   56   1,829,554   288

 

 

Where 288 represents the "Errors".

 

It appears to be as a results of overheating:

 

Jul 22 21:58:02 Tower emhttp: disk_temperature: ioctl (smart_enable): Input/output error

Jul 22 21:59:56 Tower emhttp: disk_temperature: ioctl (smart_enable): Input/output error

 

At the moment, the drive is disabled by UnRaid.

 

Suggestions?   Can I wipe the drive out and try writing to it again from the parity drive, however this time I can stick an external fan in front of the case to cool it more ( plus the ambient temp. is cooler over night ).

 

Those are "read" errors, although to have had the drive disabled, it must also have had a "write" failure.

The errors you see referring to temperature are not an indication of high temps, but the inability to have the disk respond to a request to read its temperature.  it probably is not responding to anything.

 

Can you get a SMART report on the drive?

smartctl -d ata -a /dev/sdX

where sdX = the proper device for your disk.

 

To get the disk to be rebuilt, you need to

1. stop the array

2. un-assign the drive

3. start the array with it un-assigned

4. stop the array once more

5. re-assign the drive

6. Start the array once more by pressing "Start" (at this point the re-construction will begin)

 

Joe L.

[spinbot]

This is all I get ( note I haven't done anything since I got the errors ):

 

root@Tower:~# smartctl -d ata -a /dev/sdc

smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Alle

n

Home page is http://smartmontools.sourceforge.net/

 

Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)

 

A mandatory SMART command failed: exiting. To continue, add one or more '-T perm

issive' options.

 

 

Lots of red lines in the syslog.

syslog-2010-07-22.txt

[Joe L.]

This is all I get ( note I haven't done anything since I got the errors ):

 

root@Tower:~# smartctl -d ata -a /dev/sdc

smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Alle

n

Home page is http://smartmontools.sourceforge.net/

 

Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)

 

A mandatory SMART command failed: exiting. To continue, add one or more '-T perm

issive' options.

 

 

Lots of red lines in the syslog.

As I figured... The drive is not responding at all.  It might start responding after a power cycle, or after it cools down (if it really got that hot) or, it might just have died for good.

 

Joe L.

[spinbot]

I wasn't able to remove and re-add the drive at first, however once I rebooted the computer, it picked it up as a new drive.

 

I am now presented with the option to Refresh or Start - Start will bring the array on-line, start Data-Rebuild, and then expand the file system (if possible).

 

I have to check the "Im sure I want to do this" to get "Start" to work.

[Joe L.]

I wasn't able to remove and re-add the drive at first, however once I rebooted the computer, it picked it up as a new drive.

 

I am now presented with the option to Refresh or Start - Start will bring the array on-line, start Data-Rebuild, and then expand the file system (if possible).

 

I have to check the "Im sure I want to do this" to get "Start" to work.

That is the choice you want.  Check the 'I'm sure" adjacent to "Start" and press "Start"

 

The questions is... did the drive come back as full size?

[spinbot]

Success!  ( I pretty sure.... just would have liked to see all my 1.5TB drives have numbers the same ie. XXXXXX/XXXXXX )

 

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

 

/dev/sda:

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

root@Tower:~# hdparm -N /dev/sdb

 

/dev/sdb:

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

root@Tower:~# hdparm -N /dev/sdc

 

/dev/sdc:

max sectors  = 1465149168/1465149168, HPA is disabled

root@Tower:~# hdparm -N /dev/sdd

 

/dev/sdd:

max sectors  = 1953525168/1953525168, HPA is disabled

root@Tower:~# hdparm -N /dev/sde

 

/dev/sde:

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid

root@Tower:~# hdparm -N /dev/sdf

 

/dev/sdf:

max sectors  = 18446744072344861488/2930277168, HPA setting seems invalid