Contribute
Register

PCI sata controller SI-PEX40057 working but start up really slow

Status
Not open for further replies.
Joined
May 16, 2012
Messages
53
Motherboard
ASUS X99-S
CPU
i7 5820K
Graphics
2x nvidia GTX1080
Mac
  1. iMac
Mobile Phone
  1. Android
Hi,

i installed a lci card to add 4 sata ports to my mackintosh. I have a SI-PEX40057 card with Marvell 88SE92 Chipset. Over all everything is working. Mavericks recognizes the card and i can install 4 drives and built a raid array with osx.

My problem is that the startup of the computer takes about 3-5 minutes. really much much more time than before. After i switch on the computer the SI-PEX40057 card shows up as a raid card next screen all the connected drives are shown. so far so good. i should press ctrl M to get in the menu of the card. that does not work.

Anyone uses that card and can tell me how to solve that? i don't need the raid boot option. is there a way i can turn that off? may then the start up procedure gets more faster


Thanks for any help
 
Hi i figured out that i bought a worn card. i changed it to the model SI-PEX40064 and startup works as it should. Mavericks recognizes the drives and i can use them as normal. i built a raid10 array with 4 drives connected to this card. sometimes after a while the array disappears . in system information i see the 4 drives as "unknown" connected to a Generic AHCI Controller. After reboot all is normal again.

Can anyone please help? Do i need a special kext?

Thanks
 
arminreiss,

I can't answer your question about a special kext for your disappearing software RAID array issue with your SI-PEX40064 controller card, but I can report the same really slow start up with an SI-PEX40057 in a Mac Pro 4.1 Dual Xeon 2.26GHz. My delay occurs when booting into Win 7 64-bit Ultimate, not OSX 10.8.5. It loads OSX fine: 2 spins, maybe 10-15 sec. - but the boot camp startup shows black screen for 2+ min.; the Marvell BIOS (which ignores Ctrl-M) for an instant; then another 2+ min of blinking cursor before reaching Win 7 login.

My card's packaging indicates that your SI-PEX40064 card uses a different Marvell controller chip (the non-RAID 88SE9215 vs 88SE9230 for the RAID-enabled SI-PEX40057). So it seems there's an issue with BIOS, firmware and/or Boot Loader on the SI-PEX40057 cards, possibly specific to the UEFI boot process. I am communicating with Syba Support about this issue but they seem poorly informed on their own product.

I plan to update the BIOS, Firmware and Boot Loader with the "Firmware pour MV-9230 Version 1043" from this site:

http://www.station-drivers.com/index.php/listes-constructeurs/70-marvell/47-marvell

and will report on that experience. If this update fixes the startup delay and your SI-PEX40064 still gives you trouble, you may be better off applying the fix and going back to using your SI-PEX40057.
 
New approach: Syba Support has responded to my request for an installer that will allow me to re-flash my card with its current firmware with the reply, "Sorry, once you flash the BIOS, nothing we can do. There is no recovery program we can send you."

This naturally makes me leery of leaping into a firmware update - plus, I found I can display the firmware and BIOS versions in firmware update image files like the one at station-drivers by opening them in notepad and searching on text="loader".

Doing this with the firmware update from station-drivers page gave BIOS v.1.0.0.1012 and firmware v.2.3.0.1043 (MSU reports my card was supplied with v.1.0.0.1010 and 2.3.0.1031).

Subsequently I found an updater with BIOS v.1.0.0.1015 and firmware v.2.3.0.1050, at:

http://www.win-raid.com/t7f13-AHCI-amp-RAID-ROM-Modules.html

Scroll down to "C Marvell AHCI/RAID ROM Modules," then "B. Marvell 92xx (SATA3) AHCI/RAID Rom Modules." The first offering (31k) does not show any ascii listing of version, but the second (316k) does, as noted above.

Well now: both update images have higher numbered firmware and BIOS versions, but considering the lack of fall-back support from Syba I'm still leery of doing a firmware update.

