How will I know if SASLP-MV8 will work in my 16x slot ?

I'm looking to buy the Supermicro AOC-SASLP-MV8 card to use in my Gigabyte P35-DS3R mainboard. This motherboard is a basic Intel P35 chipset motherboard with a single 16x slot and 3 small 1x slots.

I heard something about certain motherboards only supporting graphics cards in their 16x slot - how will I know if this is the case with my motherboard? Google comes up pretty empty.

I do have a Silicon Image 2-port PCI-E 1x card I can test with - if that works in the 16x slot, is that an indication that the 4x Supermicro card will work ?

I'm looking to buy the Supermicro AOC-SASLP-MV8 card to use in my Gigabyte P35-DS3R mainboard. This motherboard is a basic Intel P35 chipset motherboard with a single 16x slot and 3 small 1x slots.

 

I heard something about certain motherboards only supporting graphics cards in their 16x slot - how will I know if this is the case with my motherboard? Google comes up pretty empty.

 

I do have a Silicon Image 2-port PCI-E 1x card I can test with - if that works in the 16x slot, is that an indication that the 4x Supermicro card will work ?

Yes.  The motherboards that support only video in the x16 slots are few and far between at this point.  If you can get your x1 card working there, I'd say your chances of success with the SASLP are excellent.

I had the same question about using an AOC-USAS2-L8i in my Intel DH55TC.  I couldn't get an authoritative answer from anywhere I tried, including the Intel support board.  In the end I inferred that it will be okay, by piecing together information found in the BIOS changelog.

My AOC is now on order (while I was trying to get full info from the local retailer, the main distributor went out of stock - so my delivery time has gone from 3 days to 3 weeks!   - still, it could be worse, the Adaptec retailer was quoting 30 - 45 days! )

Unfortunately there's no way to know for sure without just testing it.  You can contact Gigabyte tech support and ask them, but even the manufacturers have gotten it wrong in the past.

As bjp said, if any non-video card works in the slot, then chances are the SASLP card will too.  You can also check your BIOS for any settings related to PEG mode and see if they can be disabled.  PEG mode reserves the PCIe x16 slot for video cards only.  If your BIOS has no settings related to PEG, then that's a good sign too.

So, here's what Gigabyte support had to say on the matter.

I guess there is still a chance it could work, but they definitly don't want the blame if it doesn't...

 

Answer - 1077616

Answer : Dear cusotmer,

 

Understand, but PCIEx16 slot on P35-DS3R board was desinged reserved for graphic card only. PCIEx4 or X4 card may not boot able from the PCIE x16 slot.

 

Best regards,

 

Gigabyte technical support team.

Question - 1077616

From : Morten Schmidt [ [email protected] ]

Sent : 4/30/2011 08:44

Question : I am not using a PCI-E graphics card - I use a PCI graphics card.

 

In this case, will a PCI-E 4x SATA controller card work in the 16x slot ?

 

How about a PCI-E 1X SATA controller card in the 16X slot (for using a total of 4 1X SATA controller cards) ?

Answer - 1077565

Answer : Dear customer,

 

Sorry not. P35-DS3R only has single PCIE x16 slot which was designed for graphic card.

 

Best regards,

 

Gigabyte technical support team.

Question - 1077565

From : Morten Schmidt [ [email protected] ]

Sent : 4/30/2011 05:25

Question : Does this motherboard support PCI-E 4x SATA controller cards in the 16x slot ?

 

Or does the 16x slot only support graphics cards ?

 

 

-------------------------------------------------------------------------------

Model Name : GA-P35-DS3R(rev. 2.1)

--------------------------

M/B Rev : 2.1

BIOS Ver : F13

Serial No. :

Purchase Dealer :

-------------------------------------------------------------------------------

VGA Brand : Creative      Model : GF MX PCI

CPU Brand : Intel      Model : E4500      Speed :

Operation System : Linux      SP :

Memory Brand : Kingston      Type : DDRII

Memory Size : 4GB      Speed : 667

Power Supply : 550 W

 

 

Slackware based Linux (UnRaid).

Perhaps some hope - their last statement only says that it may not be bootable, but does that mean that the card may not start up, or that the attached drives may not boot?

I reached the conclusion that any card should work in the x16 slot on my mobo from these entries in the BIOS changelog:

o Fixed issue where no video is displayed if both PCI and PCI-e VGA cards are attached and primary video output is set to integrated graphics.
o Fixed an issue where some PCI-e x1 cards would not work when plugged into the PCI-e x16 slot.

