BillDH2k Posted October 17, 2022 Share Posted October 17, 2022 (edited) Ok. I took a copy of the original DSDT, modified the CPU definition tables, by removing SCK1, SCK2, SCK3 related entries, and only kept SCK0. Made a few more changes to emulate the ACPI patches currently done with my current setup, such as IRQ 0, 8 zapping, and HPET._CSR to XCSR rename. My understanding were these ACPI patches will apply only to the original DSDT, but not to user added ssdt/DSDT codes. Next, I added the patched DSDT to config.plist, disabled all ACPI patches, ACPI->delete->"Dropped PmMgt table", added s trimmed down version of ssdt-1.aml (this is the dropped PmMgt table) with SCK1-SCK3 entries removed, then reboot the machine. Results: I was able to boot up Big Sur, just like before. But not Monterey - continue to encounter similar kernel panic message (see attached picture). I could tell that the patched DSDT indeed made the intended change to the system. IORegistryExplorer showed the difference before and after. IORegistry - with original DSDT (4 duplicated CPxx, one of reach socket): IOResigtrey - DSDT overwrite with patched DSDT (Only one CPxx set left): Also, the kernel panic message was complaining about CPU0, while previously it was CPU2. Here is the screen capture of the panic message: I am stuck now. Not sure why T5810 is so different from HP Z440, though both use the same C612 chip. Many part of the DSDT codes appear the same btw the two systems. Dell custom codes some how confused the Monterey. Edited October 17, 2022 by BillDH2k Link to comment Share on other sites More sharing options...
BillDH2k Posted October 19, 2022 Share Posted October 19, 2022 (edited) I googled more on "Kernel panic on Non-monotonic Time". It seemed that the root cause appeared to be Dell's BIOS not initializing the CPU cores with TSC sync, causing Monterey to kernel panic. No fix is available right now, since this happened in the earlier booting before CpuTscSync.kext's intervention. HP Z440 BIOS, however, properly initialized the TSC synch, thus no CpuTscSych.kext, or the like, is needed. May be some smart guy could figure a way to synch TSC, say an EUFI tool, before booting macOS. Edited October 19, 2022 by BillDH2k Link to comment Share on other sites More sharing options...
Slice Posted October 20, 2022 Share Posted October 20, 2022 14 hours ago, BillDH2k said: I googled more on "Kernel panic on Non-monotonic Time". It seemed that the root cause appeared to be Dell's BIOS not initializing the CPU cores with TSC sync, causing Monterey to kernel panic. No fix is available right now, since this happened in the earlier booting before CpuTscSync.kext's intervention. HP Z440 BIOS, however, properly initialized the TSC synch, thus no CpuTscSych.kext, or the like, is needed. May be some smart guy could figure a way to synch TSC, say an EUFI tool, before booting macOS. VoodooTSCSync As well you may use TscSyncTimeout quirk together with this kext. More... may be you have to edit your ACPI (DSDT or SSDT related to CPU). Link to comment Share on other sites More sharing options...
BillDH2k Posted October 21, 2022 Share Posted October 21, 2022 18 hours ago, Slice said: VoodooTSCSync As well you may use TscSyncTimeout quirk together with this kext. More... may be you have to edit your ACPI (DSDT or SSDT related to CPU). I had tried VoodooTSCSync from your recommended link, with TscSyncTimerout quirk, and it made no difference (see my reply on Oct 16). As to the root cause, below were the comments I copied from one fo the OC developer's BugTracker for this related issue. My understanding, if correct, is that the booting issue is hard to fix due to Monterey's new design. And I have not seen a solution yet. Please share your insight on this matter. Number of Dell systems are facing this problems (T3610/5610 - Ivy CPUs, T5810 - Haswell Cpus). https://github.com/acidanthera/bugtracker/issues/1676#issuecomment-881884751 vit9696 commented on Jul 17, 2021 Well, the situation unpleasant. The root cause of the issue is that on macOS 12 CPU registration comes in parallel with many other things, so SMP support (hardware multithreading) is initialised even before all the CPU cores are initialised. Normally the solution is to wait for all CPUs to register, then perform the TSC sync on them. Now it is no longer feasible, since whenever even just 2 CPUs register, we already have multithreading and potentially a kernel panic. I am not quite sure how to address it best. https://github.com/acidanthera/bugtracker/issues/1676#issuecomment-881900469 vit9696 commented on Jul 17, 2021 @wy414012, yeah, I am aware. I do not believe server CPUs with bugged firmware will be compatible with macOS 12. (My note: he was referring to the booting case with TSC kernel panic). https://github.com/acidanthera/bugtracker/issues/1676#issuecomment-882106156 vit9696 commented on Jul 18, 2021 acidanthera/CpuTscSync@2fa443a ← this will work on most laptops with sleep support. I will need some time to polish and clean it up before it can be merged to master though. Still nothing for the Xeon CPUs. Link to comment Share on other sites More sharing options...
Slice Posted October 21, 2022 Share Posted October 21, 2022 vit9696 told about CpuTscSync which is not working in Monterey while my Xeon (IvyBridge-E5) is good working in my conditions: TscSyncTimeout+VoodooTSCsync+DSDT_patch. Link to comment Share on other sites More sharing options...
BillDH2k Posted October 21, 2022 Share Posted October 21, 2022 (edited) 8 hours ago, Slice said: vit9696 told about CpuTscSync which is not working in Monterey while my Xeon (IvyBridge-E5) is good working in my conditions: TscSyncTimeout+VoodooTSCsync+DSDT_patch. Thank you for your reply. In your case, were you able to successfully boot, at a minimum, without any TSC Synch kext, under Monterey? My T5810 was able to boot under Big Sur without any TSC kext. The system was sluggish, of course, due to TSC synch problem, which can be subsequently fixed with use of CpuTscSync.kext or VoodooTSCSync.kext. Under Monterey, T5810 could not boot at all, since the kernel panic occurred before any user injected TSC kext had a chance to intervene (if vit9696 is correct). As to the patching of DSDT, I have no idea what part of the DSDT could impact TSC synch, during booting. I had tried to patch out used CPU tables, as you suggested, without success. Edited October 21, 2022 by BillDH2k Link to comment Share on other sites More sharing options...
Slice Posted October 22, 2022 Share Posted October 22, 2022 17 hours ago, BillDH2k said: Thank you for your reply. In your case, were you able to successfully boot, at a minimum, without any TSC Synch kext, under Monterey? My T5810 was able to boot under Big Sur without any TSC kext. The system was sluggish, of course, due to TSC synch problem, which can be subsequently fixed with use of CpuTscSync.kext or VoodooTSCSync.kext. Under Monterey, T5810 could not boot at all, since the kernel panic occurred before any user injected TSC kext had a chance to intervene (if vit9696 is correct). As to the patching of DSDT, I have no idea what part of the DSDT could impact TSC synch, during booting. I had tried to patch out used CPU tables, as you suggested, without success. See here Link to comment Share on other sites More sharing options...
BillDH2k Posted October 23, 2022 Share Posted October 23, 2022 (edited) @Slice I have checked the interesting thread you mentioned above. I am afraid it is an unique solution to that motherboard/BIOS only (X79, Sandy/Ivy CPUs). T5810 (X99, Hanswell/Broadwell CPUs) appeared to have a different BIOS code base, as the similar ACPI codes are not present in the DSDT. For example, T5810's DSDT only have the following blank declarations: But I went ahead and made the changes to the DSDT, by inserting the "missing" codes: Made the changes for each CPxx's (using _CID name, "PCI0-CP0xx", accordingly). Also, removed any unused CPxx's, together with a few other necessary changes (as I described in my earlier post). One thing about the CpuPm, I've tried the BIOS's own version (trimmed without redudent CPU entries ), as well as a version created with ssdtPRGen (Note: I am not 100% sure if this PM custom code was actually used by macOS in the platform!). Then, loaded this DSDT and reboot. Results: Same kernel panic while booting Monterey. No problem booting Big Sur. Tried both with and without VoodooTscSyc, with TscSyncTimeout quirk (525000). So, my conclusion is that this is more related to the DELL BIOS, for not initializing the TSC Sync properly, which was finally caught up by the new Monterey design. Other similar X99 systems, like HP Z440/840, and Supermicro Boards (I own X10DAL), do not have any booting problems with Monterey. Edited October 23, 2022 by BillDH2k Link to comment Share on other sites More sharing options...
BillDH2k Posted November 5, 2022 Share Posted November 5, 2022 This TSC sync problem with DELL T5810 (possibly apply to other systems) was finally resolved. See link here. Link to comment Share on other sites More sharing options...
Recommended Posts