MacOS(Apple Silicon) IOKit driver for FPGA DMA transmission, kernel panic.
Hardware and software configuration:
MAC mini M1 2020 16GB, macOS Ventura 13.0 or 13.7.8
FPGA device capability: 64-bit
Complete description:
We've developed a DMA driver for PCIe devices (FPGA) based on IOKit. The driver can start normally through kextload, and the bar mapping, DMA registers, etc. are all correct. I am testing DMA data transmission, but a kernel panic has occurred. The specific content of the panic is as follows:
{"bug_type":"210","timestamp":"2026-01-28 14:35:30.00 +0800","os_version":"macOS 13.0 (22A380)","roots_installed":0,"incident_id":"61C9B820-8D1B-4E75-A4EB-10DC2558FA75"}
{
"build" : "macOS 13.0 (22A380)",
"product" : "Macmini9,1",
"socId" : "0x00008103",
"kernel" : "Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103",
"incident" : "61C9B820-8D1B-4E75-A4EB-10DC2558FA75",
"crashReporterKey" : "6435F6BD-4138-412A-5142-83DD7E5B4F61",
"date" : "2026-01-28 14:35:30.16 +0800",
"panicString" : "panic(cpu 0 caller 0xfffffe0026c78c2c): "apciec[pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x02220060 linkcdmsts=0x00000000 (ltssm 0x11=L0)\n" @AppleT8103PCIeCPort.cpp:1301\nDebugger message: panic\nMemory ID: 0x6\nOS release type: User\nOS version: 22A380\nKernel version: Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103\nFileset Kernelcache UUID: C222B4132B9708E5E0E2E8B8C5896410\nKernel UUID: 0BFE6A5D-118B-3889-AE2B-D34A0117A062\nBoot session UUID: 61C9B820-8D1B-4E75-A4EB-10DC2558FA75\niBoot version: iBoot-8419.41.10\nsecure boot?: YES\nroots installed: 0\nPaniclog version: 14\nKernelCache slide: 0x000000001d1b4000\nKernelCache base: 0xfffffe00241b8000\nKernel slide: 0x000000001e3f8000\nKernel text base: 0xfffffe00253fc000\nKernel text exec slide: 0x000000001e4e0000\nKernel text exec base: 0xfffffe00254e4000\nmach_absolute_time: 0x907c3082\nEpoch Time: sec usec\n Boot : 0x6979adbb 0x00023a6a\n Sleep : 0x00000000 0x00000000\n Wake : 0x00000000 0x00000000\n Calendar: 0x6979ae1a 0x00064953\n\nZone info:\n Zone map: 0xfffffe1000834000 - 0xfffffe3000834000\n . VM : 0xfffffe1000834000 - 0xfffffe14cd500000\n . RO : 0xfffffe14cd500000 - 0xfffffe1666e98000\n . GEN0 : 0xfffffe1666e98000 - 0xfffffe1b33b64000\n . GEN1 : 0xfffffe1b33b64000 - 0xfffffe2000830000\n . GEN2 : 0xfffffe2000830000 - 0xfffffe24cd4fc000\n . GEN3 : 0xfffffe24cd4fc000 - 0xfffffe299a1c8000\n . DATA : 0xfffffe299a1c8000 - 0xfffffe3000834000\n Metadata: 0xfffffe3f4d1ac000 - 0xfffffe3f551ac000\n Bitmaps : 0xfffffe3f551ac000 - 0xfffffe3f5ac94000\n\nCORE 0 recently retired instr at 0xfffffe002569d7a0\nCORE 1 recently retired instr at 0xfffffe002569eea0\nCORE 2 recently retired instr at 0xfffffe002569eea0\nCORE 3 recently retired instr at 0xfffffe002569eea0\nCORE 4 recently retired instr at 0xfffffe002569eea0\nCORE 5 recently retired instr at 0xfffffe002569eea0\nCORE 6 recently retired instr at 0xfffffe002569eea0\nCORE 7 recently retired instr at 0xfffffe002569eea0\nTPIDRx_ELy = {1: 0xfffffe2000c23010 0: 0x0000000000000000 0ro: 0x0000000000000000 }\nCORE 0 PVH locks held: None\nCORE 1 PVH locks held: None\nCORE 2 PVH locks held: None\nCORE 3 PVH locks held: None\nCORE 4 PVH locks held: None\nCORE 5 PVH locks held: None\nCORE 6 PVH locks held: None\nCORE 7 PVH locks held: None\nCORE 0 is the one that panicked. Check the full backtrace for details.\nCORE 1: PC=0xfffffe00279db94c, LR=0xfffffe00260d5d9c, FP=0xfffffe8ffecaf850\nCORE 2: PC=0xfffffe0025be76b0, LR=0xfffffe0025be7628, FP=0xfffffe8fff08f5f0\nCORE 3: PC=0x00000001c7cacd78, LR=0x00000001c7cacd84, FP=0x000000016f485130\nCORE 4: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8ffe1dff00\nCORE 5: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8fff5eff00\nCORE 6: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8ffed8bf00\nCORE 7: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8fff11bf00\nCompressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space\nPanicked task 0xfffffe1b33aad678: 0 pages, 470 threads: pid 0: kernel_task\nPanicked thread: 0xfffffe2000c23010, backtrace: 0xfffffe8fff6eb6a0, tid: 265\n\t\t
...
Kernel Extensions in backtrace:\n com.apple.driver.AppleT8103PCIeC(1.0)[A595D104-026A-39E5-93AA-4C87CE8C14D2]@0xfffffe0026c619d0->0xfffffe0026c86c97\n dependency: com.apple.driver.AppleARMPlatform(1.0.2)[11A9713E-6739-3A4C-8571-2D8EAA062278]@0xfffffe0025f13ff0->0xfffffe0025f6255f\n dependency: com.apple.driver.AppleEmbeddedPCIE(1)[E71CBCCD-AEB8-3E7B-933D-4FED4241BF13]@0xfffffe002654e0b0->0xfffffe00265684c7\n dependency: com.apple.driver.ApplePIODMA(1)[A419BABC-A7A3-316D-A150-7C2C2D1F6D53]@0xfffffe00269a24b0->0xfffffe00269a6c3b\n dependency: com.apple.driver.IODARTFamily(1)[03997E20-8A3F-3412-A4E8-BD968A75A07D]@0xfffffe00275bcf50->0xfffffe00275d0a3f\n dependency: com.apple.iokit.IOPCIFamily(2.9)[EC78F47B-530B-3F87-854E-0A0A5FD9BBB2]@0xfffffe0027934350->0xfffffe002795f3d3\n dependency: com.apple.iokit.IOReportFamily(47)[843B39D3-146E-3992-B7C7-960148685DC8]@0xfffffe0027963010->0xfffffe0027965ffb\n dependency: com.apple.iokit.IOThunderboltFamily(9.3.3)[B22BC005-BB7B-32A3-99C0-39F3BDBD8E54]@0xfffffe0027a5e3f0->0xfffffe0027b9a1a3\n\nlast started kext at 1915345919: com.sobb.pcie-dma\t1.0.0d1 (addr 0xfffffe00240e47f0, size 9580)\nlast stopped kext at 1774866338: com.sobb.pcie-dma\t1.0.0d1 (addr 0xfffffe00240e47f0, size 9580)\nloaded
It seems that the DMA request address initiated by FPGA exceeded 32 bits, which was intercepted by PCIe root port and resulted in a kernel panic.This is also the case on macOS (M2).
I have tried the following code interface:
IOBufferMemoryDescriptor:
a. withCapacity(bufferSize, kIODirectionInOut, true);
b. inTaskWithPhysicalMask(kernel_task, kIODirectionInOut, bufferSize, 0x00000000FFFFFFFFULL)。
The physical addresses of the constructed descriptors are all >32 bits;
IODMACommand:
a. withSpecification(kIODMACommandOutputHost64, 64, 0, IODMACommand::kMapped, 0, 0),gen64IOVMSegments() The allocated IOVM address must be>32 bits, which will generate a kernel panic when used later.
b.withSpecification(kIODMACommandOutputHost32, 32, 0, IODMACommand::kMapped, 0, 0),gen32IOVMSegments() The allocation of IOVM failed with error code kIOReturnenMessageTooLarge.
So after the above attempts, the analysis shows that the strategy of Dart+PCIe root port on macOS (Apple Silicon) is causing the failure of 64 bit DMA address transfer.
I have two questions:
a. Does Dart in macOS (Apple Silicon) definitely not allocate <=32-bit IOVM addresses?
b. Is there any other way to achieve DMA transfer for FGPA devices on macOS (Apple Silicon)?
Thanks!
Delve into the world of built-in app and system services available to developers. Discuss leveraging these services to enhance your app's functionality and user experience.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
After pairing and having subscribed to a service, and even after having exchanged messages, the service fails after a period of time and both devices need to pair again.
Topic:
App & System Services
SubTopic:
Networking
We are testing our existing live build, which was prepared with Xcode 16.2, on iOS 26 beta for experience assurance and found that the [[UIDevice currentDevice] systemVersion] API is returning iOS 19 instead of the expected version iOS 26. Has anyone else observed this issue?
Hello,
When an iOS app runs on Vision Pro in compatible mode, is there a flag such as isiOSAppOnVision to determine the underlying OS at runtime? Just like the ProcessInfo.isiOSAppOnMac. It will be useful to optimize the app for visionOS.
Already checked but not useful:
#if os(xrOS) does not work in compatible mode since no code is recompiled.
UIDevice.userInterfaceIdiom returns .pad instead of .reality.
Thanks.
The documentation for CGColorRef (https://developer.apple.com/documentation/coregraphics/cgcolorref?language=objc) clearly shows that it is a struct. However, when I try to store a cell's border color using CGColorRef originalColor = self.bg.layer.borderColor and inspect what happens in the debugger, both that property and its copy have the same address. And later when I try to restore the border color the copy still has the same address but is no longer valid and causes a crash on assignment (originalColor is actually an instance variable...)
This is all object behavior, not struct behavior. If CGColorRef really was a struct, the contents would have been copied, the instance variable would have had its own address that would never have changed, and the value would have remained valid indefinitely and let me copy it back without a problem.
Why is this documented wrong? Was this a recent change? I actually had this code working at some point, and now it's broken.
Is there any recent and a bit authoritative documentation which explains how to debug recent versions of macos kernel?
I have found some blog posts from other users but those are either outdated or don't work for some other reason. I am guessing kernel debugging is pretty common for developers working on macos itself, so I'm hoping someone in this forum would have some working instructions for that.
I was excited to find out about Wi-Fi Aware in i[Pad]OS 26 and was eager to experiment with it. But after wiping and updating two devices (an iPhone 11 Pro and a 2018 11" iPad Pro) to Beta 1 I found out that neither of them support Wi-Fi Aware 🙁.
What current and past iPhone and iPad models support Wi-Fi Aware?
And is there a new UIRequiredDeviceCapabilities key for it, to indicate that an app requires a Wi-Fi Aware capable device?
Hi,
We have an issue (https://github.com/actions/runner-images/issues/10924) raised by a user requesting to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners. Apple introduced a new LNP policy with macOS Sequoia that is not controlled by TCC or MDM. Could you please guide us on how to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners?
Thanks.
I've been trying to add a CoreSpotlight indexer to my macOS application. The new template for the indexer uses the new appex CSImportExtension style importer.
I've been following this ->
https://developer.apple.com/documentation/corespotlight/csimportextension
I changed the CSSupportedContentTypes in the Info.plist file to the correct file type uti.
I added a dummy value into the attributes (see code below) - just setting contentDescription to 'noodle' (easy to search for)
class ImportExtension: CSImportExtension {
override func update(_ attributes: CSSearchableItemAttributeSet, forFileAt: URL) throws {
// Add a dummy value, and see whether spotlight finds it
attributes.contentDescription = "noodle"
}
}
I have a number of files on disk that match the uti (and can be found when I search by the file name)
Yet, when I build and run my app, the a spotlight search for 'noodle' finds no results.
Can anyone give me any advice? I cannot find any indication that the ImportExtension is called (although when I put a log message at the start of the update() call there's no message in the console which seems to suggest it's not being called).
Is there any way of debugging this?
Cheers and thanks -- Darren.
I'm on macOS Sequoia Version 15.7.3 (24G419) and using Xcode Version 26.2 (17C52).
In my Xcode project, Transaction.updates and Product.SubscriptionInfo.Status.updates don’t seem to emit updates reliably.
The code below works consistently in a fresh Xcode project using a minimal setup with a local StoreKit Configuration file containing a single auto-renewable subscription.
class InAppPurchaseManager {
static let shared = InAppPurchaseManager()
var transactionTask: Task<Void, Never>?
var subscriptionTask: Task<Void, Never>?
init() {
print("Launched InAppPurchaseManager...")
transactionTask = Task(priority: .background) {
for await result in Transaction.updates {
print("\nReceived transaction update...")
try? await result.payloadValue.finish()
}
}
subscriptionTask = Task(priority: .background) {
for await result in Product.SubscriptionInfo.Status.updates {
print("\nReceived subscription update...")
print("state:", result.state.localizedDescription)
}
}
}
}
I initialise it in:
func applicationDidFinishLaunching(_ aNotification: Notification) {
_ = InAppPurchaseManager.shared
}
I do not build any UI for this test. I open StoreKit Transaction Manager then click Create Transaction → select the product → choose Purchase (Default) → Next → Done. The console shows that it detects the initial purchase, renewals and finishes each transaction.
It also works even if I do not add the In-App Purchase capability.
In my actual project, the initial purchase is detected and finished, but renewals are not detected. Subsequent transactions then appear as unverified, presumably because the updates are not being observed so the transactions are not being finished.
What can I do to make this work reliably in my actual project?
For context, in the actual project:
I have a StoreKit Configuration file that is synced with App Store Connect
The In-App Purchase capability is enabled
The configuration file is selected in the scheme
The products in App Store Connect show “Ready to Submit”
Loading products works:
try await Product.products(for: ...)
Also, I use ProductView for the purchase UI. The first purchase works and is detected and finished, but subsequent renewals are not finished because the updates do not seem to be emitted.
Since upgrading to Mac OS 10.5 Beta-2, daemons launched with launchctl are failing to open Desktop/Documents/Downloads files and folders even in read mode with an error "Operation not permitted".Does anyone facing this issue?
I have been using the SCNetworkReachabilityGetFlags for 10+ years to inform users that their request won't work. In my experience this works pretty well although i am aware of the limitations.
Now, i am looking into the NWPathMonitor, and i have one situation that i'm trying to. get my head around - it's asynchronous.
Specifically, i am wondering what to do when my geofences trigger and i want to check network connectivity - i want to tell the user why the operation i'll perform because of the trigger couldn't be done.
SO. say i start a NWPathMonitor in didFinishLaunchingWithOptions. When the app is booted up because of a geofence trigger, might i not end up in a case where my didEnterRegion / didExitRegion gets called before the NWPathMonitor has gotten its first status?
The advantage here with SCNetworkReachabilityGetFlags, as i understand it, would be that it's synchronous?
If i want to upgrade to nwpathmonitor, i guess i have to do a method that creates a nwpathmonitor, uses a semaphore to wait for the first callback, then contunues?
Thoughts appreciated
Hello
I've noticed that this product, heavily promoted on the ASC forums for many years, is no longer available from the Apple App Store.
Can anyone tell me the reason why the product is no longer supported?
Friends have asked me if it is 'safe' to use.
Is it?
Note to moderator: If I'm asking in the wrong places, please redirect my question. Thank you.
I wrote an AppleScript that takes a bunch of scanned jpegs with systematically named filenames and transfers information from the filename into the date and time fields. That all works fine, but I've got many more scans to do and I'd like to augment the script to include a progress meter because it takes a long time to run on e.g. 1000 photos.
I've found basic progress meter examples online that involves commands like:
set progress total steps to theImageCount
set progress completed steps to 0
set progress description to "Processing Images..."
set progress additional description to "Preparing to process."
and they run OK in a separate dummy test case, however I'm getting syntax errors for such commands in my renaming script because (I think) they're inside a
tell application "Photos"
wrapper and it looks like Photos doesn't like those commands.
A progress meter (in any AppleScript) should be a straightforward thing i.e. I can clearly define a total number of steps and I can clearly define the step number I'm currently on. I just want to display something like:
I'd even be OK with just implementing something like:
display dialog "blah blah"
but that needs to be manually dismissed with each iteration of the loop, so that's no good. I also tried:
display notification "blah blah"
but that yields hundreds of notification boxes at the top right of my screen, so that's also impractical.
I was even thinking maybe I could call some generic system progress meter with all the right variables via a "do shell script" command (although I have no idea how to do that). Something surely must be possible, but I just can't figure it out :-(. Could some kind soul please help me out. Thanks.
Topic:
App & System Services
SubTopic:
Automation & Scripting
Hello,
We're developing endpoint security software using the Endpoint Security framework, and we've encountered challenges with the behavior change in macOS 15 regarding provisioning UDIDs in cloned VMs.
The Change
Prior to macOS 15, cloning a VM preserved its UDID (format: 0000FE00-9C4ED9F68BBDC72D). Starting with macOS 15, cloned VMs receive a new UDID generated from the host's Secure Enclave (format: b043d27202c7ac37ca3c6b82673302225485cae9), making each clone effectively a new device.
Our Workflow
We maintain a clean base VM image and clone it for each test run. We add the base VM's UDID to our provisioning profile once, then create clones which (previously) retained that same UDID, allowing us to start new testing cycles without re-registering devices.
This is essential because our product involves low-level system integration through the Endpoint Security framework, and if something goes wrong during development, it has the potential to affect system stability. To prevent any cascading issues between test runs or different product versions, we need each test to start from a known clean state rather than reusing the same VM.
The Challenge
With each VM clone generating a new UDID, we're hitting Apple's device registration limits quickly. This particularly impacts:
New team members who spin up VMs for the first time and can't run signed builds
Our CI/CD pipeline where multiple test environments need provisioning profiles
Developers testing different branches who need separate clean environments
Current Workaround
We've found that VMs created on macOS 14 and upgraded to macOS 15+ retain their original UDID format. However, we're concerned this workaround may stop working in future macOS versions, which would leave us without a viable path forward.
If the workaround stops working, our fallback would be signing each CI build with a Developer ID signature to allow running on any device. However, we'd prefer to avoid this as it would significantly increase load on Apple's signing infrastructure for what are essentially internal test builds.
We completely understand the security reasoning behind tying UDIDs to the host's Secure Enclave for Apple Account support. However, for development workflows that don't require Apple Account features in VMs but do require clean, isolated test environments, the previous behavior was quite valuable.
Question
Is there a recommended approach for teams in our situation? We're happy to explore alternative workflows if there's a pattern we're missing, or we'd be glad to provide more context if this is a use case Apple is considering for future updates.
Thanks for any guidance you can provide!
Feedback case: FB21389730
Topic:
App & System Services
SubTopic:
Core OS
Tags:
macOS
Provisioning Profiles
Code Signing
Virtualization
I have been experimenting with the BGContinuedProcessingTask API recently (and published sample code for it https://github.com/infinitepower18/BGContinuedProcessingTaskDemo)
I have noticed that if I lock the phone, the code that runs as part of the task stops executing. My sample code simply updates the progress each second until it gets to 100, so it should be completed in 1 minute 40 seconds. However, after locking the phone and checking the lock screen a few seconds later the progress indicator was in the same position as before I locked it.
If I leave the phone locked for several minutes and check the lock screen the live activity says "Task failed".
I haven't seen anything in the documentation regarding execution of tasks while the phone is locked. So I'm a bit confused if I encountered an iOS bug here?
Updated version of this post
My HomePod mini is now on version 16.4, so the the temperature and humidity sensors are enabled. The data properly shows up in the Home app on my various devices.
In my HomeKit iPad app running on Mac Catalyst, however, the data does not show up. I would expect the HomePod mini to show up in HMHome.accessories with a service of type HMServiceTypeTempatureSensor. I see all of my other HomeKit accessories, just not the HomePod mini.
I have tried with the latest Xcode (14.3) and highest available iOS Target and Minimum Deployment (16.4), macOS version 13.3. I have not, as of this writing, upgraded my HomeKit architecture, however.
Note that I haven't tried the app on an actual iPad (and the iOS simulator doesn't expose my HomeKit environment.)
We are developing a macOS VPN application using NEPacketTunnelProvider with a custom encryption protocol.
We are using standard On-Demand VPN rules with Wi-Fi SSID matching but we want to add some additional feature to the native behaviour.
We want to control the 'conenect/disconnect' button status and allow the user to interact with the tunnel even when the on demand rule conditions are satisfied, is there a native way to do it?
In case we need to implement our custom on-demand behaviour we need to access to this information:
connected interface type
ssid name
and being informed when it changes so to trigger our logic, how to do it from the app side?
we try to use CWWiFiClient along with ssidDidChangeForWiFiInterface monitoring, it returns just the interface name en0 and not the wifi ssid name.
Is location access mandatory to access wifi SSID on macOS even if we have a NEPacketTunnelProvider?
Please note that we bundle our Network Extension as an App Extension (not SystemExtension).
Hello,
We use the Network API in our macOS ObjectiveC applications to create a small web server. With macOS Sequoia or Tahoe (not with Sonoma), downloading files from another computer using the built-in ethernet port is way too slow.
Steps to reproduce:
Computer A (using macOS Tahoe or Sonoma), run an application using the Network APIs to create a webserver
Make sure that this computer connects to the network using the Ethernet port, there is no issue when using WiFi
On computer B, make an HTTP request to download a 20MB file => it will take about 30 seconds to download => way too slow...
We tested with:
if on computer A you run a web server using the GCD API instead of Network, it takes 0.2 seconds to download the file => no issue
on computer A disable TSO, it improves the results, but that's not a long term solution as it doesn't hold when rebooting
I can provide sample code to demonstrate this if needed.
This is a new issue as it's been a while we use that code, and only noticed it recently, and macOS Sonoma is not impacted.
Thank you for the help you can provide.
Pierre
Hello! Some colleagues and work on Jujutsu, a version control system compatible with git, and I think we've uncovered a potential lock contention bug in either APFS or the Darwin kernel. There are four contributing factors to us thinking this is related to APFS or the Kernel:
jj's testsuite uses nextest, a test runner for Rust that spawns each individual test as a separate process.
The testsuite slowed down by a factor of ~5x on macOS after jj started using fsync. The slowdown increases as additional cores are allocated.
A similar slowdown did not occur on ext4.
Similar performance issues were reported in the past by a former Mercurial maintainer: https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/.
My friend and colleague André has measured the test suite on an M3 Ultra with both a ramdisk and a traditional SSD and produced this graph:
(The most thorough writeup is the discussion on this pull request.)
I know I should file a feedback/bug report, but before I do, I'm struggling with profiling and finding kernel/APFS frames in my profiles so that I can properly attribute the cause of this apparent lock contention. Naively, I ran xctrace record --template 'Time Profiler' --output output.trace --launch /Users/dbarsky/.cargo/bin/cargo-nextest nextest run, and while that detected all processes spawned by nextest, it didn't record all processes as part of the same inspectable profile and didn't really show any frames from the kernel/APFS—I had to select individual processes. So I don't waste people's time and so that I can point a frame/smoking gun in the right system, how can I can use instruments to profile where the kernel and/or APFS are spending its time? Do I need to disable SIP?