Problems with Supermicro AOC-SASLP-MV8

[kenoka]

I recently purchased and installed a Supermicro AOC-SASLP-MV8 card, and have had numerous problems since. The card installed fine, and I installed a disk I'd previously pre-cleared. As I started copying data, I began to experience some issues. I checked back, and my copy operation had stalled. I looked at it, and my server had rebooted and was in the midst of a parity check.

 

After a bit of testing, it seems like whenever I do anything with that controller other than reading data, unRAID reboots. I am running memtest right now, with no errors so far, and have tried a different SAS-SATA cable. I have installed another drive to eliminate the first drive as a culprit, and see the same behavior.

 

I'm at a bit of a loss, but I strongly suspect that it's the controller card at fault. I suppose it could also be either the PCI-E slot on my motherboard, or the power supply. I don't think it's the PSU, since I can add and spin up all the disks without issue. It's only on write operations that the system reboots, and IIRC spin up takes more power than writing. I'm not sure how I would go about eliminating the PCI-E slot/motherboard as a culprit.

 

If anyone has any bright ideas, or knows of a resolution, I'd appreciate any help.

I previously posted in the unRAID 4.5 section, but since this seems hardware related, I thought I'd repost here. Original thread is: http://lime-technology.com/forum/index.php?topic=8315.0

[Joe L.]

I recently purchased and installed a Supermicro AOC-SASLP-MV8 card, and have had numerous problems since. The card installed fine, and I installed a disk I'd previously pre-cleared. As I started copying data, I began to experience some issues. I checked back, and my copy operation had stalled. I looked at it, and my server had rebooted and was in the midst of a parity check.

 

After a bit of testing, it seems like whenever I do anything with that controller other than reading data, unRAID reboots. I am running memtest right now, with no errors so far, and have tried a different SAS-SATA cable. I have installed another drive to eliminate the first drive as a culprit, and see the same behavior.

 

I'm at a bit of a loss, but I strongly suspect that it's the controller card at fault. I suppose it could also be either the PCI-E slot on my motherboard, or the power supply. I don't think it's the PSU, since I can add and spin up all the disks without issue. It's only on write operations that the system reboots, and IIRC spin up takes more power than writing. I'm not sure how I would go about eliminating the PCI-E slot/motherboard as a culprit.

 

If anyone has any bright ideas, or knows of a resolution, I'd appreciate any help.

I previously posted in the unRAID 4.5 section, but since this seems hardware related, I thought I'd repost here. Original thread is: http://lime-technology.com/forum/index.php?topic=8315.0

If you have more than one slot on the motherboard try the controller in the other.  It could be an interrupt conflict with the specific slot.

[kenoka]

If you have more than one slot on the motherboard try the controller in the other.  It could be an interrupt conflict with the specific slot.

I only have the single PCI-E x16 slot available. That's why I'm at a loss to test if the slot's the culprit. I guess I could pull the card and install it in another machine, but they run Windows, so I'm not sure how much that would tell me.

[kenoka]

Is there any way to make the syslog persistent? I don't get to see the last messages when the system reboots, so I don't know what's going on there.

[kenoka]

I ran through one full memtest cycle with no errors. I'm bringing the server back online for now, and will let memtest run overnight.

[SSD]

Is there any way to make the syslog persistent? I don't get to see the last messages when the system reboots, so I don't know what's going on there.

 

Wondering if it would be possible to mount a Samba share from your Windows workstation to your unRAID server, and then run a "tail" comand, redirecting the output to a file on the Windows share.  Would that work to get the last few syslog messages before a crash/reboot?

[kenoka]

Memtest ran overnight with no errors. I tried again this morning to copy a couple of files to one of the new drives, and it immediately caused a reboot. Parity check is running now.

[kenoka]

Wondering if it would be possible to mount a Samba share from your Windows workstation to your unRAID server, and then run a "tail" comand, redirecting the output to a file on the Windows share.  Would that work to get the last few syslog messages before a crash/reboot?

 

Hmm, I farted around a bit with the smbclient command, and didn't have any success connecting. I think I need to match up my usernames, either on the unRAID end or Windows end. I'll keep working on it.

[bcbgboy13]

Download one of the "Live CD" Linux flavors, burn it, place the card in your other computer with one or two HD preferably on the two different cables if you have them, change the boot order to CD first, boot the Linux , mount the new HDs and try to copy from and to them.

 

