LSI MegaRAID SAS3108 Data Recovery: 9361-8i, 9380-8e, IBM M5210 and Intel RS3DC080 Error Messages, StorCLI Commands and Failure States

The SAS3108 is the RAID-on-chip inside the 12 Gb/s MegaRAID generation that LSI introduced in 2013 and that Avago and then Broadcom sold through the end of the decade: the MegaRAID SAS 9361-8i and 9361-4i, the external 9380-8e and 9380-4i4e, and a long list of rebadged twins from IBM and Lenovo, Intel, Supermicro, Fujitsu and Dell. Every one of them runs the same firmware family, is managed with the same StorCLI command-line tool, writes the same event log, and reaches the same decision points when an array fails. This page collects those decision points from Broadcom’s own manuals, OEM documentation from Lenovo and Intel, vendor knowledge-base articles, the Linux kernel source and administrator reports, and rates each by how much danger your data is in — and which command turns a recoverable array into an unrecoverable one.

If you have a StorCLI window open right now, read the first section before you type anything else. Gillware has been recovering failed RAID arrays for more than two decades from our lab in Madison, Wisconsin. If your SAS3108 array is already offline and the data matters, power the server down and start a free evaluation.

Before You Run Anything: The SAS3108 Actions That Destroy Arrays

On this generation most administrators meet a failed array in StorCLI, in the UEFI (HII) configuration utility, or in LSI Storage Authority. Every action below is documented by Broadcom or by a server vendor as a legitimate step. Each is safe when every member drive is healthy and dropped out at the same moment. Each is a one-way door when that is not true.

• Deleting the foreign configuration — storcli /cx/fall delete, or Foreign Config → Clear in HII or WebBIOS. Broadcom describes the command plainly: it deletes the foreign configuration. That configuration is the array map the controller read from the drives. Once it is gone, the controller no longer knows the drives were ever an array.
• Importing a foreign configuration when members dropped out at different times — storcli /cx/fall import. Import trusts every member’s metadata. A drive that fell out days earlier carries stale data. Run storcli /cx/fall import preview first; the preview only reports.
• Forcing a drive back to “good” or “online” — storcli /cx/ex/sx set good force followed by set online, or Make Unconfigured Good and Place Drive Online in HII. Correct when a cable or power event knocked every member out together. Corrupting when the drive failed, or failed first.
• “Set good, then clear the foreign configuration.” One server vendor’s published procedure for a 9361 drive stuck in Unconfigured Bad is exactly this: force it good, then delete the leftover foreign configuration so the drive becomes usable. That is the right procedure for a replacement drive. On a member of an array you still need, it erases the array’s metadata from that drive.
• Deleting preserved (pinned) cache — storcli /cx/vx delete preservedcache, with force for an offline virtual drive. Preserved cache holds writes the controller could not deliver when the virtual drive disappeared. Deleting it throws them away permanently.
• Deleting a virtual drive — storcli /cx/vx del, and especially del force, which Broadcom documents as deleting the virtual drive without waiting for the cache flush to complete.
• Initializing or erasing — storcli /cx/vx start init (fast or full), storcli /cx/vx erase, storcli /cx/ex/sx start erase. Initialization writes zeroes; the erase commands overwrite with patterns. The force option exists precisely because the controller has noticed user data on the drive.
• “Replace missing” commands that start a rebuild — storcli /cx/ex/sx insert array=a row=b replaces a missing member and, per Broadcom, starts an automatic rebuild. A rebuild reads every sector of every surviving member.
• Clearing the event log — storcli /cx delete events. It does not touch your data, but it deletes the only record of which drive dropped first, which is often what decides whether an array can be reassembled correctly.
• Flashing firmware with array members attached, and especially download ... nosigchk noverchk. Broadcom warns the nosigchk option can damage the controller, and MegaRAID has a specific event for cache discarded because the firmware changed underneath it.
• Turning on automatic foreign import — storcli /cx set foreignautoimport=on — on a controller whose drives are in an unknown state. It makes the import decision at the next boot without asking anyone.
• Plugging member drives into a motherboard port or another PC to see what is on them. A RAID 1 member looks like a normal disk to Windows; the first write breaks the mirror.

If you have already done one of these, stop there. Do not run a second command to undo the first. Most of these situations are still recoverable from drive images if nothing else is written.

The SAS3108 Family at a Glance

Every card in this table is built on the SAS3108 RAID-on-chip, which reports itself to the operating system as PCI device 1000:005D (LSI’s internal name for it is “Invader”). The chip provides a PCIe 3.0 x8 host interface, 12 Gb/s SAS and 6 Gb/s SATA, expander support, and on the LSI cards 1 GB of DDR3-1866 cache. The cards differ in port count, connector type, cache size and how the cache is protected.

