Contribute
Register

Help - Ventura Freezing at Login

@medianjoe That would be IntelMausi.kext?



Just confirming the highlighted rows below are the ones I would delete, correct?

View attachment 557485

When I delete those rows and try to save I get the spinning beach ball of death. :(

I deleted from [Reserved Memory Region] to the end of PCI Path : ****. Mine had two of [Reserved Memory Region] blocks.
 
If you used Hackintool to dump your ACPI tables it will have generated a DMAR.dsl along with copies of all the ACPI tables in your setup. You should use the DMAR.dsl to create your edited SSDT-DMAR.aml

Never edit a *.aml table and try to compile it, as this won't work. You have to use disassembled tables for any editing purposes.
 
I deleted from [Reserved Memory Region] to the end of PCI Path : ****. Mine had two of [Reserved Memory Region] blocks.
Thanks, @medianjoe... I'll try that... what about the IntelMausi.kext? Is that the Monterey driver I don't need?

Edhawk said:
If you used Hackintool to dump your ACPI tables it will have generated a DMAR.dsl along with copies of all the ACPI tables in your setup. You should use the DMAR.dsl to create your edited SSDT-DMAR.aml

Never edit a *.aml table and try to compile it, as this won't work. You have to use disassembled tables for any editing purposes.

Thanks, again, @Edhawk I used maciASL, as medianjoe suggested. But, yes, I was trying to edit an .aml file. I know what to do now. Thanks again.
 
If you used Hackintool to dump your ACPI tables it will have generated a DMAR.dsl along with copies of all the ACPI tables in your setup. You should use the DMAR.dsl to create your edited SSDT-DMAR.aml

Never edit a *.aml table and try to compile it, as this won't work. You have to use disassembled tables for any editing purposes.
MaciACL does it all automatically.

Here is an example of the config.plist of OC for ssdt-dmar.aml and deleting the DMAR tables.

XML:
    <key>ACPI</key>
    <dict>
        <key>Add</key>
        <array>
...
            <dict>
                <key>Comment</key>
                <string>Remove reserved memory region blocks to fix network adapters</string>
                <key>Enabled</key>
                <true/>
                <key>Path</key>
                <string>SSDT-DMAR.aml</string>
            </dict>
        </array>
        <key>Delete</key>
        <array>
            <dict>
                <key>All</key>
                <false/>
                <key>Comment</key>
                <string>Delete DMAR (Use with SSDT-DMAR.aml)</string>
                <key>Enabled</key>
                <true/>
                <key>OemTableId</key>
                <data>RURIMiAgICA=</data>
                <key>TableLength</key>
                <integer>0</integer>
                <key>TableSignature</key>
                <data>RE1BUg==</data>
            </dict>
        </array>
...
 
@medianjoe @Edhawk

Well, following medianjoe's steps, with Edhawk's guidance, got me into Ventura from my external Ventura test drive... with working ethernet (I kept the IntelMausi.kext in place, as I was unclear on whether to remove it). Apart from moving painfully slow (and that could be because it was loading a new OS for the first time from a USB drive), there was, of course, no Bluetooth or WiFi. The more curious problem is that none of my other external OR internal USB drives were showing up in the Finder. I went into System Report, USB, and it seemed to show everything that was connected, but other than the "Ventura" drive from which I booted, I couldn't see any other internal or external drives. I guess I've got a ways to go before my system is ready for Ventura prime time. I'll hold off to see if the community comes up with methods for enabling onboard Bluetooth and WiFi (or install my BCM94360CS2), while I figure out why my other drives weren't showing up in Finder.

Screenshot 2022-11-01 at 11.43.09 AM.png
 
Intel WiFi requires the Alpha release of Airportitlwm.kext to work in Ventura, version 2.2.0 IIRC. Not the Stable 2.1.0 kext used for Monterey.


The USB connected drive may only be working at USB2 speed. So it would be slow in comparison to a drive connected to a SATA III/USB3/Type-C port working at full speed.

Trying a different USB port may make a difference too.

As you can boot from the USB connected drive, connecting it to the motherboard using a SATA port would vastly improve the speed, if that is an option available to you. It would give you a better idea of how your system works with Ventura. It shouldn't be sluggish if the full speed of the drive is available.

The IntelMausi.kext is not used by your motherboard's 2.5GB Ethernet port. It is used by a number of Intel 1GB Ethernet port/chips. So it is not of any use in your system, and can be removed from your OC setup.
 
Intel WiFi requires the Alpha release of Airportitlwm.kext to work in Ventura, version 2.2.0 IIRC. Not the Stable 2.1.0 kext used for Monterey.


The USB connected drive may only be working at USB2 speed. So it would be slow in comparison to a drive connected to a SATA III/USB3/Type-C port working at full speed.

Trying a different USB port may make a difference too.

As you can boot from the USB connected drive, connecting it to the motherboard using a SATA port would vastly improve the speed, if that is an option available to you. It would give you a better idea of how your system works with Ventura. It shouldn't be sluggish if the full speed of the drive is available.

The IntelMausi.kext is not used by your motherboard's 2.5GB Ethernet port. It is used by a number of Intel 1GB Ethernet port/chips. So it is not of any use in your system, and can be removed from your OC setup.
@Edhawk I did use the 2.2.0 version of Airportitlwm.kext, I specifically downloaded and placed the "Ventura" file. So, I was kind of surprised when it was greyed out. Not sure what to try next.

I have removed the IntelMausi.kext, and done a clean snapshot in ProperTree, and I will try a different USB port the next time I try to boot into Ventura. Obviously, connecting it directly to a SATA port would be much more ideal, but I'll need to make time for that.

But why do we think none of the other internal or external drives showed up in the Finder — only the drive I used to boot? Or was it just moving so slowly that it didn't have time to recognize all the drives, even though they were showing as connected via USB in the System Report?
 
Not sure why the drives didn't appear in Finder. Usually even if the Desktop Preferences are not set to show internal drives, Finder shows them in the sidebar by default. That hasn't changed in Ventura. But checking the Finder > Settings (Preferences) to see if the drives are set to show would be logical.

Screenshot 2022-11-01 at 20.38.38.png This is what the Finder > Settings > Sidebar shows on my Ventura (CFL) system.

If the Sidebar entries are correct, then it could be an issue with your USBPorts.kext causing the drives not to show correctly.
 
Not sure why the drives didn't appear in Finder. Usually even if the Desktop Preferences are not set to show internal drives, Finder shows them in the sidebar by default. That hasn't changed in Ventura. But checking the Finder > Settings (Preferences) to see if the drives are set to show would be logical.

View attachment 557494 This is what the Finder > Settings > Sidebar shows on my Ventura (CFL) system.

If the Sidebar entries are correct, then it could be an issue with your USBPorts.kext causing the drives not to show correctly.
@Edhawk Thanks. I did go into Finder preferences and clicked everything... hard drives, connected servers, external drives, etc. Still nothing on the desktop and nothing in the Finder sidebar. I'll try booting in again tomorrow. In my experience, sometimes these issues inexplicably resolve themselves with a reboot. Eager to see if it boots faster, too, since I've now gone through all of the setup.
 
... no Bluetooth or WiFi.

Maybe... delete the data below the OemTableId in ACPI/Delete/DMAR. i.e.,

XML:
   <key>OemTableId</key>
   <data></data>
 
Back
Top