JakubW

Slowly I'm beginning to think, that the PCi bridge in the FW card is the cause of the issues, in spite it working with older kexts on Mojave and Catalina. I did try 2 cards, one with VIA chipset and one with TI chipset, but both have the bridge. Will maybe look for a one without the PCI bridge and check.

I researched and UAR1 seems to be the Serial Port, it is already disabled in the BIOS, also, when I tried to disable it with a couple of methods, I got hard crashes, KP report below: panic(cpu 0 caller 0xffffff800d7abf7d): CPU 15 has no HPET assigned to it Backtrace (CPU 0), Frame : Return Address 0xffffffa0b8c03c60 : 0xffffff800c28cfdd mach_kernel : _handle_debugger_trap + 0x3fd 0xffffffa0b8c03cb0 : 0xffffff800c3d3fd3 mach_kernel : _kdp_i386_trap + 0x143 0xffffffa0b8c03cf0 : 0xffffff800c3c45ca mach_kernel : _kernel_trap + 0x55a 0xffffffa0b8c03d40 : 0xffffff800c231a2f mach_kernel : _return_from_trap + 0xff 0xffffffa0b8c03d60 : 0xffffff800c28c7fd mach_kernel : _DebuggerTrapWithState + 0xad 0xffffffa0b8c03e80 : 0xffffff800c28caf3 mach_kernel : _panic_trap_to_debugger + 0x273 0xffffffa0b8c03ef0 : 0xffffff800ca9cdca mach_kernel : _panic + 0x54 0xffffffa0b8c03f60 : 0xffffff800d7abf7d com.apple.driver.AppleIntelCPUPowerManagement : _pmInitThread + 0x2c7 0xffffffa0b8c03fa0 : 0xffffff800c23113e mach_kernel : _call_continuation + 0x2e Kernel Extensions in backtrace: com.apple.driver.AppleIntelCPUPowerManagement(222.0)[8B50AF31-4BF1-3BF1-81BD-BA02CFE3DDAB]@0xffffff800d7a6000->0xffffff800d7c2fff Process name corresponding to current thread: kernel_task Boot args: -v keepsyms=1 debug=0x100 darkwake=0 npci=0x2000 chunklist-security-epoch=0 -chunklist-no-rev2-dev chunklist-security-epoch=0 -chunklist-no-rev2-dev Mac OS version: 20G165 Kernel version: Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 Kernel UUID: C2591F4E-EE82-33CC-8C59-DB81D9AD80DD KernelCache slide: 0x000000000c000000 KernelCache base: 0xffffff800c200000 Kernel slide: 0x000000000c010000 Kernel text base: 0xffffff800c210000 __HIB text base: 0xffffff800c100000 System model name: MacPro6,1 (Mac-F60DEB81FF30ACF6) System shutdown begun: NO Panic diags file available: YES (0x0) Hibernation exit count: 0 System uptime in nanoseconds: 92425050121 Last Sleep: absolute base_tsc base_nano Uptime : 0x0000001584f664c8 Sleep : 0x0000000000000000 0x0000000000000000 0x0000000000000000 Wake : 0x0000000000000000 0x00000033136bd172 0x0000000000000000 Anyway, I swapped the cards, so they take up other slots and now the FireWire cards takes IRQ 11. I removed it from HPET and it takes 0, 2, 12 and 15, HDAU takes 4 or 5, so there seems not to be any conflicting IRQs ATM, but FireWire fails to load anyway.

UAR is already disabled? Entry from DSDT Method (_STA, 0, NotSerialized) // _STA: Status { Return (^^SIO1.DSTA (Zero)) }

STA method in SSDT for example?

I found multiple values in UAR1, that have Benn blocked, including 3 and 4. Anything we could do, e.g. disable it and inject it again via SSDT with no IRQNOFlags? urrent Legacy IRQs: - SIO1: [] - PS2K: [1, 1] - PS2M: [12, 12, 12] - UAR1: [4, 3, 4, 5, 6, 7, 10, 11, 12, 3, 4, 5, 6, 7, 10, 11, 12, 3, 4, 5, 6, 7, 10, 11, 12, 3, 4, 5, 6, 7, 10, 11, 12] - PIC: [2] - TMR: [0] - RTC0: [8] - COPR: [13]

