Hi all,
We are migrating a SCSI HBA driver from KEXT to DriverKit (DEXT), with our DEXT inheriting from IOUserSCSIParallelInterfaceController. We've encountered a data corruption issue that is reliably reproducible under specific conditions and are hoping for some assistance from the community.
Hardware and Driver Configuration:
Controller: LSI 3108
DEXT Configuration: We are reporting our hardware limitations to the framework via the UserReportHBAConstraints function, with the following key settings:
// UserReportHBAConstraints...
addConstraint(kIOMaximumSegmentAddressableBitCountKey, 0x20); // 32-bit
addConstraint(kIOMaximumSegmentCountWriteKey, 129);
addConstraint(kIOMaximumByteCountWriteKey, 0x80000); // 512KB
Observed Behavior: Direct I/O vs. Buffered I/O
We've observed that the I/O behavior differs drastically depending on whether it goes through the system file cache:
1. Direct I/O (Bypassing System Cache) -> 100% Successful
When we use fio with the direct=1 flag, our read/write and data verification tests pass perfectly for all file sizes, including 20GB+.
2. Buffered I/O (Using System Cache) -> 100% Failure at >128MB
Whether we use the standard cp command or fio with the direct=1 option removed to simulate buffered I/O, we observe the exact same, clear failure threshold:
Test Results:
File sizes ≤ 128MB: Success. Data checksums match perfectly.
File sizes ≥ 256MB: Failure. Checksums do not match, and the destination file is corrupted.
Evidence of failure reproduced with fio (buffered_integrity_test.fio, with direct=1 removed):
fio --size=128M buffered_integrity_test.fio -> Test Succeeded (err=0).
fio --size=256M buffered_integrity_test.fio -> Test Failed (err=92), reporting the following error, which proves a data mismatch during the verification phase:
verify: bad header ... at file ... offset 1048576, length 1048576
fio: ... error=Illegal byte sequence
Our Analysis and Hypothesis
The phenomenon of "Direct I/O succeeding while Buffered I/O fails" suggests the problem may be related to the cache synchronization mechanism at the end of the I/O process:
Our UserProcessParallelTask_Impl function correctly handles READ and WRITE commands.
When cp or fio (buffered) runs, the WRITE commands are successfully written to the LSI 3108 controller's onboard DRAM cache, and success is reported up the stack.
At the end of the operation, to ensure data is flushed to disk, the macOS file system issues an fsync, which is ultimately translated into a SYNCHRONIZE CACHE SCSI command (Opcode 0x35 or 0x91) and sent to our UserProcessParallelTask_Impl.
We hypothesize that our code may not be correctly identifying or handling this SYNCHRONIZE CACHE opcode. It might be reporting "success" up the stack without actually commanding the hardware to flush its cache to the physical disk.
The OS receives this "success" status and assumes the operation is safely complete.
In reality, however, the last batch of data remains only in the controller's volatile DRAM cache and is eventually lost.
This results in an incomplete or incorrect file tail, and while the file size may be correct, the data checksum will inevitably fail.
Summary
Our DEXT driver performs correctly when handling Direct I/O but consistently fails with data corruption when handling Buffered I/O for files larger than 128MB. We can reliably reproduce this issue using fio with the direct=1 option removed.
The root cause is very likely the improper handling of the SYNCHRONIZE CACHE command within our UserProcessParallelTask. P.S. This issue did not exist in the original KEXT version of the driver.
We would appreciate any advice or guidance on this issue.
Thank you.
Drivers
RSS for tagUnderstand the role of drivers in bridging the gap between software and hardware, ensuring smooth hardware functionality.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I created a custom class that inherits from IOUserSCSIPeripheralDeviceType00 in the DriverKit SCSIPeripheralsDriverKit framework.
When I attempted to send a vendor-specific command to a USB storage device using the UserSendCDB function of this class instance, the function returned the error:
kIOReturnNotPrivileged (iokit_common_err(0x2c1)) // privilege violation
However, when using UserSendCDB in the same way to issue standard SCSI commands such as INQUIRY or Test Unit Ready, no error occurred and the returned sense data was valid.
Why is UserSendCDB able to send standard SCSI commands successfully, but vendor-specific commands return kIOReturnNotPrivileged?
Is there any required entitlement, DriverKit capability, or implementation detail needed to allow vendor-specific CDBs?
Below are the entitlements of my DriverKit extension:
<dict>
<key>com.apple.developer.driverkit.transport.usb</key>
<array>
<dict>
<key>idVendor</key>
<integer>[number of vendorid]</integer>
</dict>
</array>
<key>com.apple.developer.driverkit</key>
<true/>
<key>com.apple.developer.driverkit.allow-any-userclient-access</key>
<true/>
<key>com.apple.developer.driverkit.allow-third-party-userclients</key>
<true/>
<key>com.apple.developer.driverkit.communicates-with-drivers</key>
<true/>
<key>com.apple.developer.driverkit.family.scsicontroller</key>
<true/>
</dict>
If there is any additional configuration or requirement to enable vendor-specific SCSI commands, I would appreciate your guidance.
Environment: macOS15.6 M2 MacBook Pro
Hi!
Following this ticket: https://developer.apple.com/forums/thread/808764?page=1#868010022
Is there any way to use the hardware RFID reading capabilities of an iPhone to read ISO15693 RF tags silently, and without a UI pop-up? Perhaps using other native iOS libraries than the NFC library?
If not, is there a way for a business to request this feature be allowed in internally used apps only?
Have a 2019 Ford Edge w/ Sync 3.4, wired carplay. Worked fine w/ iPhone 16 Pro on iOS 18. Upgraded to iPhone 17 Pro, came w/ iOS 26, carplay hasn't worked since.
I've kept trying throughout new iOS 26 releases, lately with iOS 26.3 Public Beta 1, still not working.
Have a long running issue with updates and system diagnostics as I've tried over the last few months: FB20739050
There is also a Apple support community thread with issues like this (and a ton of others) - my first post there was https://discussions.apple.com/thread/256138283?answerId=261613103022&sortBy=oldest_first#261613103022
I'm hoping here in the developer forums someone can maybe take a look at the feedback item and various system diagnostics to pin-point the issue. I'm a little concerned it's still not fixed this far into the follow-up point releases of iOS 26.
Appreciate any help, thanks!
--Chuck
Why hasn't the watchOS app updated immediately after the iPhone app was updated? It remains stuck in "Installing" status on the Apple Watch.
Topic:
App & System Services
SubTopic:
Drivers
Hello!
I have app (macos and iPadOS platforms) with empbedded DEXT. The DEXT executable runs fine on both platforms (ver 26.2).
Trying to execute from iPad App code:
let sysExtWs = OSSystemExtensionsWorkspace.shared
let sysExts = try sysExtWs.systemExtensions(forApplicationWithBundleID: appBudleId)
but always getting OSSystemExtensionError.Code.missingEntitlement error.
Which entitlement am I missing?
Thank You!
I am developing a macOS virtual audio device using an Audio Server Plug-In (HAL). I want the virtual device to be visible to all applications only when my main app is running, and completely hidden from all apps when the app is closed. The goal is to dynamically control device visibility based on app state without reinstalling the driver.What is the recommended way for the app to notify the HAL plug-in about its running or closed state ? Any guidance on best-practice architecture for this scenario would be appreciated.
在Developer app中现在注册按钮时置灰等,无法点击,我发送的联系邮件也没有得到回应,有什么办法解决吗
Topic:
App & System Services
SubTopic:
Drivers