LSI SAS 3444E support on ASRock B75 Pro3

[Whackjack]

I have a couple LSI SAS 3444E HBA cards installed in the two PCI-E x16 slots on my B75 Pro3. However, the BIOS/UEFI doesn't seem to be detecting them. In the UEFI System Browser screen, it shows both of these slots as empty. These cards are PCI-E x8 and more often go by the name IBM 25R8060/8071. Does anyone know if there are known issues with these cards (or any LSI RAID/HBA controllers) on this motherboard?
Here are some specs about the system:
UEFI Version: B75 Pro3 P1.20
Processor: Intel Core i5-3470 @ 3.2 GHz
RAM: 2x2 GB DDR3-1333
OS: Ubuntu Server 12.04 x64

[Whackjack]

I updated to the latest UEFI version of 1.50. After this finished, I saw the option to configure the SAS controller. After enabling it, I now see it in the System Browser and the output of lspci in Linux. Unfortunately, only one of the adapters is being detected currently. I'm not entirely sure if updating to the newest UEFI version helped, but I certainly never saw the configuration options before. If I get the other adapter working, I'll update this thread detailing what I did.

[Whackjack]

Last update for the night:
I have determined that only the SAS card installed in PCIE2 will be detected. I then tested a video card in both of the PCI-E slots and it worked in both of them just fine. I also tested the SAS cards individually to make sure there wasn't some weird compatibility issue, but it is always the PCIE1 slot that fails to detect the card. If anyone has any ideas about why this may be, I'm all ears.
Thanks.
UPDATE:
It appears that PCIE1 is a 3.0 slot, while PCIE2 is a 2.0 slot. This may be the cause of the issue, though I assumed that PCIE 3.0 was backwards compatible. Perhaps the cards themselves dislike that slot for some reason.

[- wardog -]

First up, I do not have this board/controller card combo.

Having said that, I have placed SuperMicro AOC-USASLP-L8i and IBM M1015 ServeRAID(LSI 9220-8i/9240-8i) in slots designated for video cards. I currently have M1015 cards running in my media server and have placed them into 939 boards vid card slots too



Items I don't see you've enumerated upon in previous posts here that might have bearing:
In looking over your manual have you gone into the BIOS's "North Bridge Config" and changed the default for "Primary Graphics Adapter" from PCIe Express to Onboard? Or even change to PCI? That advice is made assuming you're attempting two PCIe x8 cards in the only two PCIe slots the motherboard has. That leaves Onboard or PCI video. Or none for that matter if you've got it setup and running and just Remote Desktop into it via the network.

Also, you might even try changing the "PCIE1 Link Speed" to x8 if allowed.

Or possibly any combination of the above suggestions.

