Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


vit9696 last won the day on September 20

vit9696 had the most liked content!

About vit9696

  • Rank
    InsanelyMac Sage

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. vit9696

    VirtualSMC — SMC Emulator

    @SavageAUS, could you please remind me what the kernel panics are? Are you sure they are VSMC related? I do not think SMCBatteryManager could be reworked as a Lilu plugin, as modern MacBooks expose battery information via SMC, and this is what SMCBatteryManager does.
  2. vit9696

    WhatEverGreen Support Topic

    @TheBloke, you need PP,PP_BootupDisplayState to override the value. Check the FAQ more carefully. I doubt it will help unfortunatly though.
  3. vit9696


    Could be, I guess. It is very hard to believe, to be honest. You can probably ensure it by asserting that NumEntriesLeft is 0 by the end of this function: https://github.com/acidanthera/AptioFixPkg/blob/6a21a30d090721ff4620dd22bb91d4dca93e8db4/Platform/AptioMemoryFix/RtShims.c#L302
  4. vit9696

    VirtualSMC — SMC Emulator

    @Andres ZeroCross, I believe you have outdated Lilu SDK. @nms, sure, releases need thorough testing, and we try to release things simultaneously and not very often to avoid people having to upgrade many times. The next update will have to arrive close to 10.14.1, as there are certain breaking issues. The reason we do not hurry at present is that 10.14.0 works fine, and we still want to at least try to land some important changes in the current release.
  5. vit9696


    Good to have. Well, the second picture makes it very clear. XNU kernel invokes APTIO RuntimeServices SetVariable code, and then this code never returns. What we have in SetVariable is the following code coming from NvramDxe, I can tell that it did not change anyhow since the source leak, and the one in the source leaks are known to work. The code relevant to SMM switching looks the same too, and EFI_SMM_COMMUNICATION_PROTOCOL implementation is provided by EDK2. They still allocate the SMM communication buffer as EfiRuntimeServicesData, and still pass its address via NvramMailbox NVRAM variable, so it should be guarded by AptioMemoryFix. As a result I believe that the infinite loop happens somewhere on the way to NvramSmm (which now represents former Smi and Smm code glued together). However, the brief checking of the binary and the source shows that the Smi handler (NvramSmmCommunicationHandler, SetVariableSmmHandler) is pretty much the same too. This leaves us in an uneasy situation, where we do not know where to look for the problem. What I could suggest is writing a EFI runtime driver (by ripping off the known APTIO V source) that will reimplement communication with SMM: 1. Allocate a new communication buffer. 2. Check & overwrite the address of the old communication buffer in MailBox variable 3. Overwrite EFI_RUNTIME_SERVICES Variable functions with APTIO code but the new communication buffer. The above will result in having a complete path prior to SMM code under our control. Afterwards we should be able to get this code fully functional on some working APTIO V system (e.g. Skylake or Kaby Lake), and try it on the new problematic system. By changing the logic via the return codes it should be easy to ensure where the issue is: DXE or SMM driver. Other than it may even help us to understand whether the SMI handler exists at all. If it is SMM, I would probably try replacing NvramSmm with NvramSmm & NvramSmi from some Z370 BIOS first and reflashing the firmware. Then… perhaps reverse-engineer/reimplement NvramSmm with the new changes and try to debug it too. If you like the idea, I can share APTIO src and let you proceed.
  6. vit9696

    AppleALC — dynamic AppleHDA patching

    Ugh, noticed that you have GT 210, while the issue still holds, I do not think there is an up to date manual for anything below Kepler on applelife. Furthermore, I am not sure whether GT 210 works without injecting properties, so it is the matter of either reverting the GPU patches entirely (you would have done that for Kepler and newer) and leaving the things to NVIDIA drivers and WhateverGreen, or actually fixing up them. I believe what you could try first is booting without without the GPU patches, and if it fails, using Clover's NVIDIA Inject might work best for this hardware.
  7. vit9696


    If you want to help us with the panic, please redo it properly as suggested above.
  8. vit9696


    Well, the guard prints at vm_map_delete are most likely work in progress for improving the vm_map unexpected situation detection. It is very unlikely that it has anything to do to us. I believe without debug=0x100 you should be able to see the panic, but I suppose it could be the same.
  9. vit9696


    Well, try gradually lowering the value then. From slto_us=250000 and onwards, could divide by 2.
  10. vit9696


    Hmmm, a timeout… There could be some infinite loop in their code. But let's try to disable the timeout first. Add slto_us=0 to boot-args and tell me whether anything changed.
  11. vit9696


    It depends on the GUID you write to, from what I remember. If you write to apple guid, then they are applied on later onwards, otherwise immediately. That is how I got the idea of their NVRAM driver.
  12. vit9696


    Well, with the random reboots there is no real issue indeed, just NVRAM variable saving once again corrupts our memory. I believe, if you try to write a lot of variables from macOS the operating system will eventually panic. That could have been somewhat usable if you were able to get the log dumps, but otherwise it is probably not beneficial. Basically what needs to be done here now is reverse-engineering NvramSmm/NvramDxe and comparing them against the previous versions, which we fortunately have sources for. I do not think I will have much time any soon for that, so if you have time and are able to use IDA Pro/Hex-Rays, help will be welcome here.
  13. vit9696


    Hi Pene, I am aware of this issue, but as you can imagine I do not have the hardware to research it. What happened here is another change in APTIO. In former versions there were 3 drivers to implement NVRAM: NvramDxe, NvramSmm, NvramSmi. In newer boards NvramSmi and NvramSmm became one driver. I believe we can try to research this to a certain level with a considerable amount of help from your side. Frankly said, I am not sure Hardware NVRAM works on these boards in any OS at all, so the first step would be to: 1) Test NVRAM support in UEFI Linux, I believe they have a tool for this 2) Test NVRAM support in UEFI Windows, you will have to write some tool that elevates the privileges and utilises GetFirmwareEnvironmentVariableA/SetFirmwareEnvironmentVariableA APIs, see this tool for an example. The "test" we want here is fairly simple. Firstly we want to try to write some variable to Apple Boot Variable GUID: 7C436110-AB2A-4BBB-A880-FE41995C9F8, then read it, reboot, and read again. If it all fails, we could try writing to Efi Global Variable GUID: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C, and check if it at least some GUIDs are available for writing. Next, the kernel panic on reboot is what really worries me. We know that macOS writes stuff to NVRAM during the reboot, and I would like to know if disabling SetVariable/GetVariable, GetVariableNext "fixes" the problem with the reboot. Just like we debugged it previously, write jmp ASM_PFX(RtShimsReturnInvalidParameter) to the relevant shims here for a test: https://github.com/acidanthera/AptioFixPkg/blob/master/Platform/AptioMemoryFix/X64/AsmRtShims.nasm Thirdly, regarding the panics on reboot, I would like to get as much information as possible. Please apply the kernel patch mentioned here: https://applelife.ru/posts/686953, which disables kext list printing in the panic log, and try screening the kernel panic in -v keepsyms=1 debug=0x100 mode. We should hopefully see more data to stat to work with. @Slice, unfortunately this one is new. These guys never learn, and they managed to bork things once again. So it is neither the issue we researched a year ago, nor the whitelist. It is just another extension of the borked code. Vit
  14. vit9696

    Lilu — kext and process patcher

    Committed a fix to this, sorry.
  15. vit9696

    WhatEverGreen Support Topic

    Sigh… I have already told you to try disabling AGDP patches, but I guess nobody understood it. WG currently automatically disables AGDP (AppleGraphicsDevicePolicy) support on all the boards with discrete GPUs, because it leads to AMD visual glitches in Mojave, breaks multimonitor support on both AMD and NVIDIA, and may result in blackscreen with NVIDIA on several models. Indeed, it may result in some features being disabled, and for this reason there is a way to configure this via agdpmod boot argument. By default it works as if you wrote "agdpmod=pikera,vit9696" but you may write agdmod=none to get the behaviour of the original kext. The values are listed here: https://github.com/acidanthera/WhateverGreen#boot-arguments Also watch out for CFG_USE_AGDC property, see details in the bottom of: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.Radeon.en.md