Card	Ports and connectors	Cache	Cache protection	Notes
LSI/Avago MegaRAID SAS 9361-8i	8 internal, 2 × SFF-8643	1 GB DDR3-1866	CacheVault kit LSICVM02 (CVFM04 + CVPM02)	The most common SAS3108 card
MegaRAID SAS 9361-4i	4 internal, 1 × SFF-8643	1 GB	LSICVM02	Same board as the 8i with a single connector
MegaRAID SAS 9380-8e	8 external, 2 × SFF-8644	1 GB	LSICVM02	For external JBOD shelves
MegaRAID SAS 9380-4i4e	4 internal (SFF-8643) + 4 external (SFF-8644)	1 GB	LSICVM02	Mixed internal/external
MegaRAID SAS 9364-8i	8 internal	—	—	Listed against the SAS3108 in the PCI ID database
IBM / Lenovo ServeRAID M5210 (M5210e onboard)	8 internal, 2 × SFF-8643	None, 1 GB, or 1/2/4 GB flash-backed	Flash module + offload power module (optional)	RAID 5/50 and RAID 6/60 are paid upgrades; see OEM notes
Intel RAID Controller RS3DC080 / RS3DC040	8 / 4 internal	1 GB	AXXRMFBU4	Discontinued; last order September 2022
Intel RS3SC008	8 external	1 GB	—	Intel’s equivalent of the 9380-8e; discontinued
Intel Integrated RAID Module RMS3CC080 / RMS3CC040	8 / 4 internal (SIOM module)	1 GB	AXXRMFBU5	Mounts on Intel server boards; no JBOD mode
Supermicro AOC-S3108L-H8iR (and -16DD)	8 internal	2 GB DDR3-1866	BTR-TFM8G-LSICVM02	Supermicro motherboards only; the -16DD version supports up to 16 drives
Lenovo ThinkServer RAID 720i / 720ix, ThinkSystem RAID 730-8i, Fujitsu PRAID EP400i	8 internal	Varies	Varies	OEM SAS3108 boards listed in the PCI ID database
Dell PERC H730, H730P, H830	Dell’s SAS3108-based PERC9 cards. Same chip and on-disk format; Dell firmware and tools.

All of the full LSI cards support RAID 0, 1, 5, 6, 10, 50 and 60, up to 64 virtual drives per controller, and strip sizes from 64 KB to 1 MB (arrays with smaller strips created on older MegaRAID generations can still be imported). Broadcom specifies at least 200 linear feet per minute of airflow across the 9361 and 9380 cards to keep the SAS3108 within its temperature limits — a number a quiet tower or a home-lab build often does not meet.

Cards that look like SAS3108 cards but are not

Three cards share the 9361/9380 model numbers and a nearly identical management experience but use different chips: the MegaRAID 9361-16i and 9380-8i8e use the dual-core SAS3316, and the 9361-24i uses the dual-core SAS3324. On those cards the flash for cache backup is built onto the board rather than a CVFM04 daughter card, and the 16-port parts manage ports in two groups of eight that cannot be combined into one wide port. The firmware behaviour, event log and StorCLI commands on this page apply to them as well, but the hardware details in the table above do not. The entry-level 9341-4i/8i are SAS3008 cards with no cache and a fixed 64 KB strip.

How SAS3108 Controllers Store Your Array

Two copies of the map

Broadcom’s hardware guide says it directly: configuration data is saved both in the controller’s NVSRAM (32 KB on these cards) and on the drives themselves, in the industry-standard Disk Data Format (DDF) area. When the two agree, the array comes up. When they do not — a replacement controller, drives moved from another server, drives that vanished and came back — the controller calls what it found on the drives a foreign configuration and waits. Almost every SAS3108 data-loss case involves the decision made at that point. Our foreign configuration article covers the state in general.

Drive roaming and drive migration are different things

Moving drives to different ports on the same controller is roaming, and the controller re-identifies them from the on-disk metadata. Moving a set of drives to a different controller is migration, and Broadcom’s procedure has conditions: the destination controller should have no existing configuration, the drives should stay in the same order, and Broadcom notes that moving all the drives of a configuration to a controller that already has one produces an NVSRAM mismatch. A replacement card pulled from another server and still carrying that server’s configuration is the classic way to meet this.

Preserved cache (pinned cache)

If a virtual drive goes offline or is deleted because physical drives went missing while the controller still held writes for it, the controller keeps those writes. StorCLI calls this preserved cache; the event log calls it pinned cache. It is the last data written before the failure — frequently file-system metadata. The controller has a setting, bootwithpinnedcache, that controls whether it will boot at all while pinned cache is present, and a vendor knowledge-base article for a SAS3108-based server shows what administrators then hit: a new RAID volume cannot be created, and StorCLI reports controller has data in cache for offline or missing virtual disks. The vendor’s fix is to delete the preserved cache. That is correct when the old array is truly gone. When it is not, it discards the writes the old array still needs.

Punctures and the bad block table

