Jump to content

MacKonsti

Members
  • Posts

    575
  • Joined

  • Last visited

Reputation

106 Excellent

2 Followers

Profile Information

  • Gender
    Male
  • Location
    Muppet Show

Contact Methods

  • Website URL
    http://mackonsti.wordpress.com/

Recent Profile Visitors

6,599 profile views
  1. Thanks @deeveedee just to confirm to everyone else here too, that I also disabled completely the SSDT-SBUS.aml in OpenCore config on my NUC10i7FNH (Core i7-8700B @ 3.20 GHz) declared as MacMini8,1 and rebooted. Even let it sleep. I still get both kexts being active on Ventura; but indeed on IOReg, there's no longer a tree under device SBUS. My device is according to "lspci -nn" 00:1f.4 SMBus [0c05]: Intel Corporation Comet Lake SMBus Host Controller [8086:02a3] $ kextstat | grep -E "AppleSMBusController|AppleSMBusPCI" Executing: /usr/bin/kmutil showloaded No variant specified, falling back to release 157 0 0xffffff7f958a9000 0x1000 0x1000 com.apple.driver.AppleSMBusPCI (1.0.14d1) 3B3CBC6F-07BD-3D7E-9F2F-D738A31C290D <17 7 6 3> 165 1 0xffffff7f9589d000 0x6ffd 0x6ffd com.apple.driver.AppleSMBusController (1.0.18d1) 18305D5D-1310-37BC-B654-6C034FD346E7 <164 17 16 7 6 3> I will keep using it and see if I detect anything noticeable. Thanks to everyone.
  2. Thank you again for your input and feedback @deeveedee! The question is... what about the other macOS versions, did you notice the same behaviour? Does this thing do anything by not loading, eventually...? com.apple.driver.AppleSMBusPCIcom.apple.driver.AppleSMBusController We share the same hardware between my Intel NUC8 / NUC10 and your HP Elite 800 G4/G5 (if not mistaken) so you got me thinking...
  3. Hello everyone, hope you are all well. The thread has been silent--is it abandoned? I've been meaning to post in the last days... Has anyone figured out how to solve this Volume Hash Mismatch error? I am running latest Monterey with a PNY XLR8 NVMe (Model CS3030) that seemingly has a Phison E12 controller... 1. I tried to make a checklist to exclude factors, perhaps one can help enhance it ? NVMeFix.kext is not used/loaded ✅ FeatureUnlock.kext is not used/loaded ✅ Using an Intel Wi-Fi/BTLE combo (embedded in my NUC) module ✅ Using a carefully crafted USBPorts.kext with mapped USB ports ✅ Samsung NVMe disks (e.g. 970 EVO) is not installed or used as primary OS drive ✅ 2. The USBPorts.kext has the correct internal port for BTLE set as 255 ; I also tried later to set another internal port (some Internal USB-C alias) as 255 but to no avail. 3. I had stopped using the suspected BlueToolFixup.kext but I had the error eventually. Obviously, BTLE stopped working. 4. The error popped up yesterday when I plugged my iPhone on the front USB port of the Intel NUC that I have. For almost a month (including latest Monterey updates) it did not appear ALTHOUGH I have not been using BTLE or Wi-FI. 5. Any idea what the setting in OpenCore should be under UEFI → ProtocolOverrides → HashServices eventually? FALSE or TRUE ? I am confused, to be honest. I am not using FileVault2 (according to the OpenCore manual PDF) but my CPU is "Haswell or newer", could this be eventually affecting this error ? 6. Any other possible reason? Some NVME value... or kext? I have compiled this check-list in my repo, thanks in advance for your help!
  4. Yes I will obviously stop using AppleALC and replace it with VoodooHDA Do I need to still rename HDEF too HDAS? Apologies, I should have stressed this point, of removing-disabling AppleALC obviously.
  5. Hi @Slice thank your for your continuing work on VoodooHDA I am using AppleALC but would like to try VoodooHDA 3.0.2 on Monterey, so allow me a couple of quick questions: a) can I use VoodooHDA 3.0.2 with OpenCore now? Or do I need to still install it on /L/E and set system permissions to allow kexts? b) My Intel NUC8i7BEH has HDEF as definition of the device; should I rename it to HDAS via OpenCore DSDT patching? Or will it work as HDEF natively? My controller is Realtek ALC235 [0x10EC0235] hopefully compatible. c) The labels of the inputs/outputs as they are shown in System Preferences > Sound are they easily changeable? (just curious) Many thanks!
  6. Hi @deeveedee I can suspect that the IORegistry is not created the same way when VoodooHDA is used thus Hackintool may not detect the right branches or devices etc. But as you say, I am also curious to know, if it was ever attempted to code it to detect VoodooHDA (not used as much as AppleALC I guess?) Why don't you post a screenshot of your IORegistry Explorer or better, a sanitised export of IORegistryExplorer (without S/Ns if possible?) so that @headkaze can comment? (just a tip )
  7. I can only suspect yet another means of reading/enumerating the ports on Ventura that Hackintool hasn't caught up yet... What is important @deeveedee is that the generated USBPorts (on Monterey I assume, and you kept using it) is working on Ventura OS well. Could that be it @headkaze? (and thanks from me too, once more, for the great tool!)
  8. Hi @Drovosek not sure if you're the same person as in https://github.com/Drovosek01/ but good to find you here. I have the same issue with my Intel NUC8, there doesn't seem to exist a parameter/tag/text "CFG" or "Lock" or "CPU" on my firmware's NVRAM, either. This means that the BIOS/firmware of the motherboard does not expose this parameter at all... at least not in NVRAM. So its likely hard-coded in the microcode of the firmware... Sorry What's worse is that BIOS/firmware updates can also LOCK this value even if it's exposed. This happened on my Intel NUC10; I used to be able to change it, but after latest BIOS update, it's switched to read-only value <facepalm>
  9. Agreed, on most recent systems with newer firmwares/BIOS, the Prepare-to-Sleep (PTS) code is working just fine without the need to inject that old argument. Rehabman's work in the past was amazing but don't forget, he was addressing equally older hardware e.g. 3rd or 4th generation CPUs. So all old hacks, in my view, may not even be considered (I cannot comment for AMDs however). I tried to get to a minimum of settings on bootloaders so that they are easier to maintain as hacks, especially for me, to be honest. Except for laptops that could be another nightmare, sometimes, desktops appear to need less tweaking. But learning comes from tweaking of course Don't jinx it yet (for Apple dropping macOS)
  10. Hi @deeveedee I remember from old readin' that the XOSI was mainly helpful to get the PC to behave like Windows, and most notably regarding the internal ports for BTLE. Some people's PCs were not showing up internal BTLE or USB ports if not using XOSI. Some others could be related to sleep as some darker ACPI features we don't know about weren't used (on non-Windows ) On my Intel NUC, I have not seen any other behaviour with or without XOSI. I did start with it, of course, but after disabling it, I have not noticed any other behaviour. It is true that some BIOSes or Firmwares have some other code run/performed if it's not a Windows OS running -- but it has never been clear nor statistically proven (by the majority of users, for example) as to what this really offers. Perhaps in modern bootloaders, it's obsolete. Who knows... except those who master ACPI Just my 5cents
  11. Hello everyone, thanks for your tireless efforts to get Ventura working, as with Monterey last year, it's very appreciated. For us that wish to remain a little conservative and won't update so fast, macOS or Clover, is the new release r5148 destined to replace a good working r5146 ? @Slice ? I use it for both Catalina and Monterey on 2 different hackintoshes. I know they say if it works, don't upgrade but... 😂 🤣 Thank you again everyone.
  12. Hi @verleihnix thanks for this, I also have UHD620 on my Lenovo IdeaPad S145-14iWL laptop with device ID [8086:3ea0]. I use 0x3EA50009 for accelleration on my machine. Can you please be so kind and provide fuller information about your hardware especially the UHD 620 graphics IDs? Which ID do you inject for acceleration? Thanks
  13. As @vit9696 wrote in that ticket reply among other things "Apple GuC, enabled exclusively by igfxfw=2 boot argument and disabled by default is bugged, and will eventually lead to IGPU locking at high frequency." so once I read this last year, I dropped the boot-argument completely. This is very useful information hidden in some bug ticket reply, so it's a shame that this is not mentioned in the main WhateverGreen page on GitHub so that people stop using it. @vit9696 perhaps you can update the README.md file there?
  14. Happy I could help, really. Shame, if I had posted this before I had my dinner, I could have saved you the trouble of creating that other thread, LOL But as vit9696 wrote "Apple GuC, enabled exclusively by igfxfw=2 boot argument and disabled by default is bugged, and will eventually lead to IGPU locking at high frequency." so once I read this last year, I dropped the boot-argument completely. Shame he or the other developers that have access to the WhateverGreen official GitHub page don't mention this, it is very useful information hidden in some bug ticket reply!
×
×
  • Create New...