This suggests that:

1) The integrated graphics should still work, even if the x16 slot is populated

2) Any type of card should work in x16 slot (I'm not aware of any x1 graphics cards)

The only thing that's not clear from these comments is whether the x16 slot will only work with (non-graphics) x1, or whether it will also work with x4, x8 and x16.  I believe that some x16 slots are limited to x8, or less, with non-graphics cards - not a problem since I don't know of any HBAs which are more than x8.

I could only find BIOS changelog back to the last 3 versions, and no hints there for me.

But today I've tried to move my SIL3132 card to the 16X slot, and the server boots, the harddrives are recognized. So I was enthusiastic.

However, when running a no-correct parity check, it finds 2 sync errors right at the beginning (as in immediatly when the check is started). I canceled and tried 3 times, it finds those two errors the same places each time. The 2.nd time I let it complete 10% and it did not find any more errors. I am attaching a Syslog in hope that someone can help me figure out what is going on here. I also ran SMART checks and see no reallocated or pending sectors on any of my drives.

EDIT: I put the SIL3132 card back in it's original slot and rebooted - still find those 2 sync errors in the same locations as before. This is frustrating - I nave never had any of these before, ever. Could it have anything to do with a disk upgrade I did last week? I replaces a 1TB drive with a twice-precleared 2TB drive. The operation seened to have been successful, although I have not done another parity check after that operation until today after mettling with the hardware.

syslog-2011-05-06_2_Sync_Errors_at_same_locations_3_times_in_a_row.txt

Could it have anything to do with a disk upgrade I did last week? I replaces a 1TB drive with a twice-precleared 2TB drive. The operation seened to have been successful, although I have not done another parity check after that operation until today after mettling with the hardware.

This seems very likely to be the issue.  ALWAYS run a parity check after any sort of parity operation (rebuild from parity, parity sync, etc.).  The rebuilt from parity reads all the drives and writes to the new 2 TB drive.  It never attempted to read from the new 2 TB drive.  That's why a parity check is so crucial, it reads from all drives.

Still, the situation isn't dire.  2 parity errors is far from being the end of the world.  There's a few ways to tackle this.  First, do you happen to have a backup of your config file from before replacing the 1 TB drive?  If so, you could just revert to that backup, put the 1 TB drive back in, and you should have a healthy array again.  Run a parity check.  Now replace the 1 TB with the 2 TB and let the data rebuild complete.  Now run another parity check.  There should be no errors.

If you aren't able to do that, then your best bet is probably to just run a few parity checks in a row with the new 2 TB drive in place (let them complete, don't cancel them).  The parity errors will likely be gone by the 2nd or 3rd check.

Unfortunately I didn't see anything in your syslog that would tell us why you had any parity errors, but maybe someone with more syslog experience can take a look and offer their advice.

Thanks for having a look.

Having had a bit more time to think this over, also after reading Your advice, I guess I can consider the 2 errors to be on one of the drives in my array, but by the sound of your message, they are most likely caused by the disk restore operation, and as such are errors on the recently-rebuild disk (and not any of the other data drives or parity). I was definitely not aware that the disk restore process does not verify writes - the fact that unRaid does verify all writes to the protected array is what pulled me towards unRaid in the first place. So 'll be sure to always do a parity check afterwards (a no-correct one, just to check). As a side note, is there a good reason writes are not verified during disk rebuild? Is this something that has been or should be brought up as a feature or enhancement request with LimeTech?

My status now is that I still have only run no-correct parity checks, one has completed and errors are still in the 2 same locations only.

I can't do as You propose because I have used the array, transferred lots of data to the new drive, stuff that's been moved from other drives in the array. But I think if I simply pull the new 2TB drive and rebuild it onto another new 2TB drive that I have (my spare, also twice pre-cleared standby disk), I will achieve the same end result. If I understand everything right, that will be like saying "I trust all the other datadisks and my parity to be correct, and believe the source of the parity errors were on the recently-rebuild data disk. Please rebuild that datadisk for me again (and without the errors please)".

My other option would be to sync the parity, accepting the 2 errors, and then trying to figure out which files occupied the 2 affected sectors on the disk, and recover them from the 1TB drive I removed from the array. With this method, if I had the skills to identify which files occupy these sectors, that would allow me to do a crc check and confirm whether the problem was in fact with the data on the recently-rebuild datadisk. But on balance, just rebuilding again onto a fresh disk does seem more straight forward. Am I on the right track?