When a rebuild or consistency check meets an unreadable block on one member while the matching block on another member is already missing or unreadable, the controller cannot reconstruct that stripe. It records it as bad and returns an error whenever it is read rather than hand the operating system invented data. The array stays online; the data in that stripe is gone from the controller’s point of view. The mechanism is covered on our RAID puncture page.

CacheVault instead of a battery

The 12 Gb/s LSI cards replaced the lithium battery with CacheVault: a CVFM04 flash module plugged onto the controller and a CVPM02 supercapacitor pack cabled to it. On power loss the supercapacitor powers the card just long enough to copy the DRAM cache to flash; at the next power-on the cache is restored and written to the drives. Two Broadcom warnings matter for recovery. The CVPM must never be connected or disconnected with the server powered on — doing so damages the board and the supercapacitor. And Broadcom recommends write-through until the module is charged. A controller moved to another server without its CVFM04 leaves any cache that was saved to flash behind on the module.

Compatibility boundaries

• SAS3108 to SAS3108: a healthy array normally imports into another SAS3108 card. Intel’s guidance for its MegaRAID-based cards is to update the replacement controller’s firmware before connecting the drives.
• Older generations to SAS3108: arrays from SAS2108 and SAS2208 cards generally import. MegaRAID has a specific warning for this — Foreign import shall result in a backward incompatible upgrade of configuration metadata — meaning once imported, the drives may no longer be readable by the older card.
• OEM firmware: PERC, ServeRAID and Intel cards share the chip and DDF format but run their vendor’s firmware. Lenovo’s M5210 additionally gates RAID levels behind cache hardware and Features on Demand licences; see OEM notes.
• To Adaptec, HPE Smart Array, Areca or motherboard RAID: no import path in either direction.

How to Read the Message Catalog

Risk level	What it means	What to do
Level 1 — Informational	No data at risk.	Note it and move on.
Level 2 — At risk	Redundancy lost, cache protection gone, or confirmed unreadable blocks.	Back up first. No rebuild until the backup is done if survivors show errors.
Level 3 — Data offline	The virtual drive or controller is unavailable. The data is usually still on the drives.	Power down. No imports, deletes, forces or rebuilds.
Level 4 — Destructive prompt	The screen or command is about to write to the drives or discard data.	Do not confirm until you are certain, or until the drives have been imaged.

Boot-Time and Setup-Utility Prompts (HII, WebBIOS, Ctrl+R)

SAS3108 cards are configured before the operating system loads in one of three ways. On UEFI systems the configuration utility lives inside the server’s own setup screens (Broadcom calls it the HII configuration utility; it appears under Device Settings). On legacy-BIOS systems, LSI cards offer WebBIOS — Broadcom’s hardware guide says to press Ctrl+H when the Press CTRL+H for WebBIOS prompt appears. Intel’s RS3-series cards use a Ctrl+R utility. The menus differ; the decisions are the same.

Foreign configuration found

Risk: Level 3 — the Import and Clear choices are Level 4.

What it means: the drives carry an array definition the controller does not have in NVSRAM. Usual causes: a replaced or reset controller, drives moved from another server, or drives that dropped off long enough for the controller to forget them and then came back. Intel’s knowledge base lists the two everyday triggers as a power outage and a replaced RAID card.

What not to do: do not choose Clear. Do not choose Import to “just get it booting” unless every member dropped out at the same instant and every drive is healthy.

Safe next step: exit without changes, or power off. If the operating system is reachable, storcli /cx/fall show all and storcli /cx/fall import preview both only report — save their output.

Drives shown as (Foreign) Unconfigured Bad, or Frn-Ba

Risk: Level 3. The drive is present, carries metadata from an array the controller does not currently have, and has been rejected. Thomas-Krenn’s documentation for 12 Gb/s MegaRAID cards notes that a common reason is a drive reconnected after being removed improperly. Intel’s Ctrl+R cards mark these drives Frn-Ba; Intel’s procedure is to make each one Unconfigured Good, one at a time, which moves it to Foreign, then import.

That procedure is right when every member dropped at once — a pulled backplane, a cable, an expander or shelf that lost power. It is dangerous when drives went bad at different times, because the import treats all of them as equally current.

Make Unconfigured Good

Risk: Level 4 as part of a force-and-import sequence. Changing a drive’s state is not read-only; it decides what the controller does with that drive’s data at the next scan or import. Before changing any state, record every drive’s enclosure and slot, serial number and current state.

Place Drive Online

Risk: Level 4. This forces an Offline member back into its virtual drive. A server vendor’s knowledge-base article for a 9361-8i in a large storage server shows the case where it is the right move: a RAID 50 lost one drive, the rebuild onto another then failed with a source-drive error, and the virtual drive went offline. The documented fix was to place the last drive that went offline back online in HII, which returned the virtual drive to Degraded and let the rebuild run. The key word is last. Forcing online a drive that went offline first — hours or days before the others — puts stale data back into the array, and the controller has no way to know.