Yep, on Mojave it picks 04 in the HDAU segment of the GPU. I also saw, you moved the HPET to SBRG in the DSDT, did the same with an SSDT, now the boot is stable again. When I leave the OEM HPET and add patches to it, the system hangs, total freeze

More and more I suspect, that the interrupt specifies, starting with 03 cause the issue, it may be related to the HPET as well IRQ 2.zip

his SendMe is from the boot, were the Firewire auto interface got enabled, the boot log shows the same error, so there must be something else pointing to issues with launchingg the audio interface. Anyway the interface rather won't load. There were also issues with the SSDT, so I switched back to the DSDT https://drive.google.com/file/d/15a55IGV9fk93S_Mmn5MqKLNnHVD8jnWj/view?usp=sharing Send me Jakubs-Mac-Pro.zip

And here the IOReg https://drive.google.com/file/d/1CGJmob-vdVf8Q4yOeI6qbOAH76yU7E5K/view?usp=sharing I have an impression there is an IRQ conflict between HDAU and FRWR IRQ.zip

After updating to 11.6 it got better. the device loads the driver, but is stutter, after a reboot it doesn't"t load. Note on ACPI I now use SSDTX79ZD3.aml instead of the DSDT (as You also did in the EFI folders) Send me Jakubs-Mac-Pro.zip And here the IOReg https://drive.google.com/file/d/1CGJmob-vdVf8Q4yOeI6qbOAH76yU7E5K/view?usp=sharing

Allright, another update on mz CPU. I removed Plugin Type from the CPU SSDT and generated SSDT Plug. Works better with Big Sur. I also had issues with updating to newer build. The fix with older FireWire kexts caused kernel panics and /I had to sort out the Unicore Bridge, use a DSDT patch in OC, but I still can't get FireWire Audio working on Big Sur. I'am afraid I will have to delete the kexts form the OS and load older ones from OC, but it doesn't seem to be a good solution in the long run. Saw this in Verbose Boot and Boot Log: 2021-09-24 02:01:38.037853+0200 0x897 Default 0x0 0 0 kernel: (AppleFWOHCI) AppleFWOHCI_DescriptorPool::create - link = <private> 2021-09-24 02:01:38.049394+0200 0x897 Default 0x0 0 0 kernel: (AppleFWAudio) AM824NuDCLRead::Start() failed: 0xe00002d4 2021-09-24 02:01:38.057864+0200 0x897 Default 0x0 0 0 kernel: (AppleFWAudio) AppleFWAudioDevice::initHardware error StartAllStreams 2021-09-24 02:01:38.065788+0200 0x897 Default 0x0 0 0 kernel: (AppleFWAudio) AppleFWAudioDevice[<private>]::initHardware() Error!!! something wrong in initHardware calling cleanUpResources() status=<private> 2021-09-24 02:01:38.076060+0200 0x897 Default 0x0 0 0 kernel: (AppleFWAudio) AppleRemoteAudioDevice[<private>]::initHardware(<private>) failed Will compare with Catalina.

I checked that devices, that require more than 100 mA of current are stable and those at 100 or less have enumeration issues. SO there is an issue with low poerr device rather than the speed. It may be a power issue as this article suggests: https://www.cnet.com/news/tackling-a-usb-device-enumeration-error-in-os-x/ I have an impression, tie IO Probe score needs to be adjusted, but do't know how to approach it TBH

It turns out the plugin type needed to be added to the SSDT, now X86 PlatformPlugin is loaded, had to generate custom aml with these args ./ssdtPRGen.sh -p 'E5-2670' -x 1 -target 0 -c 3 -cpus 1 -l 8 -mode custom -d 3 USB 1.1 enumeration issue still present

got improvements on SSDT and loading x86 platform plugin, now it is loading correctly and Mac single core turbo is displayed correctly. To generate it I sues the script with following attributes ./ssdtPRGen.sh -p 'E5-2670' -x 1 -target 0 -c 3 -cpus 1 -l 8 -mode custom -d 3 You need to extract amps from your motherboard and copy APIC.aml to your desktop.

After looking in Windows via USBDevview, I got another conclusion, all the affected devices are USB 1.1, so maybe the legacy hub should be triggered somehow.