Gigabyte 965P-DS3P used by anyone?

[Talos]

http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=Motherboard&ProductID=2455&ProductName=GA-965P-DS3P

 

I already have this board in my HTPC but am updating the HTPC to something else and am thinking of making an Unraid server with this mobo. I've linked the specification page above which lists most of the componentry. Im basically looking at building a 12 drive array which would reqiure adding in a 1430SA to this mobo in the 2nd 16x/x4 pci-e slot.

 

The only thing I'm worried about on the mobo is the Marvell 8056 LAN adaptor. I dont see many if any setups with this network adaptor used. The rest of the system should work fine i think being standard intel p965 and ICH8R. 

 

I have an opportunity to pick up a P5Q-Deluxe 2nd hand atm but would rather spend that money on a few more drives for the system if I dont need to replace the mobo.

 

If i try the free version of unraid can i test the motherboard without wiping any of the data on the discs already setup in the HTPC just to see if the network port works?

[Joe L.]

If i try the free version of unraid can i test the motherboard without wiping any of the data on the discs already setup in the HTPC just to see if the network port works?

Yup, just don't assign any disks to the array.

[Talos]

ok ive fired up the free version of unraid to see how it all went. Appeared to start all ok and I can view //tower/ from remote computers on my network so it appears that there are no issues with the onboard network not working under unraid. I can view all the hard drives attached to the system so unraid recognises both the ICH8R and the jmicron onboard controllers.

 

All appears ok except I did notice a few errors fly by while it was booting though so i have taken a capture of my syslog hoping someone will know what the issue's are and whether it means they fatally rule out use of the board for unraid or if they are minor ignorable or fixable errors.

 

eg of error the two errors are below so people dont have to search through the whole syslog...

 

Aug 24 08:57:15 Tower kernel: Buffer I/O error on device sdg1, logical block 122096125

Aug 24 08:57:15 Tower kernel: attempt to access beyond end of device

 

and

 

Aug 24 08:57:15 Tower kernel: read_file: error 2 opening /boot/config/super.dat

Aug 24 08:57:15 Tower kernel: md: could not read superblock from /boot/config/super.dat

 

thanks

 

EDIT: also just noticed this in the syslog a bit higher but not reported as an error:

sdg: p1 exceeds device capacity

 

Appears to be talking about one of my 500gb drives, one of which i know is about 600mb away from being completely full. maybe the error is because the drive is too close to being full?

[Joe L.]

ok ive fired up the free version of unraid to see how it all went. Appeared to start all ok and I can view //tower/ from remote computers on my network so it appears that there are no issues with the onboard network not working under unraid. I can view all the hard drives attached to the system so unraid recognises both the ICH8R and the jmicron onboard controllers.

 

All appears ok except I did notice a few errors fly by while it was booting though so i have taken a capture of my syslog hoping someone will know what the issue's are and whether it means they fatally rule out use of the board for unraid or if they are minor ignorable or fixable errors.

 

eg of error the two errors are below so people dont have to search through the whole syslog...

 

Aug 24 08:57:15 Tower kernel: Buffer I/O error on device sdg1, logical block 122096125

Aug 24 08:57:15 Tower kernel: attempt to access beyond end of device

 

and

 

Aug 24 08:57:15 Tower kernel: read_file: error 2 opening /boot/config/super.dat

Aug 24 08:57:15 Tower kernel: md: could not read superblock from /boot/config/super.dat

 

thanks

 

EDIT: also just noticed this in the syslog a bit higher but not reported as an error:

sdg: p1 exceeds device capacity

 

Appears to be talking about one of my 500gb drives, one of which i know is about 600mb away from being completely full. maybe the error is because the drive is too close to being full?

The BIOS on Gigabyte motherboards create a Host-Protected-Area at the end of the first disk they detect where they "think" is un-formatted.

This makes the disk seem smaller than it actually is by a megabyte or so.  The MB puts a copy of the BIOS up there to aid in recovery of the BIOS in a failed BIOS upgrade situation.

 

The first message

sdg: p1 exceeds device capacity

says that the partition 1 size is greater than the size reported by the disk drive. 

 

The series of errors when accessing sdg1 occurred when your server attempted to read those blocks at the end of the disk.  Typically, when the partition size as described in the disk partition table is not correctly sized the chances of a corrupt file-system is higher as the OS will attempt to

 

It does not appear as if you've assigned any of your disks to the array...  That was the reason for the message

Aug 24 08:57:15 Tower kernel: read_file: error 2 opening /boot/config/super.dat

Aug 24 08:57:15 Tower kernel: md: could not read superblock from /boot/config/super.dat

That file is created after you assign disks to the array.

 

 

You can type the following two commands at the linux prompt after logging in as "root" to check on the disk with the oddly configured first partition:

 

hdparm -N /dev/sdg

and

fdisk -l /dev/sdg

 

The errors have nothing to do with the current data on the disks, they only have to do with an apparent error in setting the partition size.  I'd be very careful in filling that disk in the HTPC, as it might try to use the space that is not really available.  It is not an issue for unRAID if you decide to use those same disks... but be aware, you should put one of your "data" disks on the MB on the first SATA port in case it decides to add an HPA on its own... Otherwise, it might do the same to the parity drive, and then it would not be larger than an identical data disk.  Do a search on "HPA" and "Gigabyte" on the forum for more details on this quirk of the Gigabyte BIOS.

[Talos]

Awesome... Thanks for the detailed replies Joe. Guess I can be reasonably confident in the board working for the purposes of Unraid then.

 

I've never heard of the HPA thing on gigabyte motherboards before but that info is very handy to know. I generally run the drives to full before replacing them so I would hate to have run into this before. I will definitely take note of the data disc on port 1 tho. Does this mean I will always get this "error" for the disc on port 1 when booting unraid?

 

Now to just wait for the slipped disc in my back to heal so I can start the build process

[Joe L.]

I will definitely take note of the data disc on port 1 tho. Does this mean I will always get this "error" for the disc on port 1 when booting unraid?

No, as the disk will be re-partitioned to use what it advertises as its size. (if you use that same disk)

 

The issue seems to be discovered when a new "parity" disk is installed, replacing an existing one, and the BIOS decides to add an HPA making it seem smaller than a identically sized data disk. At that point, unRAID will not allow the assignment, as the disk is too small.

 

Recently, we discovered the -N option of hdparm will let you reset the HPA, but nobody has used it, to my knowledge, so far, to un-do what the BIOS on the MB is doing without your knowledge.

 

As I said, do a search on this forum for HPA and Gigabyte and you will see past threads.

 

Joe L.

[RobJ]

Many of the HPA related links have been organized in the UnRAID Topical Index, HPA section.