Force Online on a failed array

Risk: Level 4. A server maker’s storage-controller guide covering the LSI-9361-8i describes forcing a Failed array online and warns, in its own words, that the operation might modify the data in the array. That is an accurate description of the risk.

Initialize, Erase, Delete Virtual Drive, Clear Configuration

Risk: Level 4. Initialization writes zeroes. Erase overwrites. Deleting a virtual drive or clearing the configuration removes the definitions; the data blocks remain until something overwrites them, but the controller no longer knows the array existed. None of these has a place on an array that holds data you want.

StorCLI on a Failing SAS3108 Array: Safe Commands and Destructive Commands

StorCLI is the primary tool for this generation (the older MegaCLI syntax still works through the same binary, per Broadcom). StorCLI addresses objects by path: /c0 is controller 0, /c0/v0 is virtual drive 0, /c0/e252/s4 is the drive in slot 4 of enclosure 252, /c0/fall is every foreign configuration. Adding J to the end of a command produces JSON output, which is useful for saving evidence.

Read-only commands — run these first and save the output to another machine

• storcli /c0 show all — controller, virtual drives, physical drives, foreign configurations and CacheVault in one report
• storcli /c0/vall show all and storcli /c0/eall/sall show all — every virtual drive and every physical drive, with states and serial numbers
• storcli /c0/dall show all — drive-group topology, including missing members
• storcli /c0/fall show all and storcli /c0/fall import preview — what the foreign configuration contains, without importing it
• storcli /c0 show preservedcache — which virtual drives have pinned cache and whether they are offline or missing
• storcli /c0/cv show all — CacheVault status (returns an error if no CacheVault is attached)
• storcli /c0 show events file=/path/events.txt and storcli /c0 show termlog — the controller event log and the firmware log

Commands that change or destroy data

Command	What Broadcom documents it as doing	Risk on a failed array
/cx/fall import	Imports the foreign configuration	Level 4 if members dropped out at different times
/cx/fall delete	Deletes the foreign configuration	Level 4 — removes the array map
/cx/ex/sx set good [force]	Changes the drive to Unconfigured Good	Level 4 as part of a force/import or clear sequence
/cx/ex/sx set online	Changes the drive state to Online	Level 4 — trusts that drive’s data
/cx/ex/sx set offline, set missing	Marks a member offline, then missing	Level 4 on a degraded array — removes redundancy you may need
/cx/ex/sx insert array=a row=b	Replaces a missing member and starts an automatic rebuild	Level 4 if survivors have media errors
/cx/ex/sx start rebuild	Starts a rebuild	Level 4 if survivors have media errors
/cx/vx delete preservedcache [force]	Deletes pinned cache (force for an offline virtual drive)	Level 4 — permanent loss of the last writes
/cx/vx del [force]	Deletes the virtual drive; force skips the cache flush	Level 4
/cx/vx start init [full] [force]	Fast or full initialization	Level 4 — zeroes data
/cx/vx erase, /cx/ex/sx start erase	Overwrites the virtual drive or drive with patterns	Level 4
/cx/vx start cc force	Consistency check on an uninitialized virtual drive	Level 4 — rewrites parity to match whatever is on the drives
/cx delete events	Deletes all records in the event log	Level 4 for the evidence, not the data
/cx set foreignautoimport=on	Imports foreign configurations automatically at boot	Level 4 on drives in an unknown state
/cx download file=... nosigchk	Flashes firmware without checking the image signature	Level 4 for the controller and its cache

One vendor support article for a 9361-based server walks through set good force on an Unconfigured Bad drive and then deletes the foreign configuration that appears, ending with the message Successfully deleted foreign configuration. Another storage vendor’s procedure for replacing a failed drive on its 9361-based systems is: set the drive offline, set it missing, spin it down, swap it. Both are reasonable for a healthy array with a single dead drive. Neither should be run on a degraded array whose surviving members are logging errors, or on an offline array whose history you do not know.

Event Log Messages (StorCLI, LSI Storage Authority, MegaRAID Storage Manager)

The controller keeps one event log; StorCLI, LSI Storage Authority (LSA) and MegaRAID Storage Manager (MSM) all display it, and the Linux driver echoes critical entries into the kernel log. The text below comes from the MegaRAID event message table, which carries the same codes across generations. In real logs, drives appear in the form PD 16(e0x08/s22) and virtual drives as VD 00/0.

“State change on PD … from ONLINE(18) to OFFLINE(10)” / “… to FAILED(11)”

Risk: Level 2. A member has left its virtual drive. The numbers in parentheses are the firmware’s state codes. Note the time and the slot — the order in which members left is the single most important fact in any later recovery.

“VD %s is now PARTIALLY DEGRADED” (0x00fa) / “VD %s is now DEGRADED” (0x00fb)

