-
Notifications
You must be signed in to change notification settings - Fork 80
All Known Limitations
This page will get long and messy and the limitations may have multiple layers on hardware, drivers, software and more.
All of the issues described on this page have been found over the years Seagate has produced HDD diagnostic software such as SeaTools for Windows, SeaChest, openSeaChest, SeaTools SSD, SeaTools and many other internal tools.
Many of these limitations still exist although some may have been resolved over time. This page is unable to capture everything and there are likely new limitations showing up with each new piece of hardware, driver update, or operating system update. Sometimes a limitation is intentional and sometimes it is not.
If a limitation on this page affects a specific drive feature, it will also be noted on that feature's wiki page as needed.
By the end of this page you may find yourself wondering "How in the world does anything actually work" and we are right there with you...
- RAID Limitations
- Driver Limitations
- Translator Limitations (SAT, SNT)
- SMART Attribute Vendor Variations
- Customer Unique Firmware Limitations
- Operating System Limitations
- BIOS and UEFI Limitations
Note: This page is under active development. More sections will be added as limitations are documented.
The first and foremost thing to understand about RAIDs is that there is no standardized method to issue raw commands to the physical drives that are part of the RAID.
The closest to standardization that ever occurred was the CSMI (Common Storage Management Interface) specification that made it as far as a draft standard in T10. Some drivers have limited support for CSMI, even today, but this standard was never adopted (for a lot of different reasons). CSMI is often implemented at a driver-level however since it is most pertinent to RAID, it will be in the RAID section rather than the driver limitations section.
Each RAID vendor uses different IOCTL interfaces in their kernel drivers to communicate with RAID controllers. While the IOCTL codes may vary between operating systems (Windows, Linux, FreeBSD, Illumos), the functionality provided by a given vendor's driver is typically consistent across platforms when examining their code. Each vendor may have one or many drivers for the different products they've manufactured over time.
Broadcom, Avago, LSI, 3ware:
- Driver Varieties: mpi3, mpi2, mpi, mrsas (Broadcom/LSI); 3ware used completely different drivers
-
Known Issues:
- TCG commands may not work with certain MegaRAID controllers
- Some MegaRAID controllers have ROC bugs preventing Seagate vendor unique SAS commands
- Some MegaRAID controllers block all passthrough to SAS drives while SATA works fine
- Drivers or firmware managing the RAID may filter certain commands
Microchip, Microsemi, PMC, Adaptec:
- Driver Varieties: Multiple Adaptec interfaces across product generations; newer HBAs use CISS driver (shared with HPE controllers after acquiring that business)
-
Known Issues:
- Some RAID HBAs have hot-swap issues with ATA devices
- Drivers or firmware managing the RAID may filter certain commands
Intel Motherboard/CSMI:
- Support limited by Intel RST driver version installed
- Different driver versions can respond differently to certain requests or just have bugs
- Many older revisions will not respond to any CSMI requests (prior to version 11.x-ish)
- See Operating System Limitations - Windows for detailed Intel RST issues (Windows-only driver)
AMD:
- Some chipset drivers support CSMI
- Systems with NVMe support seem to lose CSMI support for SATA disks
- Has a different vendor unique method to access physical drives in a RAID
- No documentation can be found on the web describing how to access this interface
3ware (acquired by Broadcom/LSI/Avago):
- Limited command set allowed in RAID mode
- All commands outside the short allowed list are blocked in RAID mode
- JBOD mode limitations unknown but likely governed by SAT spec version in HBA firmware
What commands can be sent?
- Theoretically: Anything
- Realistically: Unknown until tested on specific controller/configuration
- Limitations may or may not be documented by RAID vendors
- Cannot be fully documented by limited team size given numerous products and configurations
Command Filtering for Security: Some RAID vendors now only allow specific commands from published standards that have well-documented, predictable behavior. Vendor-specific commands, mode pages, capabilities, and other undocumented features may be blocked because:
- The RAID vendor does not know their exact behavior
- Lack of documentation creates potential security risks
- Unpredictable behavior could compromise RAID stability or data integrity
This is particularly common with vendor unique commands and lesser-known features that fall outside standard specifications.
Resets, Timeouts, and Cascading Failures:
When a drive receives a reset command or when a command timeout occurs, the current operation or state of the drive can be significantly affected:
What Happens During a Reset:
- Any in-progress command is immediately aborted
- Drive state may change unexpectedly (power state transitions, security state changes, etc.)
- Long-running operations (Sanitize, Format, Self-Test, Firmware Download) are interrupted and may fail
- Drive must reinitialize, which takes time and may appear as temporary unavailability
The Cascade Effect: Problems occur when software, kernel drivers, or RAID firmware have command timeouts set too short:
- Short Timeout Triggers: A legitimate long-running command (e.g., Sanitize taking hours) exceeds the timeout value
- Driver Issues Reset: The driver/kernel assumes the drive is unresponsive and issues a reset
- Drive Aborts Operation: The in-progress operation is terminated, potentially leaving the drive in an inconsistent state
-
Controller Misinterprets: The RAID controller, unaware of the drive's legitimate state transition, may:
- Assume the drive has failed
- Mark the drive as faulty in the RAID configuration
- Attempt recovery via additional resets
- Rebuild the array unnecessarily
-
Cascading Failures: Multiple reset attempts can compound the problem, potentially causing:
- Data corruption if writes are interrupted
- Drive firmware instability
- Complete system hang as multiple components attempt recovery simultaneously
Best Practices:
- Use appropriate timeout values for the command being executed (some commands legitimately take hours)
- Avoid issuing state-changing commands (Sanitize, Depopulate, Security Erase) through RAID controllers when possible
- Test long-running operations in JBOD mode first if available
- Monitor drive and controller logs for unexpected resets during operations
Operating Systems: RAID driver support varies by vendor - check vendor documentation for supported platforms.
Processor Architectures: While RAID drivers may be compilable from open-source kernels for any CPU type, it is up to the RAID vendor to qualify them and ensure they work correctly with that CPU architecture.
Generally Supported:
- x86 (32-bit Intel/AMD)
- amd64/x86_64 (64-bit Intel/AMD)
- AArch64/ARM64 (on more modern RAID HBAs - check vendor documentation)
CPU Architecture Considerations: Code written for one CPU architecture may not work identically on another due to fundamental differences in how they load and access data:
- Endianness: Big-endian vs little-endian byte ordering affects how multi-byte values are stored
-
Alignment Requirements: Some CPUs require data to be aligned on specific boundaries (2-byte, 4-byte, 8-byte)
- x86/amd64 allow unaligned access (with performance penalty)
- ARM/AArch64 may fault or produce incorrect results on unaligned access
- RAID driver code not written with alignment in mind may crash on strict-alignment CPUs
- Memory Ordering: Different CPUs have different memory consistency models affecting multi-threaded code
Testing is Essential: Always verify RAID functionality on your specific CPU architecture before deploying in production.
While there exist some drivers that support the CSMI interface, the support is often incomplete. Sometimes there is enough support to discover devices and issue commands, but not always.
Sometimes despite partial support being available, it may still not be enough for openSeaChest to communicate with the devices in the RAID.
Of the various drivers we've debugged and tested, the Intel chipset drivers often support CSMI so that openSeaChest is fully supported. Intel drivers that support an SSD cache or Optane memory boost or NVMe devices are still supported, at least for SATA disks through this interface.
We've also encountered the Adaptec driver storarc has some support for CSMI, but some of the IOCTLs fail unexpectedly or return data that does not seem to be correct, so support is disabled or at least very limited.
Another driver we've encountered is the HPCISS driver for Windows. This driver does not seem to allow any of the CSMI passthrough commands required for openSeaChest so it is not supported.
AMD has some chipset drivers that support CSMI, but any system that also has NVMe support seems to remove what little CSMI support is available for SATA disks.
Drivers are OS-specific - see Operating System Limitations for OS-specific details.
Most drivers tested have been found to:
- Only support the 16-byte ATA-Passthrough command
- Not support asynchronous commands
- May require specific memory alignment (though no requirements above byte alignment have been seen)
Note: Much of the SAT translation support described in this section applies to both OS drivers and HBA firmware for SAS controllers. USB limitations are significantly different and covered separately - see USB Bridge Limitations.
Typical Support (SAS HBAs, motherboard AHCI):
- 16-byte ATA-Passthrough: Always present in tested cases
- 12-byte ATA-Passthrough: Available on most controllers, but not allowed in Windows unless using a SAS HBA
- 32-byte ATA-Passthrough: May be supported in more recent hardware (Broadcom 9500/9600 series HBAs), but not widely supported prior to SAT-5 adoption
- NCQ/FPDMA commands via ATA-Passthrough: Only observed as possible in Linux with AHCI cards and libata; not fully tested by Seagate and not currently in use; SAT-6 makes changes that will make it more likely to be supported on future HBAs by removing NCQ tag requirements and allowing the HBA to assign tags instead (which also simplifies software implementation)
Common Translations Supported:
- ATA Information VPD page (except Highpoint)
- Send Diagnostic command (for DST - Diagnostic Self-Test)
- Self-test results VPD page
- Informational Exceptions VPD page (SMART)
- Control Mode page, Control Extension Mode page
- Temperature log page
- Power Conditions VPD page, Power Conditions mode page (EPC)
- Block Device Limits VPD page
- Extended Inquiry VPD page
DMA vs UDMA Protocol:
- Tools try UDMA mode first, then retry with DMA mode
- Microsemi/Adaptec: Only accept DMA mode, reject all UDMA mode commands
- UDMA preferred for better compatibility with other SATLs (especially USB)
Return Task File Registers (RTFRs):
- Most controllers return RTFRs in sense data correctly
- Some LSI firmwares: Return fixed format sense data; when descriptor format requested for full RTFRs, send back completely different command's result
- First command may show partial LBA fields (missing extended LBA), creating unreliable results
Intel RST (Rapid Storage Technology):
- Windows-only driver with complex CSMI and NVMe support
- See Operating System Limitations - Windows for comprehensive Intel RST details
Linux libata:
- Blocks ATA Security commands unless kernel boot parameter
libata.allow_tpm=1is provided - see Enabling Access To Additional Commands In Linux for details - Does not allow hardware or software resets
- Incomplete SAT translation (but no worse than most HBAs)
- See Operating System Limitations - Linux for more details
SCSI to ATA Translation (SAT) and SCSI to NVMe Translation (SNT/SNTI) allow drives to appear as SCSI devices to the host OS. This section covers translator limitations - for comprehensive details on translation protocols, see SCSI Translations (coming soon).
SAT is a T10 specification defining how to translate SCSI CDBs into ATA commands. It includes:
- SCSI command translation to ATA equivalents
- SAT ATA-Passthrough commands (12-byte, 16-byte, 32-byte variants)
- ATA error translation to SCSI sense data
Where SAT is Used:
- Every SAS HBA that supports SATA devices
- Every USB to SATA/PATA adapter
- Some OS drivers and add-in card firmwares
12-Byte ATA-Passthrough:
- Limitation: Can only issue 28-bit ATA commands (not useful for modern drives)
- Dangerous: Uses same operation code as CD/DVD "blank" command (MMC spec)
- Current Usage: Now used by default for unknown controllers/USB devices when issuing 28-bit commands (Identify, etc.) since it is more likely to be USB-compatible off the shelf despite other issues; when rejected, tools retry with 16-byte CDBs instead
16-Byte ATA-Passthrough:
- Capability: Can issue both 48-bit and 28-bit ATA commands
- Most widely supported and most commonly used by tools
- Limitation: Cannot set AUX or ICC registers
32-Byte ATA-Passthrough:
- Capability: Can issue any command including AUX and ICC registers
- Status: Implemented in libraries to generate CDB, but not used unless a command requires setting AUX or ICC registers due to limited real-world support
Some ATA-Passthrough commands require Return Task File Registers (RTFRs) in sense data:
- SCT features commands (when inquiring current settings)
- Read Native Max Address
- Accessible Max Address - Report Native Max Address
- SMART return status
- Sanitize Status
Fixed Format Sense Data:
- Can only return partial RTFRs
- If extended LBA or sector count registers are non-zero, bits indicate this
- Should provide parameter code for ATA-Passthrough results log page (never supported)
- Workaround: Issue REQUEST SENSE with descriptor mode bit set to 1; if possible disable system autosense to issue REQUEST SENSE directly (not currently implemented)
- Capacity-Related Issue: Disks between 128GB and 2TB may not respond to certain requests exactly as software needs when RTFRs are required, due to the way system autosense requests fixed format sense data by default for these capacities
Descriptor Format Sense Data:
- Can return complete RTFRs via ATA-Passthrough results descriptor
- Nearly every device supports this if descriptor format is available
- Some USB devices still have issues
SAT defines a protocol field for ATA-Passthrough CDBs covering any ACS specification protocol. Mismatching protocol with command causes undefined behavior - tools will not send mismatched commands to prevent stability issues.
Warning: Just because you can trick an HBA into issuing an NCQ/FPDMA command by changing the protocol field to "DMA" does not mean this will work properly in a production environment! This is not something openSeaChest will ever do as it may break system stability or cause unpredictable behavior.
Protocol Support Matrix:
| Protocol | HBA Support | Driver SATL Support | Notes |
|---|---|---|---|
| NCQ/FPDMA | Rare | Never | Likely to start being supported as SAT-6 compliance is adopted |
| Hardware Reset | Sometimes | Never | Some implement as software reset instead |
| Software Reset | Sometimes | Never | |
| DMA | Usually | Usually | UDMA preferred for compatibility |
| UDMA | Usually | Usually | Microsemi/Adaptec do not support |
| PIO | Almost always | Almost always | Some SATLs limited to single-sector transfers (USB) |
| Non-data | Usually | Usually | Must set check condition flag for RTFR retrieval; sense data can be truncated/empty |
| Execute Device Diagnostic | Unknown | Filtered | Linux libata blocks this; workaround is to switch to non-data protocol - may be safe on SATA but should NOT be used on PATA devices as it changes transfer mode back to slowest mode during execution, potentially breaking systems or drivers unaware of this change |
| Return Response Information | Rare | Rare | Bugs common (extend bit not set, T-dir dependence crashes) |
Check Condition Bit:
- Requests check condition generation to receive sense data on any command completion
- Some SATLs do not honor this bit
- Some SATLs crash when this bit is set
- Even when set, RTFRs may still be empty, respond with RTFRs from a different command, or RTFRs are truncated/incomplete
The most commonly supported translations (required by OS compatibility, especially Microsoft test requirements):
Standard Commands:
- Standard Inquiry Data
- Unit Serial Number VPD page
- Block Device Characteristics VPD page
- Device Identification VPD page
- Read/Write/Verify commands (6, 10, 12, 16-byte variants)
- Caching Mode page
- Solid State Media Log Page (SSD only)
- Unmap (SSD only)
Zoned Device Requirements:
- All zoned command translations
- Some Zoned VPD and Log pages (if necessary for host)
Additional HBA/Controller Support:
- See specific items listed under Driver Limitations above
SNTL: SCSI to NVMe Translator (driver implementation) SNTI: SCSI to NVMe Translation whitepaper from nvmexpress.org
Critical Limitation: There is no defined NVMe passthrough CDB in any specification. The SNTI whitepaper:
- Describes translation of common commands (like SAT does)
- Does not include passthrough command definition
- Is outdated and abandoned (NVMe drivers created quickly enough that translation deemed unnecessary)
The Problem: USB to NVMe adapters exist and use SNTL, presenting as SCSI devices. While there is no standardized NVMe passthrough, openSeaChest now has vendor-specific passthrough definitions from JMicron, ASMedia, and RealTek with information on their capabilities.
Vendor-Specific Passthroughs: Some vendors created proprietary NVMe passthrough methods. Since these are non-standard, there is no guarantee an off-the-shelf USB adapter will work with openSeaChest. We do our best to detect supported implementations found during testing, but coverage can be limited.
Important Safety Note: Attempting to send vendor unique commands randomly without accurately detecting device support may cause undefined behavior, potentially making a device unresponsive and unrecoverable. Because of this risk, openSeaChest performs very thorough screening to ensure a device will support these commands before issuing any of them. Auto-detection is now possible through various methods, but the most reliable method is always USB VID/PID lookup.
Supported Vendor Passthroughs:
JMicron (JMS583):
- Reuses opcode A1h
- Cannot be auto-detected
- Requires USB VID/PID matching
ASMedia:
- Two variants: Basic and Packet
- Basic (AS2362): Only supports Identify (specific CNS) and Get Log Page
- Packet (AS2364): More complete, similar to JMicron, allows any NVMe command
- Can be auto-detected via Standard Inquiry signature (but both signatures same - must attempt both)
RealTek:
- Has NVMe passthrough with limited documentation
- Support implemented through trial and error debugging
- Firmware update support incomplete
- Detection and command support continue to improve
USB bridges have extensive unique limitations deserving dedicated coverage. See USB Bridge Limitations for comprehensive details on:
- Bridge-specific quirks and workarounds
- BOT vs UAS behavioral differences
- Command support variations
- Transfer size limitations
- Known bridge chip issues
Different drive vendors implement SMART attribute data differently on SATA drives. This variation can affect how openSeaChest interprets attributes on non-Seagate drives, particularly those without the Device Statistics log.
Key Characteristics:
-
Vendor-Specific Implementations: Each manufacturer may use different attribute IDs, data formats, and thresholds for the same type of measurement
- RAW Data Field Variations: Even when attribute IDs and names are identical across vendors, the RAW data fields contain completely different formats and data
- Common Attribute Example - ID 9 (Power On Hours): All vendors use this attribute, but each may report power-on time in their own unique RAW data format
- Common Attribute Example - ID 1 (Read Error Rate): Same attribute name across vendors, but RAW data interpretation varies significantly
-
Temperature Attribute Example - ID 194:
- Some vendors report only current temperature
- Some vendors report maximum and current temperature
- Seagate reports minimum, maximum, and current temperature
- Even vendors reporting similar data use different byte offsets within the RAW data field
- Endianness Variations: Some vendors use different endianness (big-endian vs little-endian) in their RAW data fields, requiring vendor-specific interpretation logic
- This complexity means that knowing the attribute ID and name is insufficient - you must also know the vendor-specific RAW data format to interpret values correctly
-
Impact on Drives Without Device Statistics Log: Drives without the Device Statistics log may not be able to have correct values or data format interpreted in all scenarios
- The Device Statistics log (introduced in ACS-3) provides a standardized format for common drive health data
- Drives with this log are much easier to interpret accurately regardless of vendor
Different Approaches to Handling Vendor Variations:
-
Smartmontools Approach: Maintains a model number database to manage vendor variations
- Database maps specific drive models to their attribute implementations
- Requires ongoing maintenance as new models are released
-
openSeaChest Approach: Attempts to figure out attributes based on firmware codebase patterns rather than maintaining extensive model number lists
- Seagate Focus: This approach is currently focused on Seagate products only
- Even for Seagate drives, some model number lookup is required to correctly identify the drive family and interpret attribute data
- More meaningful and correct based on industry patterns observed across Seagate drive families
- Different Seagate models from the same firmware codebase often implement identical attributes (may add or remove one or two)
- Firmware codebase pattern recognition allows support for entire product families rather than individual models
- Non-Seagate Support: Standards-based features (Device Statistics log, standard SMART attributes) are fully supported for all vendors
- May add support for vendor-specific attribute interpretations when implementations are well-documented and straightforward
Recommendation: For the most accurate and consistent health monitoring, use drives that support the Device Statistics log. This standardized log eliminates most vendor-specific interpretation issues.
For detailed information on SMART attributes and health interpretation, see How To Check Drive Health.
Some drive manufacturers, including Seagate, provide customer unique firmware builds for specific enterprise customers as part of secure supply chain agreements. These firmware builds have important limitations:
Cannot Switch Between Standard and Customer Unique Firmware:
- Security Violation: Switching between customer unique firmware and standard firmware (in either direction) violates the secure supply chain policy
- Firmware Updates Only From Customer: Firmware updates for drives with customer unique firmware must come from the customer who purchased them, not directly from the drive manufacturer
- Warranty Handled by Customer: Warranty claims and support for drives with customer unique firmware are handled by the customer, not the drive manufacturer directly
- Contractual Requirements: The limitations are enforced through contractual agreements between the manufacturer and the customer
Important Notes:
- This limitation exists to protect the security and integrity of customer-specific configurations
- Other drive vendors may have similar limitations with their own customer unique firmware programs
- It is up to each manufacturer to set and enforce their own rules regarding customer unique firmware
What This Means for You:
- If you purchased a drive with customer unique firmware (typically through an OEM or enterprise supplier), you must obtain firmware updates from that supplier
- Do not attempt to flash standard firmware onto a drive with customer unique firmware
- Contact your original supplier for support and firmware updates, not the drive manufacturer directly
For detailed information on firmware updates, see How To Update Drive Firmware.
Each operating system has unique limitations, passthrough mechanisms, and supported features. This section provides an overview - see individual OS pages for comprehensive details.
Supported Versions: Windows Vista and higher (including equivalent Windows Server versions)
- Windows XP, XP 64-bit, and Server 2003 are NOT supported. Windows XP only allows single 512B sector transfers in passthrough mode which is a significant workaround that breaks compatibility with more modern Windows operating systems. If you want to contribute a pull request to add this in after testing it, we are happy to consider it, but it will not be part of official Seagate support due to the significant limitations present in XP with software disk tools.
Passthrough Methods:
ATA-Passthrough IOCTL:
- Limited to 48-bit commands
- Direct vs Double-buffered modes (Direct preferred for large transfers)
- Windows XP: Single-sector PIO transfers only
- Windows Vista+: Multi-sector transfers supported
- Asynchronous requests not allowed per Microsoft documentation
- Double-buffered caches some command responses, such as Identify device. This makes it incompatible for use with checking configuration changes or firmware changes after an update is made.
SCSI-Passthrough / SCSI-Passthrough Ex:
- Works well for SCSI/SAS devices and SAS HBAs
- Ex variant (Windows 8+) allows CDBs larger than 16 bytes
- Asynchronous requests not allowed (though overlapped IO may work - unclear if intended when some testing was performed)
- Limited to 16-byte CDBs (standard), or driver-dependent for Ex variant support
NVMe (Windows 8.1+):
- No universal NVMe passthrough from Microsoft's driver
- Windows 8.1: SCSI translation only, plus Firmware Update Miniport IOCTL (Supported by openSeaChest)
- Windows 10: Storage Query Property, Vendor Unique Passthrough (with restrictions), Firmware Update IOCTLs
- Vendor unique commands must be in "Commands and Effects" log or rejected
- Firmware Update API has 15-second timeout (activation must complete within this time). Workaround to use miniport version instead will sometimes get around this since the miniport request supports a timeout value. This is the default behavior in openSeaChest for maximum compatibility with any firmware update.
Critical Windows Limitations:
| Issue | Affected Commands | Workaround/Notes |
|---|---|---|
| Sanitize Blocked | Sanitize commands | Windows 8+ blocks unless running Windows PE or Windows Recovery Environment |
| ATA Security Blocked | All ATA Security | Windows sends freeze-lock on device attach; Windows PE allows only specific password |
| Firmware Update BSOD | Firmware updates | Pre-Windows 10: May BSOD if all segments sent successfully; use manual deferred mode to avoid the BSOD and power cycle the drive to complete activation |
| Cached Failures | Sequential commands | Failed command remains cached; send ATA Check Power Mode to clear before issuing a new command |
| OS-Initiated Resets | Long-running commands | OS may reset if command exceeds undocumented timeout or during OS drive access |
| 64k Transfer Limit | Large transfers | Generally limited to 64k (may vary by driver) |
| Bad LBA Repair Blocked | Write/repair operations | Permission denied on system areas or foreign Windows boot drives. Sometimes possible to workaround with another command like write-same or write-zeros, but not guaranteed. |
Intel RST Driver Issues:
- Driver Variants: Different Consumer and Enterprise drivers exist for NVMe with different interfaces to issue commands
- openSeaChest Support: Currently only consumer driver supported
- NVMe Command Filtering: Heavy filtering on NVMe devices
- Firmware Updates: Limited to commit action 1 (system reboot required to complete activation)
- M.2 vs PCIe Slots: M.2 slots may or may not use Intel RST driver; PCIe adapter slots will usually not use this driver and instead use the Microsoft Windows 10 NVMe driver
- Non-conformant Inquiry Data: Sets vendor ID to first 8 chars of model number instead of "ATA"
- CSMI Support Variability: Some versions work well with CSMI, others do not respond to any CSMI requests (prior to version 11.x-ish)
- SCSI-Only Mode: Some versions expose SCSI device only (no CSMI or Windows passthrough available)
- ATAPI Opcode Handling: ATAPI opcodes always treated as ATAPI spec opcode (DO NOT USE for vendor unique commands)
- Various Bugs: Different driver versions have different bugs; some incompatible with any commands
Note: For SMART attribute vendor variations that affect all operating systems, see SMART Attribute Vendor Variations.
Microsoft Documentation Links:
Supported Interface: SG (SCSI Generic) driver and NVMe driver in kernel
- Out-of-tree drivers not supported
- Targets kernel 2.6 and higher with SG driver enabled
SG (SCSI Generic):
- Very good support, handles nearly everything
- No limits on CDB size
- For ATA drives on ATA interface: Translation performed by libATA
- Provides device/bus/controller reset calls (not always supported by all controllers)
- Asynchronous IOs supported (support quality unknown at this time since it is unused in openSeaChest for now)
Critical SG Issues:
| Issue | Impact | Workaround |
|---|---|---|
| SD Handle Spin-Up | Using SCSI Block handle spins up device on open | opensea-transport maps SD to SG via sysfs to prevent power state change |
| ATA Security Blocked | Security commands blocked by libata | Add libata.allow_tpm=1 to kernel boot parameters |
| Incomplete SAT | Missing some SAT translations | No worse than most HBAs |
| No Hardware/Software Reset | libata blocks reset commands | Use SG reset calls (limited controller support) |
NVMe (Intel submitted kernel driver):
- IOCTL supports any NVMe command
- Used by nvme-cli for all IOs
NVMe Issues:
- Header files/definitions moved and changed numerous times across kernel versions. Build system will attempt to figure this out in openSeaChest for you, but can fail.
- Some kernels have only partial NVMe passthrough headers (likely reorganization bug)
- All IOs treated as synchronous requests
- Reset IOCTLs not available in every kernel version
- Namespace rescan IOCTL not always available
Build Compatibility:
- Technically any Linux kernel 2.6+ with SG driver enabled
- OpenSeaChest now statically links with musl-libc for maximum portability between Linux distributions
- Linking to glibc creates portability issues since different distributions use different glibc versions; you would need to build for each distro you support, or use something downrevision like manylinux provides for near-complete distro compatibility
Cross-Compilation for Other Architectures:
- Requires cross-compiler matching customer's environment
- Embedded devices/companies often create custom cross-compilers
- If mismatch occurs, need either:
- Customer's toolchain (compiler, linker, etc.)
- Remote access to system with toolchain (raises IP security concerns for closed-source code)
CAM IO (Controller Architecture Model):
- Allows SCSI, ATA, or NVMe passthrough depending on device attachment
- NVMe support now available through CAM
- Issue: Missing USB VID/PID lookup to improve overall USB support
NVMe:
- Supported via CAM interface
- Also supported via Intel-provided IOCTL (similar to Linux driver)
Legacy IOCTLs:
-
ATA IOCTL: Support added for old ATA IOCTL interface
- Limits available commands
- Primarily useful for FreeBSD versions prior to FreeBSD 8 (which didn't support CAM ATA)
- Legacy SCSI IOCTL: Same interface as OpenBSD/NetBSD (last used in FreeBSD 3.x)
Linux Compatibility Layer:
- Can run Linux versions with /dev/sg? handles if layer installed
- Most customers do not want to install this package
CAM IO (Controller Architecture Model):
- Supported and uses CAM interface
- No NVMe support available
- All SATA support handled via SCSI translation in DragonFly BSD kernel/CAM code
- Does not provide CAM-ATA interface like FreeBSD
- Issue: Missing USB VID/PID lookup to improve overall USB support
Now Supported:
- SCSI passthrough available
- ATA passthrough available
- Interface is nearly identical between OpenBSD and NetBSD
- Issue: Missing USB VID/PID lookup to improve overall USB support
NVMe:
- Not currently supported
USCSI:
- Interface for both ATA and SCSI drives
- Very similar to Linux SG
- For ATA on AHCI: Performs SCSI translation
- Issue: Missing USB VID/PID lookup to improve overall USB support
UNVME:
- NVMe passthrough defined by Oracle
- Not currently supported - support planned
USCSI:
- Same as Oracle Solaris
- Issue: Missing USB VID/PID lookup to improve overall USB support
NVMe:
- Very limited interface in source code
- Allows Identify, read log, few other commands
- No vendor unique commands or specific IOs
- Not currently supported - support for limited command set planned
Implemented Interfaces:
- SCSI passthrough: Tested and working for /dev/rhdisk# handles
- ATA passthrough: Implemented but untested
- NVMe passthrough: Implemented but untested (requires AIX 7.2 or later)
USB Support:
- USB VID/PID lookup support unknown
- Not clear if USB support is possible on AIX
RAID Physical Drives (PDisks):
- No available passthrough documentation
- Not supported unless IBM provides documentation
- See RAID Limitations for general RAID issues
SCSI Passthrough Only:
- Source code exists in repository
- Untested - no validation on actual HP-UX systems
No NVMe Support:
- No NVMe passthrough interface exists in HP-UX
- Not possible to implement without OS-level support
Very Limited Out-of-Box Capabilities:
- Only ATA Identify and ATA SMART commands to internal ATA devices
- Anything else requires custom driver
Why Not Support the Available ATA Interface: Supporting the only available ATA interface is not worth the effort because:
- macOS hasn't shipped with SATA drives in many years
- Would provide minimal value to users
- Custom kernel driver would be required for meaningful functionality
Custom Driver Route:
- Only path to proper macOS support
- Not currently planned due to unknown scope of work
- Would require significant development and ongoing maintenance per macOS version
Dead - Do Not Request:
- Cannot be made or supported
- Will not work in UEFI environment
- Requires custom drivers for all hardware (too much work to create/maintain)
Both traditional BIOS and UEFI firmware can create limitations preventing certain drive operations.
ATA Security:
- Freeze-Lock: BIOS may issue freeze-lock on boot, blocking all ATA Security commands (cannot be stopped in any known BIOS/UEFI option). Often sent prior to booting the operating system.
-
Password Encoding: BIOS may encode password in unique way unknown to software
- ATA Security does not specify password encoding (not even ASCII requirement - just 32 bytes)
- BIOS may hash, reverse, byteswap, or use any other encoding
- Moving drive between systems with different encoding causes unlock failures
DCO (Device Configuration Overlay):
- Some BIOSs aware of DCO will issue DCO freeze-lock on boot, blocking all DCO changes from other software.
These issues are system-specific and only resolvable by system manufacturer/BIOS maker:
- Low Memory: Cannot allocate enough to communicate with devices or scan system
- Broken Passthrough: Protocols present but do not work properly
- System Hangs: Accessing some protocols causes system freeze
- Misaligned Data: Some protocols return misaligned data
- Discovery Failures: Protocols present but do not discover devices
- Block Driver Only: System implements block access but not passthrough
- External Driver Issues: Loading external ATA/NVMe passthrough drivers may not solve problems (will not load, will not connect, or same issues as built-in)
All defined in Intel EDK2. Having a UEFI driver does NOT guarantee passthrough availability - the DXE driver must support the specific passthrough protocol. Only the block driver is required for booting a system.
ATA Passthru:
- Similar to SAT ATA-Passthrough command setup
- May support physical and/or logical devices
- Asynchronous command support optional
-
Loading External Driver:
- You can compile a driver using EDK2 and load it manually.
- Must unload system driver first
- Must match device (typically AHCI controller)
- Known Issues: System claims disconnect but fails to load (other firmware holding protocol), system hangs when accessed, insufficient memory
SCSI Passthru / Ex SCSI Passthru:
- Available since EFI (pre-UEFI)
- May support physical and/or logical devices
- Asynchronous support optional
- Cannot provide SAS controller drivers - must come from HBA vendor
NVMe Passthru:
- May support physical and/or logical devices
- Asynchronous support optional
-
Issues:
- Unstable (does not work reliably across different systems that were tested in passthrough mode).
- Some commands hang driver indefinitely
- "Infinite" timeout requests immediately fail (API usage issue unique to NVMe, not in ATA Passthru)
Purpose: Backwards compatibility with legacy option ROMs
The Problem:
- Many systems load legacy option ROMs before UEFI drivers
- If legacy ROM loads first, UEFI driver never loads and protocols unavailable
Fix:
- Disable CSM entirely, OR
- Change settings to load UEFI driver first (if available) before legacy option ROMs
- Necessary on many systems, especially for SAS HBA adapters with UEFI drivers
Purpose: Prevent viruses/malware from infecting system on boot or pre-boot
Requirement: Initial OS loader or bootloader must be signed by Microsoft after Microsoft testing
Alternative: Part of chain of trust OR signed by Microsoft
Disabling Secure Boot:
- Not recommended (opens potential vulnerability)
- Many end users will not know how
- Cannot be automated
- Simple enable/disable setting on some systems
- Others: Delete platform key from key management (ONLY if restorable!)
Chain of Trust:
- If signed by Microsoft and embeds another key, anything with EXACT SAME KEY can load
- This is how Linux systems boot (shim with Microsoft key + distro key)
Seagate Approach:
- Seagate Shim → rEFInd → Tinycore Linux
- Seagate Shim → UEFI Shell → UEFI Applications/drivers/OS
Observed Issues:
- Signature validation failed despite correct signing (only Windows boots)
- Same as above but hitting Enter repeatedly allows loading even with error messages about incorrect signatures.
- Partial validation (shell works but fails on other EFI applications)
- Requires switching secure boot mode from "Windows" to "Other" for non-Microsoft OS
No Known Specification: Undefined what fast boot does exactly
Typical Behavior:
- Loads minimal drivers to get Windows running
- Windows loads Windows drivers as needed
Issues:
- Some drivers may not load in UEFI shell
- May cause undesired behavior or lack of functionality
- Changes to UEFI firmware may be ignored (system only boots to Windows since this hardcodes the boot path)
None of these issues can be solved by Field Diagnostics team
Some systems have more memory limitations than others. This is not a RAM limitation, but a limitation of the UEFI firmware on how to allocate memory for a UEFI application.
Symptoms:
- Tool will not work
- System freezes
- System crashes or reboots
- Protocols expose but data is misplaced, fails, randomly offset, or byte-swapped
Only fixes can be provided by motherboard manufacturer/BIOS/UEFI firmware maker
- Introduction To Command Line Tools - Getting started with openSeaChest
- ATA Security Feature - Platform-specific issues with ATA Security
- Drive Health and SMART - Understanding health monitoring capabilities