Other items in that BIOS that in browsing the manual that might be of interest are "Intel(R) Rapid Start Technology"(I'd set this to Disabled), "ACPI HPET Table"(Might play tough with this set to the default of Enabled) and "PCI ROM Priority"(Not sure if might cause issue or not on this motherboard, nor what settings are available)



Good luck and keep posting updates.

[- wardog -]

Oh!

PCIe 3.0 and PCIE 2.x(.0/.1) are interchangeable, so I don't see that as one of your hurdles.

[synack]

While PCIe 3 and PCIe 2+1 are "electronically" interchangeable, they are completely different protocol wise. I don't have that motherboard, but check your BIOS to see if you can drop the PCIe3 slot down to 2 manually. I bet the card and chipset are having troubles negotiating to PCIe2.
a quote from wikipedia regarding the PCIe3 changes in protocol:

PCIe 3.0 removes the requirement 2.0 has for 8b/10b encoding, and instead uses a technique called "scrambling" that applies a known binary polynomial to a data stream in a feedback topology.

My guess is that the 2.0 cards don't have a clue how to talk to the chipset and are giving up and/or crashing. In motherboards that have the ability to manually "downgrade" the slot, things work fine.
As I'm not an electronics engineer and do not fully understand the specs and protocols of each, I can't say for sure if that's a motherboard fault or card fault... but the result of downgrading the slot manually instead of letting the system auto detect has worked around the issue in numerous cases.


Syn

[Whackjack]

Thanks for the replies. The only options for PCIE1 Link Speed are "Auto" and "Gen1". Changing it from the default of "Auto" to "Gen1" doesn't make a difference. I tweaked a few other things, such as disabling Intel Rapid Start and ACHI HPET. I even cycled through all the graphics adapter settings to no avail. I was unable to find anything named "PCI ROM Priority".
I'm beginning to think that these SAS controllers are just plain incompatible with PCI-E 3.0. Unless a new BIOS firmware drops with improved compatibility or control over PCI-E 3.0, I'll probably just have to buy a different (and much more expensive) controller card.

[- wardog -]

I updated to the latest UEFI version of 1.50. After this finished, I saw the option to configure the SAS controller. After enabling it, I now see it in the System Browser and the output of lspci in Linux. Unfortunately, only one of the adapters is being detected currently. I'm not entirely sure if updating to the newest UEFI version helped, but I certainly never saw the configuration options before.

BIOS 1.30 introduced a fix for "3. Modify Dell Raid card issue.". Not sure whether it might apply here in your instance or not. But if you're comfortable flashing you might revert to 1.30 in case they borked the Dell raid card support in the newer/later BIOS releases that followed after 1.30. Just sayin' is all .................

My guess is that the 2.0 cards don't have a clue how to talk to the chipset and are giving up and/or crashing. In motherboards that have the ability to manually "downgrade" the slot, things work fine.

It's CPU dependent. The OP's Sandy Bridge cpu installed on this board enable PCIe1 to be a 3.0 slot. An Ivy Bridge cpu installed would make/force the PCIe1 slot to be a PCIe 2.x slot

As I'm not an electronics engineer and do not fully understand the specs and protocols of each, I can't say for sure if that's a motherboard fault or card fault... but the result of downgrading the slot manually instead of letting the system auto detect has worked around the issue in numerous cases.

Me neither. Yet it doesn't make sense electrically nor signalling that the PCI Consortium would not allow backward compatibility. Nor would I imagine that motherboard manufacturers would so readily jump on the 3.0 bandwagon were it proven that all their user base 2.x cards were obsoleted by the 3.0 slot inclusion to their motherboards. Also, see above.(ie(cpu dependent whether 3.0 or 2.x)


Whackjack,

More items to try.

"PCI ROM Priority" is located in the Boot section off the main BIOS screen. Though I'm still unsure of what options you're presented to alter.

Insert one of those cards into PCIe1 and connect a hard drive(sata and power) to Port 0(furthest from the PCI mounting bracket, above the LEDs). Boot up, change it to Gen1, reboot, and reply what occurs. You should also try this(HD attached) in "Auto" also. I remember that once I needed to do this for the cards to be functional.

Note: According to the ASRock site and User Manual the PCIe2 slot, although physically an x16 length slot, is actually/electrically an x4 slot. So the card(any card) will be restricted throughput wise by this revelation should you choose to use this slot for an HBA. I'd imagine NON-RAID(pass through) or JBOD(span/concatenation) throughput would not be affected at x4 transfer rates.


Last but least. Whackpack, where in the US you located? I have some of each of the cards and various lengths of the proper SFF cables that I might be persuaded to loan out provided they return back in the condition they left here as. PM me if this might assist. The SM cards appear awkward as they are proprietary SM UIO cards but I have machined some nylon bushings that allow them to be used with non-proprietary PCI mounting brackets.

[- wardog -]

Too, in the Boot menu, adjust the "Setup Prompt Timeout" to three seconds just in case the card and or hard drive might need that extra time to initialize.

Long shot, I know.

[synack]

It's CPU dependent. The OP's Sandy Bridge cpu installed on this board enable PCIe1 to be a 3.0 slot. An Ivy Bridge cpu installed would make/force the PCIe1 slot to be a PCIe 2.x slot

Me neither. Yet it doesn't make sense electrically nor signalling that the PCI Consortium would not allow backward compatibility. Nor would I imagine that motherboard manufacturers would so readily jump on the 3.0 bandwagon were it proven that all their user base 2.x cards were obsoleted by the 3.0 slot inclusion to their motherboards. Also, see above.(ie(cpu dependent whether 3.0 or 2.x)

Kind of... the PCIe3.0 itself IS in the CPU (not Sandy Bridge BTW, but yes partially Sandy Bridge-E, and Ivy Bridge natively) the 2.0 is on the chipset, and they are switched together through the chipset. I wanted to keep the conversation simple... **Sandy Bridge-E does have pcie3 support, however it was not vetted by the PCIe consortium before release, so ymmv. Only Ivy Bridge is currently FULLY pcie3 compliant.

I hope I didn't imply that pcie3 was NOT backward compatible with PCI2 and 1, it most certainly is. pcie2 cannot talk to pcie3 but pcie3 *should* be able to "dumb down" to PCIe2 etc. The card and slot(well SWITCH if you want to get more technical) should auto negotiate to the highest common level.
It seems in real life some pre-pcie3 cards have problems talking to a pcie3 slot. it *should* work, however real life sometimes dictates otherwise.

Syn