Risk: Level 2. Partially degraded means a RAID 6 or 60 virtual drive has lost one member and still has one level of redundancy; degraded means redundancy is gone. Back up before replacing the drive if any surviving member is logging errors.

“VD %s is now OFFLINE” (0x00fc)

Risk: Level 3. The virtual drive has lost more members than it can tolerate and is no longer presented to the host. In the vendor case above it appeared in the log as FATAL:VD 00/0 is now OFFLINE. The data is usually still on the drives. Power down unless you know exactly which member left last and that it is healthy.

“Rebuild failed on %s due to source drive error” (0x0065) / “Unrecoverable medium error during rebuild on %s at %lx” (0x006d)

Risk: Level 3. A second drive could not be read during the rebuild. This is the most common route from Degraded to Offline. The second drive is usually only partly failed; cleanroom imaging of it is often the difference between some of the data and nearly all of it.

“Controller cache pinned for missing or offline VD %s” (0x0143) / “… VDs: %s” (0x0144)

Risk: Level 3, with a Level 4 decision attached. Writes are being held for a virtual drive that is not there. Bring the original members back before anyone deletes the preserved cache. When cache is discarded, the log shows Controller cache discarded by user for VDs: %s (0x0145) or Dirty cache data discarded by user (0x00ed).

“Controller cache discarded for missing or offline VD %s” (0x0128)

Risk: Level 3. A virtual drive with cached data went offline or missing while the system was running, and because it was offline the cache could not be saved. Writes the operating system believed were complete never reached the drives. Expect file-system inconsistency on top of whatever took the array offline.

“Controller cache discarded due to memory/battery problems” (0x000a), “Unable to recover cache data due to configuration mismatch” (0x000b), “Controller cache discarded due to firmware version incompatibility” (0x000d)

Risk: Level 2–3. Fatal-class events meaning cached writes were lost rather than delivered. The second usually follows drives or configuration changing before the cache could be flushed. The third is the reason not to flash firmware on a controller holding cache for an array in trouble. On CacheVault cards, a failing CVPM forces write-through (BBU disabled; changing WB virtual drives to WT, 0x00c3) unless someone set cachedbadbbu, which keeps write-back caching with no protection.

“Drives missing from configuration at boot” (0x00ee), “Virtual drives (VDs) missing drives and will go offline at boot: %s” (0x00ef), “VDs missing at boot: %s” (0x00f0), “Previous configuration completely missing at boot” (0x00f1)

Risk: Level 3. The controller remembers an array but cannot find some or all of its drives. Every drive failing at once is rare; a cable, backplane, expander, external shelf or power supply is far more likely. Check connections with the power off. Do not create a new configuration on the controller.

“Foreign Configuration detected” (0x00da), “imported” (0x00db), “cleared” (0x00dc)

Risk: Level 1 / 3 / 4. These three record the foreign-configuration decision. If cleared appears and nobody on your team chose it, find out what did before anything else changes. Related: Partial foreign configuration imported, PDs not imported:%s (0x0108) means some drives were left out of the import — the array that came online is not the array you had.

“Foreign import shall result in a backward incompatible upgrade of configuration metadata” (0x011f)

Risk: Level 4. The drives came from an older MegaRAID generation, and importing them rewrites their metadata in a newer format. Fine for a planned upgrade. On drives that might need to go back into the original server, image them first.

“VD %s disabled because RAID-5 is not supported by this RAID key” (0x00fe) / “VD %s disabled because RAID-6 is not supported by this controller” (0x00ff)

Risk: Level 3. The array is intact but the controller is not licensed or equipped to run that RAID level. On SAS3108 hardware this is the Lenovo M5210 trap described under OEM notes: a replacement card without the right cache module or Features on Demand upgrade. Do not delete and recreate the virtual drive; fit the matching hardware or licence.

“Patrol Read puncturing bad block on %s at %lx” (0x0061), “Uncorrectable medium error logged for %s at %lx” (0x010f), “VD bad block table on %s is full” (0x010e)

Risk: Level 2, with confirmed data loss inside the array. Stripes the controller could not reconstruct are now permanently blocked. The vendor fix for punctures is to back up and run a full initialization, which erases the array. If the files in those stripes matter, reconstruction from drive images is the only route back to them.

“Controller needs replacement, IOP is faulty” (0x0113), “Fatal firmware error: %s” (0x000f), “Multi-bit ECC error” (0x0020)

Risk: Level 3. The controller, not the drives, has failed. The drives usually hold an intact array. Do not move them to whichever card is on hand; a mismatched replacement is where the next problem starts.

“Command timeout on PD %s, CDB:%s” (0x010b), “PD %s reset (Type %02x)” (0x010c), “SAS topology error: …” (0x0077–0x0082)

Risk: Level 2. A drive is not answering in time, or the SAS fabric itself is misbehaving. Repeated timeouts on one drive point to that drive; timeouts across many drives on one connector point to the cable, backplane or expander. Either can escalate into a multi-drive drop.