The most common reason for parity errors is an unclean server shutdown, such as a power failure.  Did you have one recently?

The early part of an RFS formatted disk is the "housekeeping" area and not assigned to data files.  This housekeeping area is very frequently written.

The RFS file system is maintained by the Linux OS, not unRAID, and has been designed to withstand power failures without data loss.  The chances that one of your data disks has been corrupted is extremely small.  When it does happen, the reiserfsck program is quite good at fixing the problem.

unRAID's parity disk is NOT maintained by the OS. In fact is has no filesystem at all - just a raw partition where it unRAID maintains parity data.  The parity disk is extremely easy to "corrupt" with a power failure.  (In this context, "corrupt" means that some parity data intended to be written to the disk, could have been buffered and never actually gotten to the disk.  Parity writes can stay buffered for a very long time - days, weeks, months, years - even with no new writes to the array.).  It would be quite rare to have a hard shutdown without "corrupting" parity.  Parity has no "fsck" type program to repair it - only the beloved parity check .

These two facts make unRAID's parity disk the prime suspect when there are parity errors.  And a correcting parity check will update parity based on the data on the data disks.  That's exactly what you want 99% of the time.  The only times you might not want to do this is if you are having inconsistant parity check results, or if suddenly a large number of unexplained parity errors showed up that might be a failing disk.  Again, these are very rare situations, and not what is happening in your case.

I would recommend running a correcting parity check and be done with it.  Afterwards, run another non-correcting check.  All should be clean.  Monthly parity checks are recommended, but if you are nervous, you might want to run weekly checks for the next month and see if any parity checks are creeping into your system.  If they are, you will have some investigating to do.  But my suspicion is you'll have no further trouble unless/until you have a power failure on the array.

Sound advice.  In my post above I forgot to specify that you should run the default correcting parity checks, not the no-correct ones through unMenu.

I run on UPS, and there has not been a powerfailure, crash or any form of sudden shutdown. When powering down I kill all my apps that run on the protected array (Sabnzbd, Transmission and Twonkyserver), stop the array and power down cleanly. Every single time since I brought the server into 'production' 9 or 10 months ago.

I really appreciate You guys taking the time to look at my problem and giving me Your advice, but hoping for a wider audience, I have started a thread in the General Support area.

http://lime-technology.com/forum/index.php?topic=12884.0

Since You two have already read the info in this thread, here is the short version of what has happened since:

I have rebuild the data disk in question again, onto a fresh precleared disk, and after the rebuild I am now getting 5 parity errors in the first 0.1% of the parity check and nothing after that. Like after the first rebuild, the 5 new parity errors are persistently in the same locations with each parity check. In the new thread is a new syslog containing the clean disk rebuild and subsequent parity errors.

I hope You don't feel this is cross-posting, and hope You will provide more of Your valuable insight over in the support thread. Thanks!

Closing this off - the rebuild corruptions I encountered (manifesting as parity errors in subsequent parity checks) disapeared after upgrading from 4.6 to 4.7 and I have tried a number of times to reproduce without encountering the issue again, including trying a 4.6 bare bones configuration (stripped go file). So, it apears to have been a particular combination of 4.6 and the addons I'm running and/or performance tuning tweaks. Or some obscure memory error that I haven't been able to identify yet.

Nevertheless, back to the original topic. Obviously, Gigabyte's support was of no help, but based on the research I did I found nothing to indicate that anything would allow a 1X controller to work but not a 4X controller, so since my SIL3132 card did work in the 16X slot, I went ahead and ordered the SASLP-MV8 card. And it seems to work just fine - I've connected a single array disk to the card along with 4 non-array disks. I've run several parity checks with no errors, including one simultaneously with preclearing 3 of the non-array disks and running a hashdeep audit on the 4'th non-array disk, all with no hickups.

To anyone wanting to know if a 4X Controller card will work in their 16X slot: If a 1X controller card works in a 16X slot then mostlikely so will a 4X card. The issues surrounding 16X slots is that some are PEG-only, meaning "PCI Express Graphics Only", and obviously if a 1X SATA controller card works in your 16X slot, it is not PEG-Only. If anyone does have different experience, please speak up 

Since I posted in this thread, saying that I had had a similar question about my system, I guess that I ought to confirm that, likewise, my x8 AOC-USAS2-L8i card is working perfectly in my x16 'graphics card' slot.

i put since than one of my x1 cards in my PCI x 16 slot without any issues

waiting now for my BR10i to arrive to see how that will work out