Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
I did start to research options for newer kernels, and I vaguely recall reading some mention of issues with changes in interfaces affecting the vendor release. That suggested it'd require more significant code changes, which I'm not ready for without much more experience with the card, and some baseline 'known good' benchmarks for comparison. That's the main reason I haven't explored it.
There is a github repo that says it's for later kernels: snuf/iomemory-vsl
I haven't tried it.
Note that the github repo is branched from an older vendor version and has done significant code refactoring. That will make efforts to merge newer vendor changes possibly error prone. That makes it a hard decision as to where to invest time.
Hi @acquacow!
My question: after cross-flashing my CISCO card will get original SanDisk part number (in fio-status output) or will keep older (branded) part number?
It's important for ESXi (I think). In ESXi compability list I see SanDisk supported up to 6.7, but Cisco only up to 5.5 version.
Thank you!
connectx-2 brackets are working well for me:
Low Profile Bracket for Mellanox CX354A MCX354A-FCBT MCX354A-QCBT MHQH29B-XTR 713752005420 | eBay
Only one screw lines up correctly with the iodrive board, at the the bottom, but that seems enough to stabilize it. It allows plenty of air flow, and the LEDs fit at at the bottom of the opening.
CAUTION!
EFI opROM support UEFI boot is removed above FW version 4.3.0.
latest FW support UEFI boot is 4.2.5.
EFI opROM support UEFI boot is removed above FW version 4.3.0.
latest FW support UEFI boot is 4.2.5.
Last edited:
but for the PX600 series 
Unless you copy the optrom into the 4.3 firmware file and add the definitions for it to the INFO file =)
Any thoughts or feedback regarding active vs. passive cooling?
I am considering installing a IOdriveII into a workstation (rather than a traditional server). The workstation would have case airflow, but it wouldn't be screaming the high volume of air within a server. The drive would have very very low I/O requirements, primarily WORM (Write-Once-Read-Many... for example: gaming, movies, media, etc.). Obviously this isn't fully utilizing the abilities of the drive, but its $/GB is fantastic compared to other SSD storage.
Question:
(1) Would you recommend a dedicated fan be installed near the IOdriveII to keep it cool, or would the regular case fan be sufficient?
(2) At what temperature should I begin to worry? It's around 50-55 C without a fan.
I am considering installing a IOdriveII into a workstation (rather than a traditional server). The workstation would have case airflow, but it wouldn't be screaming the high volume of air within a server. The drive would have very very low I/O requirements, primarily WORM (Write-Once-Read-Many... for example: gaming, movies, media, etc.). Obviously this isn't fully utilizing the abilities of the drive, but its $/GB is fantastic compared to other SSD storage.
Question:
(1) Would you recommend a dedicated fan be installed near the IOdriveII to keep it cool, or would the regular case fan be sufficient?
(2) At what temperature should I begin to worry? It's around 50-55 C without a fan.
The spec is ~300LFM of airflow, but the regular ioDrive IIs use an industrial FPGA that is good for 100C.
The drive will start to throttle writes past 80C-ish and will eventually take itself offline around 95C or so.
A fan somewhere near the drive isn't a bad idea.
Hello all!
For the 1st time I've bought Cisco branded gen3 iomemory.
And it's got some strange behavior - driver loads VERY slow. It takes tens of seconds of silence even if auto attach was disabled by command line (auto_attach=0). Drive's LED flashes all this time and turns on after loading is completed. Looks like some kind of drive rescan is performed every time the driver loads.
Could it be some specific feature of Cisco branded devices?
Also, after upgrading from 4.2.5 to 4.3.5 I've got a bunch of "Pad 3 shows trim mismatch at reg 0x4b expected 0x20 actual 0x00." messages in syslog.
This situation is explained here:
HPE Support document - HPE Support Center
But in my case 4.2.5 driver wasn't complaining at all and newer drivers doesn't show "Invalid mixed NAND configuration.". All messages are limited to trim mismatch infos. After than (and after long long driver loading) drive attaches and behave normally.
What's the root case of this problem? Is it some kind of non-fatal NAND chip issue?
For the 1st time I've bought Cisco branded gen3 iomemory.
And it's got some strange behavior - driver loads VERY slow. It takes tens of seconds of silence even if auto attach was disabled by command line (auto_attach=0). Drive's LED flashes all this time and turns on after loading is completed. Looks like some kind of drive rescan is performed every time the driver loads.
Could it be some specific feature of Cisco branded devices?
Also, after upgrading from 4.2.5 to 4.3.5 I've got a bunch of "Pad 3 shows trim mismatch at reg 0x4b expected 0x20 actual 0x00." messages in syslog.
This situation is explained here:
HPE Support document - HPE Support Center
But in my case 4.2.5 driver wasn't complaining at all and newer drivers doesn't show "Invalid mixed NAND configuration.". All messages are limited to trim mismatch infos. After than (and after long long driver loading) drive attaches and behave normally.
What's the root case of this problem? Is it some kind of non-fatal NAND chip issue?
Please take a note what iomemory doesn't support advanced power saving features like suspend. If your machine will go suspend mode drive wouldn't be able to wakeup properly. Not sure if iomemory's driver can block suspend in Windows, but linux machine can go into suspend without any cautions. Your iomemory will turn inaccessible after wakeup. Suspend/resume is like a powerloss for ioDrive, so the next time you'll boot it will require a drive rescan. It can take from tens of seconds to tens of minutes.
If you don't need the data, you can just format it and drop a blank lebmap on, then overwrite the card a few times and it'll build a new map of any bad cells (you'll see it in the syslog prefixed with fioinf and fioerr).
You have to find a version of the driver that has fio-read-lebmap and fio-write-lebmap in them. I think they took them out at some point.