This will give you indication is there something wrong with your existing "Unraid" system.

 

But before doing so you can try one last time - just leave only 4 GB RAM for now and disable anything from the BIOS - serial ports, par. port, audio, firewire, floppy cntrl, IDE cntrl. if you do not have any IDE drives as it looks like you have everything enabled.

 

Good luck

[papnikol]

Is there any way to make the syslog persistent? I don't get to see the last messages when the system reboots, so I don't know what's going on there.

 

i think you can do that by putting the following lines in the go script and reboot:

#move syslog to usb stick

mv -f /boot/syslog.current /boot/syslog.last 2>/dev/null

cat /var/log/syslog > /boot/syslog.current

echo "*.debug  /boot/syslog.current" >> /etc/syslog.conf

/etc/rc.d/rc.syslog restart

 

i dont know exactly what the syntax does, but it creates a backup of syslog on the usb

this shouldnt be normally done because it is not a good idea to use the usb since it has a limit on read/writes. but it is good for debugging.

 

As for your main problem,the rebooting i had the same problem. there might be many reasons and you have to start checking for each one (you already tested memory, must find a way to check the card).

in my case, buying a ups fixed it (it seems the current in my area is not very stable and the ups has filters that fix that) at the beginning but i had the same problem later when i added more disks. this time  it was due to my low wattage Power Supply (to be verified, as i am waiting for the new one i have ordered. What is your power supply (i mean watts, single/multiple rail, amperage)?

(you might want to check the psu subject, http://lime-technology.com/wiki/index.php?title=UnRAID_Topical_Index#Power_supplies , mainly the wiki)

[kenoka]

Hi guys,

 

Thanks for the input.

 

@bcbgboy13: That was on my test plan, and I guess I'll have to follow through with it.

 

@papnikol: My PSU is a Corsair 650TX, which I believe is single rail to the 12V line. I thought about switching SATA power cables, but thought it wouldn't matter since it is single rail. I also do have a UPS: a CyberPower 1500AVR, which should have plenty of current.

 

Edit: I just checked, and the 650TX has 52 amps and 624 W available on the 12V line.

[papnikol]

Well, you are more than ok with the PSU and the UPS specs. you should test the card. It doesn't matter if you try it in a windows machine, if the hardware is faulty, u will see it...

[kenoka]

I'll make an Ubuntu live CD or USB drive and test the card soon.

[terrastrife]

If you are running an intel chipset you may have to increase the nb core voltage to get the PEG slots stable with cards that arent video cards.

[kenoka]

The northbridge is an AMD 780G.

 

For future reference, here is a list of the hardware in my server:

motherboard: Gigabyte GA-MA78GM-S2H rev. 1.0

CPU: AMD Athlon 64 5200+

RAM: Corsair XMS2 DDR2-800 2x2GB

PSU: Corsair 650TX

 

[v0lrath]

I'm having the exact same issue- same Supermicro Card, and also a Gigabyte MoBo. In fact, I've tried it in both the GA-MA74GM-S2 and the GA-MA78GM-S2H (same as OP) and had issues. I had the rebooting issues with the MA78GM, and now with my new MA74GM I can't format any drives attached to the Supermicro controller. I have 4 drives already set up, and when I add the 5th and click "Start will record the new disk information and bring the expanded array on-line...", it just refreshes the page with no changes made.

 

Is anyone else using the Supermicro AOC-SASLP-MV8 succesfully? Is it an unRAID compatibility issues, or maybe a Gigabyte MoBo issue?

 

Oh, and im using 5.0 beta 2. I ahd the same rebooting issues on  4.5.6.

[Rajahal]

Many of us are using the SuperMicro AOC-SASLP-MV8 successfully.  I'm using two of them at the moment (on an Asus board).  I've also used one on a Biostar board.  My guess is an incompatibility with Gigabyte motherboards.  You might want to contact Gigabyte and ask them about it.

 

Also, are you sure you are using the correct SAS cables or SAS to SATA breakout cables?  Past reports of using the wrong cables have noted that the drives simply don't show up (in BIOS or in unRAID), however, maybe there's something about your configurations that is different.

[v0lrath]

I previously used the card with Windows Home Server with the same motherboard and had no issues.

 

My syslog keeps repeating this:

 

Oct 21 14:34:26 Server kernel: ata1: status=0x41 { DriveReady Error }

Oct 21 14:34:26 Server kernel: ata1: error=0x04 { DriveStatusError }

Oct 21 14:34:26 Server kernel: ata1: translated ATA stat/err 0x41/04 to SCSI SK/ASC/ASCQ 0xb/00/00

 

I can see the disk just fine in the BIOS and unRAID, but strangely when I go to unMENU>Disk Management the drive shows up but has no ID info. In the normal unRAID menu I can see the serial number, etc. EDIT: After a reboot I could see it in unMENU, but still had all the same issues.

 

After work tonight I will yank the ASUS board out of my desktop and see if it works. I've spent 2 weeks trying to fix this problem and I would gladly just buy a new board if it would work.

[papnikol]

could there be any problem with the bios settings of your AOC-SASLP-MV8? maybe you should fiddle a bit with them....

[kenoka]

I'm having the exact same issue- same Supermicro Card, and also a Gigabyte MoBo. In fact, I've tried it in both the GA-MA74GM-S2 and the GA-MA78GM-S2H (same as OP) and had issues. I had the rebooting issues with the MA78GM, and now with my new MA74GM I can't format any drives attached to the Supermicro controller. I have 4 drives already set up, and when I add the 5th and click "Start will record the new disk information and bring the expanded array on-line...", it just refreshes the page with no changes made.

 

Is anyone else using the Supermicro AOC-SASLP-MV8 succesfully? Is it an unRAID compatibility issues, or maybe a Gigabyte MoBo issue?

 

Oh, and im using 5.0 beta 2. I ahd the same rebooting issues on  4.5.6.

 

Hmm, a bad card would be bad on both motherboards, right? So no definitive answer there. It does start to point the finger more toward the motherboard though.

 

I've had no issues with drives being seen, or added to the array, or formatted. It's only on writing data to the disk that it fails. I can read information just fine once it's on there.

 

I have requested an RMA from Newegg, and will be trying a replacement card. If that one exhibits the same behavior, then I'll be pretty sure it's the motherboard at fault.

[v0lrath]

Please update this thread with what you find out. I'm going to try fiddling with the BIOS, then installing my ASUS board. If neither of those works, I guess I'll have to replace my card too.

[kenoka]

Will do. I'll be shipping the card back tomorrow, and then hopefully receiving the replacement next week.

 

On a brighter note, I've had to go through and drive reconstruction and it all went very smoothly. As I was testing by adding more data to a drive on the SAS card, the copy failed and I had to restart it. As I did so, I noticed that it was going unusually fast. I went and checked the status of the array, and the disk was disabled due to a write error. I went through the process to replace the disk, with the additional step of moving the disk from the SAS controller to my eSATA port.

 

After that was completed, I also removed the other disk I had put on the SAS controller, and did an "initconfig". Parity rebuilt in about nine hours.

[v0lrath]

I tried it in my ASUS motherboard and had the same problems. In fact, I went into the card's BIOS and when I tried to "verify" the drive, I got an error immediately on both the Gigabyte and the ASUS boards. Looks like maybe we both have bad cards and just happen to have the same motherboard? Or maybe that motherboard kills this card

 

Either way, I'm going to try to RMA it with Supermicro, I've had it for too long to do it with Amazon.

 

On another note, what do errors on the main webGUI page mean? My parity drive has about 36 errors. Does it need replaced?

[kenoka]

Probably not. I got parity errors whenever I tried to write to the drive(s) on the Supermicro card. Most of those were due to forced reboots.

 

I would let it finish its parity check and probably call it good. One good thing is that I've really learned to trust UnRAID's parity and data handling (which of course is the whole point), because there's nothing like seeing it work firsthand.

 

It actually sounds to me like you're having a different issue than I am. My card can see and add cards, but won't write. Your card doesn't even recognize that a drive is present.

 

I would try contacting Amazon anyway. They're generally really good about such things.

[v0lrath]

No, it does recognize the drive. It looks like it can't write OR read though, judging by the way it failed verifying all my disk immediately straight from within the card's BIOS. I RMAd it with Supermicro, we'll see what happens when I get my new card.... and who knows when that will be!

 

Also, the errors aren't parity errors (are they?) They are the errors that show up on the main webGUI page next to Read and Write.