CacheVault, CacheCade and Cache Settings

• CacheVault status: storcli /c0/cv show all reports the module, its state and temperature. In HII it appears on the battery-management screen with the type shown as a supercapacitor.
• Do not hot-swap the CVPM. Broadcom states that inserting or removing it with power on damages the board and the supercapacitor. Power the server fully down first.
• Write-through until charged: Broadcom’s own recommendation after fitting a CacheVault module.
• Cache without protection: Lenovo sold a 1 GB cache upgrade for the M5210 with no flash backup. On that configuration, a power loss with write-back enabled loses whatever was in cache.
• CacheCade: SAS3108 cards support CacheCade SSD caching as a licensed feature — through the advanced-software key header on the 9361-8i (the same header enables FastPath and SafeStore) and through a Features on Demand upgrade on the M5210. A CacheCade virtual drive sits in front of the hard-drive array. If the SSD cache fails while it holds writes that were never flushed, those writes exist only on the SSDs, and StorCLI shows the CacheCade drive as missing. Send the SSDs with the hard drives.

Linux Kernel Messages (megaraid_sas)

SAS3108 cards use the in-kernel megaraid_sas driver, which identifies the chip by PCI device ID 0x005d and drives it through its “fusion” code path. By default the driver copies every controller event of Critical class or higher into the kernel log in the form <sequence> (<timestamp>/0x<locale>/<CLASS>) - <description>, so the event text above — including VD 00/0 is now OFFLINE — shows up in dmesg and syslog. The driver’s own messages, from the current kernel source:

“FW in FAULT state Fault code:0x… subcode:0x… func:…”

Risk: Level 3. The controller firmware has faulted. The driver will try an online controller reset. Record the fault code; it identifies the class of failure.

“IO/DCMD timeout is detected, forcibly FAULT Firmware”

Risk: Level 2–3. A command took too long, so the driver deliberately faulted the firmware to collect a crash dump and reset it. One occurrence after a drive hiccup can be transient. Repeated occurrences mean something — usually a failing drive, sometimes heat — is holding up I/O.

“resetting fusion adapter scsiN.” / “Reset successful for scsiN.” / “Failed to transition controller to ready for scsiN.”

Risk: Level 2–3. The reset sequence. Success means I/O resumes. Repeated resets in one day mean the underlying problem is still there.

“Reset failed, killing adapter scsiN.” / “Reset not supported, killing adapter scsiN.” / “Controller in crit error”

Risk: Level 3. The driver has stopped using the controller. File systems on the array will error out. The controller is the failed component at this moment; protect the drives and do not move them to an arbitrary replacement card.

“Waiting for FW to come to ready state” / “FW now in Ready state”

Risk: Level 1 if both appear. Normal at boot. A boot that hangs after the first line and never prints the second means the controller firmware is not coming up.

VMware ESXi (lsi_mr3 and megaraid_sas)

ESXi supports these cards with Broadcom’s native lsi_mr3 driver. A Broadcom (VMware) knowledge-base article documents the failure sequence many administrators meet: drives log unrecoverable medium errors, the controller firmware faults, the driver attempts an online controller reset, and when the reset fails the adapter is left in a critical state and the local datastore becomes inaccessible. In vmkernel.log it reads as FW in FAULT state. Fault code 0x10000 Sub code 0x0, then Reset failed, stopping adapter., then repeated Adapter in critical state.

Risk: Level 3. The drive errors came first; the controller failure followed. Do not reboot the host into repeated reset attempts. A second article notes that with the older megaraid_sas driver, an offline volume is reported to ESXi only as a lost connection, so the datastore sits in All-Paths-Down rather than reporting a permanent loss — the host can appear unresponsive in vCenter while the real problem is an offline virtual drive. One administrator running a 9361-8i under ESXi 6 reported I/O stopping completely for several seconds at a time while the card reported nothing wrong; treat unexplained stalls on these hosts as a reason to check drive health, not just driver versions.

Windows and Management Software

• Event ID 129, “Reset to device, \Device\RaidPortN, was issued.” Windows logs this whenever the storage driver resets a port after a timeout. A few in a week can be benign; bursts alongside Event 11 (The driver detected a controller error) mean a drive or the controller is failing. Risk: Level 2.
• MegaRAID Storage Manager is legacy software. MSM still manages SAS3108 cards, but Broadcom treats it as maintenance-only, and integrators moved customers off it after it was found exposed to the Log4j vulnerability (CVE-2021-44228); LSI Storage Authority is the replacement for 93xx-series controllers. Intel ended its own RAID Web Console 3 in March 2024. On an older server, the management GUI you find installed may be years out of date — StorCLI is the reliable way to read state.

OEM Notes: Lenovo, Intel, Supermicro and Others