There are other less drastic fixes for slow boot camp load found at:

http://forums.macrumors.com/showthread.php?t=1432768 and
http://forums.macrumors.com/showthread.php?t=779252

Which involve the Windows BCD configuration. I've tried some of this before without success because I built the boot camp windows partition from a winclone image which had been shrinked down from a larger partition to fit the drive I was using. That procedure broke the windows recovery process: when I tried to repair with my original Win7 install disk it reported it was not compatible with this version of windows. Checking with BCDEdit I found the Winclone process had changed the OS name to "Vista Business (Recovered)" so there are probably issues with my Win7 install at this point.

So first I will reinstall Win7 and report on that. And if that doesn't fix it, I'll move my card over to a PC (the update must be done with a DOS boot disk) and try the BIOS v.1.0.0.15 and firmware v.2.3.0.1050 image from win-raid.com - and report on that. Fingers-crossed...
 
Troubleshooting the BCD proved futile, so I reinstalled Win7 and applied SLIC 2.1 and Open 7 Activator as per this tutorial:

http://viperfx07.blogspot.com/2010/01/tutorial-fixing-slow-booting-in-windows.html

That didn't change the startup delay. I then moved the Syba card to a PC and performed an update from the win-raid.com image file using a DOS boot USB thumb drive. After the update reported success I moved the card back to the Mac Pro: that didn't change the delay either, but the RAID0 array I had connected to that card was now not recognized in OSX.

In Win 7, the Marvell Storage Utility correctly reported the updated BIOS and Firmware versions. I also noted that there was now a "Report SMART" toggle available instead of the "Rebuild Array" toggle. It would not allow me to set that to 'on' however, which may be because of the RAID0 array on that adapter card. I rebuilt that array, restarted OSX and repopulated it from the backup I'd made of it earlier. I now observed that the disk had changed names in OSX's System Info from "Marvell Raid VD 0" to ASUS ROG RAIDR EXPRESS PCIeSSD." But nothing changed with the Win 7 startup delay.

So next up is to run tests of Win 7 installs on a single bootcamp disk connected to ODD Bay 2 with the Syba card removed to narrow down the issue to (1) my Win 7 install vs (2) the Syba card. In retrospect that would have been a good first step in this troubleshooting process...
 
Trials with various W7 installs and card combinations pointed to my problem being one entirely due to having two Marvell 88SE-9230-based controller cards installed at the same time. When only one card was installed, start up took place in a relatively prompt (~30 sec) fashion.

I imagine a similar issue could arise with a single Marvell-based card on a motherboard that already had Marvell controller chip on it.

Syba Support claims that two cards do not conflict in their tests, but added that they cannot both support RAID arrays at the same time. My setup has RAID0 arrays on each card and once it boots both work properly. Perhaps they mean RAID1 - I have not tested this. But I imagine their tests are on BIOS-based Wintel platforms, not the hybrid EFI/BIOS Apple situation I have.

My final trial involved flashing both cards with BIOS / Firmware from win-raid.com noted previously. This resulted in the boot delay going from 5 or so minutes to over two hours. I kid you not: the machine sits at a blank screen for almost 200 minutes before booting.

I discovered this by leaving the machine at the blank screen overnight, having thought I'd bricked something with the firmware update. Since Syba responded that they have no BIOS / Firmware image files available to re-flash the cards back to the original versions, I have contacted Marvell for their BIOS / Firmware image. I will report their reply if I receive one.

Trying to troubleshoot this I looked at the Windows system log, and there are a variety of errors that show up in it, but none I have been able to correlate with the boot delay, as they occur regardless of whether one card is installed and the machine boots quickly, or two with the delay.

This makes sense given that the event service doesn't start until Windows starts loading, and that is after the delay. So troubleshooting this further seems unlikely unless there is some way to log the Apple BIOS-emulator process itself to see how it interacts with the Marvell BIOS.

Are we having fun yet?
 
I found a BIOS/Firmware update, at:

http://www.highpoint-tech.com/BIOS_Driver/R640L/firmware/9230_CpuAHCI_1053.rar

Running the go.bat in a DOS environment on a Wintel PC with the cards installed therein, using -w -y erase flag first then and -y to update to ver. 1.0.01018 on both my cards, by golly, no more boot delay.

However I'd be the last person to ascribe this simply to the flash update. Mac Pro with its elegantly blank screen gives me no insight into what its EFI is passing to the SMB.

But with this config:

SI-PEX40057 in slot 2 w/2xCrucial M4 SSD RAID0 Windows 7 Ultimate SP1 on ports 2 and 3, and a Samsung 840 EVO on port 0; and,
SI-PEX40058 in slot 4 w/2xSeagate Barracuda 2TB RAID0 HSF+; and,
4xWD 2TB Enterprise Green drives in OSX software RAID0 in the internal drives of an early-2009 (4.1) Mac Pro -- it boots - OSX, Win7 Ult SP1, both with relatively little (<45sec) delay.

Not all is completely jake, however. An 88SE9128 PCIeX1 card (Sonnet, I think) in Slot 3 with a WD3TB SATAIII drive on one eSata port and an Elite Pro enclosure w/2TB WD SATAII drive on the other produces the result,

"No Bootable Disk Found"

But hey, I can turn those drives on after I boot. And considering that I was waiting over 2 hours for W7 boot previously, I'm a happy camper...

...and have refitted the side cover - for the foreseeable future.
 
Troubleshooting the BCD proved futile, so I reinstalled Win7 and applied SLIC 2.1 and Open 7 Activator as per this tutorial
Are you using a pirated copy of windows? Out site rule prohibit _any_ use of piracy.

I now observed that the disk had changed names in OSX's System Info from "Marvell Raid VD 0" to ASUS ROG RAIDR EXPRESS PCIeSSD."
I don't understand, first you said its a SATA card now its a ASUS RAIDR? I Have the ASUS RAIDR and if you attempt to update its firmware using anything other then the ASUS firmware you will kill that SSD.
 
Hi PJALM,

The tutorial quoted ascribes possible boot delay root cause to issues with WAT, documented in licensed copies. That root cause was eliminated early in this investigation. The delay is engendered by conflicts in the pre-OS boot phase. Users could encounter this issue regardless of whether an OS was licensed, pirated or even present. However in this case all software in use is licensed.

The "disk name" reported in OSX's System Info is merely the contents of certain firmware memory locations in the controller card's NVRAM. It is put in those locations during a firmware load, from an ascii file "9200.txt" found in certain (not all) updates' "bin" folder.

Being ascii it is user-editable, which is helpful to distinguish between multiple cards (as in my case). When I first performed that firmware update the data "ASUS ROG RAIDR EXPRESS PCIeSSD" overwrote the "Marvell Raid VD 0" value that had been there before. In a later update I edited the text to uniquely identify each card. But of course nothing changed in the hardware!

I have no experience with the ASUS RAIDR device. Its firmware however was originally produced by Marvell in support of the 88SE92xx controller chip in the ASUS device. The same chip is used in the Syba and Highpoint PCIex2 SATA III controller cards (as well as others).

The firmware update I performed which seems to have fixed my boot delay problem was branded by Asus for their PCIe SSD and has worked fine (so far) on the Syba-branded cards in my system. But it originated with Marvell.

Unfortunately, firmware updates for 92xx-based controllers are poorly supported on the web by Marvell (and most card vendors), leaving customers like myself and Okinawanmatt to do their support jobs for ourselves. If Marvell (and Syba) provided up-to-date firmware, we wouldn't have to poke around in the dark and risk bricking the hardware we purchased when it comes from the supplier with buggy and out-of-date firmware.

I hope my detailed and time-consuming documentation of an instance where a firmware update may have eliminated a serious usability issue has been of help to readers of this forum. If in your case it was not, I'm sorry you wasted your time reading it.
 
Status
Not open for further replies.
Back
Top