Problem phenomenon: We have developed a third-party NVMe I/O kit driver for HighPoint NVMe Controller, which runs normally on macOS 11.x and previous version. But the command timeout will often appear when testing on macOS 12.0.1 system. Problem analysis: The Create Device Interrupt (MSI) function failed to return, and causing the command to time out. The following is part of the code, NULL Pointer is returned: ies = IOInterruptEventSource::interruptEventSource (this, &RSNVMeController::interruptOccurred, PCIProvider,index ); Question: We would like to consult why Create Device Interrupt (MSI) failed and how to fix the issue??? Note: We suspect that the Inbox NVMe driver may create a device interrupt for the third-party NVMe device when the system is started, but sometimes it may not be released interrupt in time due to some reasons on macOS 12.0.1, causing other third-party NVMe drivers to fail to create an interrupt for the NVMe device. We tracked the difference between 11.6(OK) and 12.0.1(NG) regarding NVMe driver loading: macOS11.6: IONVMeFamily driver will Attach&Probe&Start for all NVMe devices(including Apple NVMe device and Third-Party NVMe device). macOS12.0.1: IONVMeFamily driver will Attach&Probe&Start for all NVMe devices(including Apple NVMe device and Third-Party NVMe device). If a third-party NVMe driver is found, IONVMeFamily driver will terminate and Detach from Third-Party NVMe device; IONVMeFamily driver will Attach&Probe&Detach for third-Party NVMe device. HighPoint Third-Party NVMe driver will Attach&Probe&Detach for Third-Party NVMe device.Select HighPoint Third-Party NVMe driver to Start, because its probe score is larger than IONVMeFamily driver. At present, it is suspected that the IONVMeFamily driver may attach/detach the third-party NVMe device multiple times in macOS 12.0.1, which will cause some interrupt resources to not be released in some cases. Of course this is just a guess… STEPS TO REPRODUCE Insert 4 NVMe devices to HighPoint SSD7505 NVMe controller Plug SSD7505 to MacPro 2019 Enter into macOS 12.0.1 Install HighPoint NVMe driver Reboot OS Copy data to NVMe device

We are implementing a Sample Partition Scheme driver. this is the info.plist <key>IOKitPersonalities</key> <dict> <key>SamplePartitionScheme</key> <dict> <key>IOKitDebug</key> <integer>0</integer> <key>IOProbeScore</key> <integer>80000</integer> .... <key>IOProviderClass</key> <string>IOMedia</string> <key>IOPropertyMatch</key> <dict> <key>Whole</key> <true/> </dict> </dict> </dict> our driver match a whole disk IOMedia, If it's our disk, perform read/write on this disk. When we test our driver in macOS12. if the IOMedia is a blank RAW disk, our driver will be loaded at boot time. if the IOMedia has partitions, system partition scheme driver will be loaded at boot time. Pluging in a GUID partition disk on a booted Mac always load our kext. how can our driver match GUID partition disks and load at boot time?

I use macPro 2019. The problem is with my NVMe RAID controller. It uses its own driver instead of the system's NVMe driver. In the macOS 13 system, after installing the driver and restarting the system, during the startup process, the driver has a "vtd fault" error when loading, causing the driver to fail to initialize. My driver works fine on macos11/12. I upgraded my system to the latest macOS 13 beta and the problem appeared. The error message is as follows: vtd[0] fault: device 83:0:0 reason 0x6 R:0x101700000 A vtd fault error means that the pcie peripheral has accessed a physical address of memory that should not be accessed. After debugging, I found out that address 0x101700000 is exactly the physical address of the memory range my driver allocated. In my driver, I allocate memory buffers like this: IOBufferMemoryDescriptor::inTaskWithPhysicalMask(current_task(), kIODirectionOut | kIODirectionIn | kIOMemoryPhysicallyContiguous, (mach_vm_size_t)size, ~((mach_vm_address_t)(alignment - 1))); Then allocate the IODMACommand object: IODMACommand::withSpecification(kIODMACommandOutputHost64, 64, 0, IODMACommand::kMapped, 0, alignment, NULL); Then get the physical address of the buffer: dmaCommand->setMemoryDescriptor(memDesc) dmaCommand->gen64IOVMSegments(&offset, &segments[0], &numSeg); When the pci peripheral reads this address, a vtd fault occurs. Later, I plugged the NVMe RAID controller into a thunderbolt box, then started macos, and after entering the system, I used Thunderbolt-capable to connect the box to the macPro. At this time, the NVMe RAID driver could be loaded normally without vtd error. vtd fault occurs only when the system starts. How to solve this problem?