IBM / Lenovo ServeRAID M5210 and M5210e

The M5210 is a SAS3108 card with two SFF-8643 connectors whose feature set depends on what is plugged into it. With no cache module it runs in Integrated MegaRAID (iMR) mode: RAID 0, 1 and 10 standard, RAID 5 and 50 only with a Zero Cache/RAID 5 Features on Demand upgrade, and a fixed 64 KB strip. With a 1, 2 or 4 GB cache module it runs in full MegaRAID (MR) mode with configurable strips and, with a further licence, RAID 6 and 60. Lenovo’s FoD upgrades are system-wide, not per card. The recovery consequences:

• An M5210 replacement without the same cache module and licences may refuse to run the array — the RAID key events above — even though nothing is wrong with the drives.
• An array created in MR mode with a strip other than 64 KB cannot be run by an iMR-mode card.
• One of the cache options (1 GB Cache/RAID 5) has no flash backup.

The M5225 is the external-port sibling in the same M5200 family.

Intel RS3DC080, RS3DC040, RS3SC008, RMS3CC080 and RMS3CC040

Intel’s 12 Gb/s RAID cards are SAS3108 boards with 1 GB of cache. The RS3DC080 launched in 2013 and is discontinued (last order September 2022); the external-port RS3SC008 was discontinued in 2022; the RMS3CC080 is a module that mounts on Intel server boards and does not support JBOD mode. Intel’s knowledge base for these Ctrl+R-based cards gives two instructions worth repeating: update the replacement controller’s firmware before connecting the drives, and when drives show as Frn-Ba, make them Unconfigured Good one at a time. Intel recommends uninstalling RAID Web Console 3, which reached end of life in March 2024. Our page on the previous generation, the Intel RS2BL080, covers the older Ctrl+G cards.

Supermicro AOC-S3108L-H8iR

Supermicro’s SAS3108 card carries 2 GB of DDR3-1866 cache (twice the LSI retail cards), takes the BTR-TFM8G-LSICVM02 CacheVault unit, and is supported only in Supermicro motherboards. The -16DD variant supports up to 16 drives rather than 240. A replacement from the wrong variant, or an LSI retail 9361-8i substituted for it, changes cache size and limits.

Dell, Fujitsu and Lenovo ThinkServer / ThinkSystem

Dell’s PERC H730, H730P and H830, Fujitsu’s PRAID EP400i, Lenovo’s ThinkServer RAID 720i/720ix and ThinkSystem RAID 730-8i are all SAS3108 designs with their makers’ firmware and tools. The on-disk format and the decision points on this page are the same.

The SAS3108 Failure Patterns That Bring Arrays to a Lab

The rebuild that took the second drive

A RAID 5 or RAID 50 loses one member, a rebuild starts, and a second member fails with a source-drive error partway through. The virtual drive goes offline. The vendor-documented fix — force the last offline drive back online and let the rebuild continue — works when that drive is healthy and current. When it is the drive that is failing, the rebuild reads it end to end and finishes the job. Imaging it first in a cleanroom changes the odds.

Unconfigured Bad, set good, clear foreign

A drive comes back from a brief disconnect as Unconfigured Bad. Someone follows a support article: set good force, then delete the foreign configuration so the drive can be used. On a spare that is correct. On a member of the array, the second command removes that drive’s copy of the array map, and the controller now sees one blank drive and an array missing a member.

The pinned cache that blocks everything

An array goes offline; the controller pins its cache; the administrator tries to build a new virtual drive and is told the controller has data in cache for offline or missing virtual disks. The documented fix is to delete the preserved cache. That is the moment to stop: the cache is the last state of the old array, and it can only be delivered if the old members come back.

The replacement card that will not run the array

A SAS3108 card dies and a different one goes in: a different firmware level, an M5210 without the cache module or licence, a Supermicro card swapped for a retail 9361-8i. The import fails, or the virtual drive is disabled, and the tempting next step is to delete and recreate it. Matching firmware, hardware and licences first is what Intel and Lenovo’s documentation points to.

The ESXi host that lost its adapter

Medium errors on a member drive, a firmware fault, a failed online reset, and the datastore is gone. The array is usually fine. Repeated reboots into the same reset loop, and especially rebuilds started on the strength of a successful reboot, are what make it worse.

What to Do Right Now

1. Stop writing. If the volume is still online and degraded, copy the most important data off before any rebuild. If it is offline, shut down cleanly.
2. Capture the evidence. If the operating system is up, run the read-only StorCLI commands listed above and save the output, the event log and the termlog to another machine. Photograph HII or WebBIOS screens.
3. Record the physical layout. Label every drive with its bay, the controller connector and any expander or shelf position, and note serial numbers against the enclosure and slot numbers in the log.
4. Do not import, delete, force, initialize, flash or rebuild. Do not delete preserved cache. Do not move drives to another controller or a PC. Do not unplug the CacheVault module with power on.
5. Get an evaluation. Ship all the drives together, including any CacheCade SSDs. We do not need the server, and in most cases we do not need the controller.

How Gillware Recovers SAS3108 Arrays

We never run a failed MegaRAID array during recovery. Every member is logged by slot, serial number and firmware, then imaged on write-blocked hardware in our ISO 5 Class 100 cleanroom; drives with physical damage are repaired with donor parts first. The originals are shelved and all work happens on the images. Our in-house reconstruction software, HOMBRE, reads the DDF metadata from every image, establishes member order, strip size and parity layout, and identifies which members dropped out and when. Where the metadata was wiped by a foreign-configuration delete or an initialization, the layout is derived from the file-system structures across the images instead. CacheCade SSDs are imaged and their contents evaluated alongside the array. The array is assembled virtually, without any controller, and the file systems on it — NTFS, ReFS, VMFS, ext4, XFS and others — are recovered from the assembled volume. More on our MegaRAID process is on our LSI MegaRAID recovery page; the previous generation is covered on our LSI MegaRAID SAS2108 page; the RAID data recovery hub covers everything else.

Every case is quoted after a free evaluation, so you know the cost before any recovery work begins.

SAS3108 Model Pages

• LSI MegaRAID SAS 9361-8i Data Recovery: 9361-8i and 9361-4i Failures, StorCLI Traps, and CacheVault Risks
• IBM / Lenovo ServeRAID M5210 Data Recovery: iMR vs MR Mode, Features on Demand Traps, and Error Messages
• Intel RAID Controller RS3DC080 and RS3DC040 Data Recovery: Ctrl+R Prompts, Frn-Ba Drives, and End-of-Life Replacement Traps
• LSI MegaRAID SAS 9380-8e Data Recovery: External JBOD Shelf Failures, 9380-4i4e, and Error Messages

SAS3108 Manuals and Documentation

Document	What it covers
12Gb/s MegaRAID SAS RAID Controllers User Guide (pub-005183, v1.3)	9361 and 9380 hardware: connectors, cache, CacheVault, airflow, drive roaming and migration
12Gb/s MegaRAID SAS Software User Guide (pub-005110)	HII, WebBIOS, StorCLI, MSM and the event message appendix
StorCLI Reference Manual	Every StorCLI command, including foreign, preserved-cache and drive-state commands
CVPM02, CVPM05, CVFM04 User Guide	CacheVault modules by controller, handling and monitoring
ServeRAID M5210 and M5210e Product Guide	iMR and MR modes, cache options, Features on Demand upgrades
Intel RAID Controller RS3DC080 specifications	Intel rebadge, cache backup option, discontinuation dates
Intel: Importing foreign RAID arrays on Ctrl+R-based controllers	Frn-Ba drives, firmware-first on replacement cards
Supermicro AOC-S3108L-H8iR	Supermicro SAS3108 card, cache and CacheVault options
Broadcom KB 450566: Local datastore inaccessibility (lsi_mr3)	ESXi firmware-fault and failed-reset sequence
Linux megaraid_sas driver source	Authoritative text of every driver message

Frequently Asked Questions

Is it safe to run storcli /c0/fall import?

Only if every member dropped out at the same moment and every drive is healthy. Run storcli /c0/fall import preview first and save the output. If any drive failed earlier than the others, import can combine stale and current data; image the drives first.

What does storcli /c0/fall delete actually do?

It deletes the foreign configuration — the array definition the controller read from the drives. The data blocks are not erased, but the controller no longer knows the drives formed an array. Recovery after it requires reconstructing the layout from drive images.

Can I delete preserved cache to get the server working again?

It will clear the block on creating new virtual drives, and it will permanently discard the writes held for the offline array. If that array’s data matters, bring its original drives back or have them imaged before deleting anything.

Is the 9361-16i or 9361-24i a SAS3108 card?

No. The 9361-16i and 9380-8i8e use the SAS3316 and the 9361-24i uses the SAS3324. They run the same MegaRAID firmware family, so the messages and StorCLI commands on this page apply, but their cache and port hardware differ.

My replacement M5210 says the virtual drive is disabled. Is the data gone?

Usually not. The replacement is missing the cache module or Features on Demand licence that the RAID level needs. Fit matching hardware and licences; do not delete and recreate the virtual drive.

Do you need my controller or my CacheVault module?

Usually not. Send every drive, labeled by bay, plus any CacheCade SSDs. We reconstruct from drive images without a controller. If pinned cache or a CacheVault module may hold the last writes, tell us when you open the case.

Start Your SAS3108 Recovery

If your SAS3108 array is offline, degraded with failing survivors, or showing messages you now recognize from the Level 3 and Level 4 lists above, power the server down and label the drives. Do not import, delete, force, initialize, flash or rebuild, and do not delete preserved cache. Our engineers will image every member, reconstruct the array without the controller.