Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Yes, confirmed fix in 12.1. Booted Monterey installed via micropatcher (no OC at all) with MVC flashed W5700 5 times in a row and it always booted properly!

Can someone check Big Sur 11.6.2?
 
  • Like
Reactions: prefuse07

I'm also interested to see what the result of this is. I have 12.2 beta 1 showing as an update but as far as I can tell it's not really anything interesting for the purposes of this discussion here. I'll put it on the other machine and try modifying the config.plist as mentioned to see how it boots up. If it doesn't work I can put that disk drive into my main MP5,1 and change the plist back.

The very slow/failed boots I had before appear to have come back with the 12.1 beta 4, one just today. I'm at a loss to explain those. But they are certainly not happening on 12.1 final release version.

Edit: 12.2 beta 1 (21D5025f) installed with no problems at all, this was using the regular update feature in macOS. I'm just using the Martin Lo 0.7.5 package.

12.2b1-installed.jpg
 
Last edited:
  • Like
Reactions: prefuse07
@PeterHolbrook may be on to something here - I'm still not running 12.1, so I have no relevant test platform right now, but I did have a look at the code, and it appears they've been tinkering with a lock in register_and_init_prng. Without a test platform, I can't say much for certain, but it looks like it's definitely worth trying to boot 12.1 without SurPlus (just disable the two patches for the test) - there's a real chance that the race condition might not be an issue in the released version of 12.1.

If you give this a try, please post results, positive and negative, in this thread. Thank you.
I can confirm my POSITIVE experience deleting both parts of SurPlus in my config.plst under OCLP 0.3.3.
Monterey 12.1 booting process has been normal six times in a row, both warm and cold bootings. I will continue to watch the situation.

In any case, I still send my gratitude to you, @Syncretic. for all your work last few months fighting against -and defeating- that race condition
 
I can also confirm that macOS 12.1 boots successfully without SurPlus. A welcomed change, but it will never take away from the epicness of @Syncretic's contribution.
I will take this off the 6 core MP5,1 later today and see how it goes over the course of this week.

I noticed also that same computer once running on 12.1 final release version has run faultlessly. I can't change the computer running 12.2b1 this week because it's the work machine.

Fingers crossed the experts here don't have to find workarounds like that again.
 
12.1 works like magic, 11.6.2 sadly not, but who cares about Big Sur when we have Monterey working.

Is there any way to skip that EFI firmware update without OpenCore or moving the drive to supported Mac and back ?
 
I think I agree with the others, it looks like 12.1 is very good for our 5,1 classic Mac Pros. I've had no problems at all with the release version 12.1 on my 6 core 5,1 which I use twice daily for Zwift, and the 128gb machine runs well in 12.2 beta 1.

Fingers crossed it remains that way and no other unpleasant surprises.
 
But is MonteRand still required for 12.1?
 
  • Like
Reactions: mangombia
^I think he means 11.3-12.0.1 and a few betas of 12.1 require SurPlus, whereas 12.1 and 12.2 betas don't.
 
Last edited:
  • Like
Reactions: freqrider
I'm still getting on 12.2 some random stalling startups where the boot menu will appear then choose the default OS (12.2) and the progress bar goes across very slowly and stops half way.

If I reboot then it will work. Another thing that helps is waiting at the boot menu for longer and then choosing 12.2.

I really can't work out what is going on with that, there are no other issues and 12.2 is very stable otherwise.
 
I'm still getting on 12.2 some random stalling startups where the boot menu will appear then choose the default OS (12.2) and the progress bar goes across very slowly and stops half way.
Randomly hanging on boot in Monterey can be caused by not having DataHub>BoardProduct set. See

 
  • Like
Reactions: kkinto and avro707
Can anyone confirm 12.2 is booting fine without SurPlus patches?
Yes I can. I upgraded from 12.1 to 12.2 with no issues at all. No Surplus nor MonteRand.
I use OCLP 0.4.1.
OCLP still adds Surplus but you can erase it without a problem, if you want. In #1 @Syncretic says:

"The race condition addressed by SurPlus is no longer an issue in 12.1. (Note that SurPlus is still required for Big Sur 11.3-11.6.2 and Monterey prior to 12.1; MonteRand seems to only be required for 12.1b1 and no other version/beta.)"

I think that idea is now valid for Monterey 12.2 as well
 

Attachments

  • Screenshot 2022-01-29 at 10.48.49.png
    Screenshot 2022-01-29 at 10.48.49.png
    318 KB · Views: 151
Last edited:
  • Like
Reactions: freqrider
11.6.3 still doesn't boot well, 12.2 works well without any patches. Can be moved directly from other supported Mac.
 
I understand that two machine debugging of the kernel using FireWire and Ethernet doesn't start early enough, but what about serial?

In the serial_init function of pe_serial.c, there's three options for a serial port: Legacy, MMIO, and PCIe.
Legacy uses the COM1 port address 0x3f8.
MMIO uses MMIO Config space 0xFE036000 or Legacy MMIO Config space 0xFE034000 but you can use a boot-arg "mmio_uart" to specify a base address.
PCIe uses PCIe MMIO base 0xFE410000 but you can use a boot-arg "pcie_mmio_uart" to change that.

Macs don't usually have a serial port but a Hackintosh can (a COM port). My GA-Z170X-Gaming 7 motherboard has a COM port for example.

I wonder if the PCIe option would work? Install a 16x50 compatible PCIe card, and set the boot-args. To check if it could work, boot into a UEFI Shell and probe the addresses with the mm command using the same offsets and values that the probe functions in pe_serial.c use.

A PCIe card in a Thunderbolt enclosure might also work if you have a Mac with no PCIe slots. But the PCIe addresses might change during PCIe enumeration?
A follow up to this idea:

I don't think my 16x50 based PCIe serial card ( https://www.amazon.com/dp/B085QMN3HD ) has registers that match the "mmio_uart" or "pcie_mmio_uart" modes. It appears to have registers that match the legacy uart mode but the xnu kernel doesn't have a boot-arg to override the base for those registers (I/O address 0x3f8).

These are my instructions to get it to work:
- Use ioreg -fliw0 to examine the serial ports.
- There is a com_apple_driver_16X50UARTSync which has the location info "PCI Slot-3 Bus=24 Dev=0 Func=0 BAR=0 Offset=0"
- The grandparent of that is a IOPCIDevice which has the info for BAR 0 (base address register #0) in the assigned-addresses property:
Code:
    | |   |   |   |   | |     00: phys.hi: 81180010 phys.mid: 00000000 phys.lo: 00002008
    | |   |   |   |   | |         size.hi: 00000000 size.lo: 00000008
    | |   |   |   |   | |         bus: 24 dev: 0 func: 0 reg: 16
    | |   |   |   |   | |         type: I/O flags: abs
phys.hi has the memory type and flags (0x81 = type: I/O, flags: abs) and PCI bus (0x18 = 24), device (upper 5 bits of 00), and function (3 bits of 00) numbers, and the register offset in config space (0x10 = BAR 0).
An I/O memory address are those that are accessed using the in and out x86 instructions.

0x2008 is the I/O address assigned by UEFI PCI bus enumeration. It may change when different devices are connected.

The address has to be within the range of I/O addresses assigned to each of its ancestors.

The pcitree.sh script (or FixPCIeLinkRate.efi in UEFI Shell) can show the ancestors:
Code:
├┬00:09.0-[12-1a]     # g2x4 > g1x4    [8086:4029] [0604] (rev 20) PCI bridge                : Intel Corporation 5400 Chipset PCI Express Port 9
│├┬12:00.0-[13-19]    # g1x8 > g1x4    [8086:3500] [0604] (rev 01) PCI bridge                : Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port
││├┬13:01.0-[18]      # g1x4 > g1x1    [8086:3514] [0604] (rev 01) PCI bridge                : Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2
│││├─18:00.0          # g1x1           [125b:9100] [0700]          Serial controller         : Asix Electronics Corporation AX99100 PCIe to Multi I/O Controller
│││└─18:00.2          # g1x1           [125b:9100] [0700]          Serial controller         : Asix Electronics Corporation AX99100 PCIe to Multi I/O Controller

The
Code:
sudo lspci -vvvv
command can get the address ranges for all the parents. In my case, I see the ancestors have these I/O address ranges:

00:09.0: I/O behind bridge: 00001000-00002fff [size=8K]
12:00.0: I/O behind bridge: 00001000-00002fff [size=8K]
13:01.0: I/O behind bridge: 00002000-00002fff [size=4K]

Basically, it's like the bus numbers - the parents have to have a range that encompasses all the values that are used by its children.

Anyway, the point is you can't just assign numbers without affecting all the ancestors and their descendants. This makes Thunderbolt hot plug complicated (it helps to have reserved bus and memory ranges which is what PCs do in their BIOS menus).

- Create a kernel patch in OpenCore config.plist in the "Kernel/Patch" section that replaces all accesses to the legacy COM 1 port (0x3f8, 0x3f9, 0x3fa, 0x3fb, 0x3fc, 0x3fd, 0x3fe, 0x3ff) with accesses to the I/O range of our PCIe serial port: (0x2008 .. 0x200f).
Code:
            <dict>
                <key>Arch</key>
                <string>Any</string>
                <key>Base</key>
                <string></string>
                <key>Comment</key>
                <string>serial output to PCIe card (change 3f8 to 2008 which is offset 0 of BAR0 of our PCIe serial card)</string>
                <key>Count</key>
                <integer>0</integer>
                <key>Enabled</key>
                <true/>
                <key>Find</key>
                <data>Zrr4Aw==</data>
                <key>Identifier</key>
                <string>kernel</string>
                <key>Limit</key>
                <integer>0</integer>
                <key>Mask</key>
                <data>///4/w==</data>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string></string>
                <key>Replace</key>
                <data>ZroIIA==</data>
                <key>ReplaceMask</key>
                <data>///4/w==</data>
                <key>Skip</key>
                <integer>0</integer>
            </dict>
You can use plutil -p config.plist to see a more human readable form. It looks like this:
Code:
        "Arch" => "Any"
        "Base" => ""
        "Comment" => "serial output to PCIe card (change 3f8 to 2008 which is offset 0 of BAR0 of our PCIe serial card)"
        "Count" => 0
        "Enabled" => 1
        "Find" => {length = 4, bytes = 0x66baf803}
        "Identifier" => "kernel"
        "Limit" => 0
        "Mask" => {length = 4, bytes = 0xfffff8ff}
        "MaxKernel" => ""
        "MinKernel" => ""
        "Replace" => {length = 4, bytes = 0x66ba0820}
        "ReplaceMask" => {length = 4, bytes = 0xfffff8ff}
        "Skip" => 0
f803 is the original address base in little endian format ( = 0x03f8 ). We use a find mask f8ff to find all 8 addresses in the range. 0820 is the new address base replacement in little endian format ( = 0x2008). We use a replace mask to leave the offset (0-7) in the range intact.

Use a disassembler such as Hopper.app to ensure that all occurrences of the find bytes(use a hex regular expression 66BAF[89ABCDEF]03) are part of an in or out instruction.

In the config.plist, the boot-args should enable serial kprintf (the 8 in debug=) and set the serialbaud to the max value (115.2 Kbps) supported by the PCIe serial card and the host serial port (I have a Keyspan USB adapter connected to an iMac). Search xnu source code ( https://github.com/apple-oss-distributions/xnu/blob/main/osfmk/console/serial_protos.h ) for flags that can be used with serial= (search for serialmode). I have set SERIALMODE_OUTPUT and SERIALMODE_INPUT (I think INPUT is probably optional). Setting SERIALMODE_SYNCDRAIN might cause a panic?
Code:
                <key>boot-args</key>
                <string>keepsyms=1 debug=0x108 -v maxmem=63488 iogdebg=-1 serial=3 msgbuf=1048576 serialbaud=115200</string>

There are a couple thing left to do to make this work. First you need to enable I/O addresses for the PCIe card:
- In OpenCore, press space bar so you can see the Open Shell.efi option. Select that. In the UEFI Shell, enter the following command:
Code:
mm 180000004 1 -w 1 -pcie
where 18 is the bus number, 00 is the device number, 00 is the function number, 004 is the command register, 1 is the value to write to the register (this is bit 0 which is the enable I/O addresses bit). -w is the write command. 1 is the number of bytes to write to. -pcie is the type of address.
An efi driver should be created to do this enablement. Maybe a modified SerialDxe.efi?

- It may be that when macOS attaches its Apple16X50PCI0, it will disable kprintf. kprintf will start working again if you launch a serial app (Serial.app for example) that inits the port to 115.2 Kbps. Maybe a codeless kext can be created to match this with a higher probe score so that the kext driver won't load for this serial port and interfere with kernel's kprintf function?

- If the serial card were in a hot pluggable environment, such as in a Thunderbolt enclosure, then there may be issues with disconnecting it and reconnecting it - if the I/O address gets assigned to something else.
 
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
@joevt ... Looks like this patch example added to the Sample OC Config might be aiming at the same thing:
My patch is about getting alternative serial port hardware to work with the kernel (for kprintf and maybe debugging) by changing the I/O addresses to match the I/O addresses of my PCIe serial port card.

I'm not sure what that patch you linked is doing - the description is not detailed enough. It seems to imply that the DEBUG kernel has earlier serial output than the RELEASE kernel (the implication follows from the fact that the alternative interpretation of the description - that the RELEASE kernel doesn't have serial output - is false). It would be useful to have a comment that refers to a line of code in the opensource xnu code that is to be altered by the patch.

In any case, I suppose @vit9696 is using the serial port of a Hackintosh - the COM1 port of a PC. The I/O addresses used in xnu don't need to be changed in that case (same would be true for an Xserve).

There's some OpenCore documentation about debugging using the serial port:
https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/kernel-debugging.html

Debugging during EFI (or just redirecting the console to serial like you can in Open Firmware) won't work without a serial driver. In my case, I don't have a EFI serial driver for my PCIe card. Macs (including my MacPro3,1) have an IsaSerialDxe driver but I don't think there's any hardware for it (ISA would probably apply to the COM1 port).
 
Yes, the documentation there leaves much to be desired. The OC Team does not like to add comments in config files but could have provided more info with the commit comments.

Vit appears to tend towards the laconic side of things, except in his monthly updates where he releases the inner poet and waxes lyrical (apart from the last one).

I suppose I can't say much about that though, not being one that puts full and proper notes into commits myself such as you do. Need to start changing that.
 
Yes, the documentation there leaves much to be desired. The OC Team does not like to add comments in config files but could have provided more info with the commit comments.

Vit appears to tend towards the laconic side of things, except in his monthly updates where he releases the inner poet and waxes lyrical (apart from the last one).

I suppose I can't say much about that though, not being one that puts full and proper notes into commits myself such as you do. Need to start changing that.
It appears to be a simple patch that just sets the default value of disable_serial_output to 1, the same value that is used for the default value of the DEBUG kernel.
https://github.com/apple-oss-distri...a151b24afbff733/pexpert/i386/pe_kprintf.c#L62

This has the effect of beginning kprintf output earlier. I see these additional lines in the kprintf output before the usual set of lines begin being output:
Code:
EFI_get_frequency: read FSBFrequency value: 398999949
 BUS: Frequency =    398.999949MHz, cvtt2n = 00000002.819AA5C6, cvtn2t = 00000000.6624DC54
 TSC: Frequency =   3191.999593MHz, cvtt2n = 00000000.503354B8, cvtn2t = 00000003.3126E2A8, gran = 8
Longterm timer threshold: 1000 ms

The usual set of lines (first ≈200 of them) that occur with or without the patch:
Code:
kprintf initialized
Serial mode specified: 00000003
version_variant = 0
version         = Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64
KASLR slide: 0x000000000dc00000 dynamic
Hiding local relocations
WARNING: ignoring first page in [0x0:0x8e]
Physical memory 63488 MB
avail_remaining = 0xf7f7bc
Kernel virtual space from 0xffffff8000000000 to 0xffffffffffffefff.
Available physical space from 0x128f9000 to 0xfffce4000
initialize_screen: b=80020000, w=00000A00, h=00000640, r=00004000, d=00000001
Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64
pmap_startup() delaying init/free of page nums > 0x200000
pmap_startup() init/release time: 48347 microsec
pmap_startup() delayed init/release of 14517783 pages
vm_page_bootstrap: 1462879 free pages, 14757281 wired pages, (up to 14517783 of which are delayed free)
VM boostrap: 31 maps, 510 entries and 128 holes available
"vm_compressor_mode" is 4
kext submap [0x<ptr> - 0x<ptr>], kernel text [0x<ptr> - 0x<ptr>]
zone leak detection enabled
VM bootstrap done: 19 maps, 474 entries and 128 holes left
IOKit IOMD setownership ENABLED
ATM subsystem is initialized
Log queues configured: slot count: 72, per-slot size: 32768, total size: 2359296
Long logs support configured: size: 16384
Firehose configured: 16 chunks, 8 io pages
Telemetry: Sampling all tasks once per 1 second
Scheduler: Default of dualq
Setting scheduler priority decay band limit 18
standard timeslicing quantum is 10000 us
standard background quantum is 2500 us
WQ[wql_init]: init linktable with max:262144 elements (8388608 bytes)
WQ[wqp_init]: init prepost table with max:262144 elements (8388608 bytes)
mig_table_max_displ = 53 mach_kobj_count = 400
Reallocated master cpu data: 0xffffff800ec6ce00, interrupt stack: 0xffffffd076153000, fault stack: 0xffffff800dd56800
CPU identification: Intel(R) Xeon(R) CPU           X5482  @ 3.20GHz
CPU features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1
  HTT: 4 cores per package; 4 logical cpus per package
CPU extended features: SYSCALL XD EM64T LAHF
Initializing EFI runtime services
MSR_IA32_APIC_BASE 0xfee00000 enabled legacy mode BSP
ID: 0x0 LDR: 0x0
Boot cpu local APIC id 0x0
fpu_state: FP, state_size: 512
Kernel text 0xffffff800de10000-0xffffff800e810000 to be write-protected
Marking (0xffffff800e824000, 0xffffff800e8a3000) as rwx
Marking (0xffffff800eeef000, 0xffffff800ef1b000) as rwx
Marking (0xffffff800ef1b000, 0xffffff800ef1c000) as rwx
Marking (0xffffff800e810000, 0xffffff800e823000) as rwx
Marking (0xffffff800e8a3000, 0xffffff800e8a4000) as rwx
Marking (0xffffff800ef1c000, 0xffffff800ef1c000) as rwx
Marking (0xffffff800e823000, 0xffffff800e823000) as rwx
Marking (0xffffff80122ad000, 0xffffff801261f000) as rwx
Marking (0xffffff80112ec000, 0xffffff8011333000) as rwx
Marking (0xffffff800de10000, 0xffffff800de10000) as rwx
Marking (0xffffff801137c000, 0xffffff8011d06000) as rwx
[RTCLOCK] frequency 3190000000 (3191999593)
maxDec: 5382165216
BANK subsystem is initialized
IPC_PTHREAD_PRIORITY subsystem is initialized
kdp_core zlib memory 0x7000
Registered coredump handler for kernel
Kernel boot args: 'keepsyms=1 debug=0x108 -v maxmem=63488 iogdebg=-1 serial=3 msgbuf=1048576 serialbaud=115200'
corecrypto_kext_start called
FIPSPOST_KEXT [1403286020] fipspost_post:155: [FIPSPOST][Module-ID] Apple corecrypto Module v12.0 [Intel, Kernel, Software, SL1]
FIPSPOST_KEXT [1414805746] fipspost_post:159: PASSED: (11 ms) - fipspost_post_hmac
FIPSPOST_KEXT [1424053509] fipspost_post:168: PASSED: (20 ms) - fipspost_post_integrity
FIPSPOST_KEXT [1431821277] fipspost_post:174: PASSED: (28 ms) - fipspost_post_indicator
FIPSPOST_KEXT [1439710102] fipspost_post:175: PASSED: (36 ms) - fipspost_post_aes_ecb
FIPSPOST_KEXT [1447441936] fipspost_post:176: PASSED: (44 ms) - fipspost_post_aes_cbc
FIPSPOST_KEXT [1460169646] fipspost_post:177: PASSED: (56 ms) - fipspost_post_rsa_sig
FIPSPOST_KEXT [1478214995] fipspost_post:178: PASSED: (74 ms) - fipspost_post_ecdsa
FIPSPOST_KEXT [1486152073] fipspost_post:179: PASSED: (82 ms) - fipspost_post_ecdh
FIPSPOST_KEXT [1493455342] fipspost_post:180: PASSED: (90 ms) - fipspost_post_aes_ccm
FIPSPOST_KEXT [1501191263] fipspost_post:181: PASSED: (97 ms) - fipspost_post_aes_cmac
FIPSPOST_KEXT [1509023585] fipspost_post:182: PASSED: (105 ms) - fipspost_post_hkdf
FIPSPOST_KEXT [1530497340] fipspost_post:183: PASSED: (127 ms) - fipspost_post_pbkdf
FIPSPOST_KEXT [1537983378] fipspost_post:185: PASSED: (134 ms) - fipspost_post_kdf_ctr
FIPSPOST_KEXT [1545797524] fipspost_post:186: PASSED: (142 ms) - fipspost_post_aes_gcm
FIPSPOST_KEXT [1553619764] fipspost_post:187: PASSED: (150 ms) - fipspost_post_aes_xts
FIPSPOST_KEXT [1561493800] fipspost_post:188: PASSED: (158 ms) - fipspost_post_tdes_ecb
FIPSPOST_KEXT [1569368763] fipspost_post:189: PASSED: (166 ms) - fipspost_post_drbg_ctr
FIPSPOST_KEXT [1577339215] fipspost_post:190: PASSED: (174 ms) - fipspost_post_drbg_hmac
FIPSPOST_KEXT [1585263730] fipspost_post:212: all tests PASSED (181 ms)
Matching service count = 0
Matching service count = 0
ulock_initialize>thread_max=76800, ull_hash_buckets=32768
AAA_LoadEarly_MouSSE::probe(ACPI)
ACPI: ACPI: RSDP 0x000000007F744014 000024 (v02 APPLE )RSDP 0x000000007F744014 000024 (v02 APPLE )Darwin Image4 Validator Version 4.2.0: Tue Nov 30 21:45:44 PST 2021; root:AppleImage4-157.60.2~361/AppleImage4/RELEASE_X86_64
calling mpo_policy_init for AppleImage4
Security policy loaded: AppleImage4 sysctl hook (AppleImage4)
AppleImage4: no options node: 19
calling mpo_policy_init for AMFI
Security policy loaded: Apple Mobile File Integrity (AMFI)
calling mpo_policy_init for Sandbox
Security policy loaded: Seatbelt sandbox policy (Sandbox)
calling mpo_policy_init for Quarantine
Security policy loaded: Quarantine policy (Quarantine)
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...
Lilu       dev: @ failed to obtain model information, retrying...


ACPI: Lilu       dev: @ failed to obtain model information, retrying...
ACPI: XSDT 0x000000007F67E000 0000EC (v01 APPLE  Apple00  0000006C      01000013)XSDT 0x000000007F67E000 0000EC (v01 APPLE  Apple00  0000006C      01000013)Lilu       dev: @ failed to obtain model information, retrying...


Lilu       dev: @ failed to obtain model information, retrying...
ACPI: ACPI: FACP 0x000000007F740000 0000F4 (v04 APPLE  Apple00  0000006C Loki 0000005F)Lilu       dev: @ failed to obtain model information, retrying...
FACP 0x000000007F740000 0000F4 (v04 APPLE  Apple00  0000006C Loki 0000005F)

ACPI: ACPI: Lilu       dev: @ failed to obtain model information, retrying...
DSDT 0x000000007F737000 0049CC (v01 APPLE  Apple00  00010001 Loki 0000005F)Lilu       dev: @ failed to obtain model information, retrying...
DSDT 0x000000007F737000 0049CC (v01 APPLE  Apple00  00010001 Loki 0000005F)

ACPI: ACPI: FACS 0x000000007F682000 000040Lilu       dev: @ failed to obtain model information, retrying...
FACS 0x000000007F682000 000040

ACPI: ACPI: FACS 0x000000007F682000 000040FACS 0x000000007F682000 000040

ACPI: Lilu       dev: @ failed to obtain model information, retrying...
ACPI: ECDT 0x000000007F742000 000053 (v01 APPLE  Apple00  00000001 Loki 0000005F)ECDT 0x000000007F742000 000053 (v01 APPLE  Apple00  00000001 Loki 0000005F)Lilu       dev: @ failed to obtain model information, retrying...


Lilu       dev: @ failed to obtain model information, retrying...
ACPI: ACPI: HPET 0x000000007F73F000 000038 (v01 APPLE  Apple00  00000001 Loki 0000005F)Lilu       dev: @ failed to obtain model information, retrying...
HPET 0x000000007F73F000 000038 (v01 APPLE  Apple00  00000001 Loki 0000005F)

ACPI: ACPI: APIC 0x000000007F73D000 0000BC (v02 APPLE  Apple00  00000000 Loki 0000005F)Lilu       dev: @ failed to obtain model information, retrying...
APIC 0x000000007F73D000 0000BC (v02 APPLE  Apple00  00000000 Loki 0000005F)

ACPI: ACPI: MCFG 0x000000007F73C000 00003C (v01 APPLE  Apple00  00000001 Loki 0000005F)Lilu       dev: @ failed to obtain model information, retrying...
MCFG 0x000000007F73C000 00003C (v01 APPLE  Apple00  00000001 Loki 0000005F)

ACPI: ACPI: SSDT 0x000000007F736000 000146 (v01 PmRef  Cpu0Cst  00003001 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F736000 000146 (v01 PmRef  Cpu0Cst  00003001 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F735000 00034B (v01 CPUPST Cpu0Ist  00000012 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F735000 00034B (v01 CPUPST Cpu0Ist  00000012 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F734000 000047 (v01 PmRef  Cpu1Cst  00003000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F734000 000047 (v01 PmRef  Cpu1Cst  00003000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F733000 000337 (v01 CPUPST Cpu1Ist  00000012 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F733000 000337 (v01 CPUPST Cpu1Ist  00000012 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F732000 000047 (v01 PmRef  Cpu2Cst  00003000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F732000 000047 (v01 PmRef  Cpu2Cst  00003000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F731000 000337 (v01 CPUPST Cpu2Ist  00000012 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F731000 000337 (v01 CPUPST Cpu2Ist  00000012 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F730000 000047 (v01 PmRef  Cpu3Cst  00003000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F730000 000047 (v01 PmRef  Cpu3Cst  00003000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F72F000 000337 (v01 CPUPST Cpu3Ist  00000012 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F72F000 000337 (v01 CPUPST Cpu3Ist  00000012 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F72E000 000047 (v01 PmRef  Cpu4Cst  00003000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F72E000 000047 (v01 PmRef  Cpu4Cst  00003000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F72D000 000337 (v01 CPUPST Cpu4Ist  00000012 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F72D000 000337 (v01 CPUPST Cpu4Ist  00000012 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F72C000 000047 (v01 PmRef  Cpu5Cst  00003000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F72C000 000047 (v01 PmRef  Cpu5Cst  00003000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F72B000 000337 (v01 CPUPST Cpu5Ist  00000012 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F72B000 000337 (v01 CPUPST Cpu5Ist  00000012 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F72A000 000047 (v01 PmRef  Cpu6Cst  00003000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F72A000 000047 (v01 PmRef  Cpu6Cst  00003000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F729000 000337 (v01 CPUPST Cpu6Ist  00000012 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F729000 000337 (v01 CPUPST Cpu6Ist  00000012 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F728000 000047 (v01 PmRef  Cpu7Cst  00003000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F728000 000047 (v01 PmRef  Cpu7Cst  00003000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F727000 000337 (v01 CPUPST Cpu7Ist  00000012 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F727000 000337 (v01 CPUPST Cpu7Ist  00000012 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F726000 00003D (v01 PmRef  CpuPm    00003000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F726000 00003D (v01 PmRef  CpuPm    00003000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F722000 000166 (v01 SataRe SataAhci 00001000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F722000 000166 (v01 SataRe SataAhci 00001000 INTL 20061109)

ACPI: ACPI: SSDT 0x000000007F71D000 0004BE (v01 PCIRef Pci8844  00001000 INTL 20061109)Lilu       dev: @ failed to obtain model information, retrying...
SSDT 0x000000007F71D000 0004BE (v01 PCIRef Pci8844  00001000 INTL 20061109)

ACPI: ACPI: DMAR 0x000000007F71A000 000088 (v01 APPLE  Apple00  00000001 Loki 0000005F)Lilu       dev: @ failed to obtain model information, retrying...
DMAR 0x000000007F71A000 000088 (v01 APPLE  Apple00  00000001 Loki 0000005F)

Lilu       dev: @ failed to obtain model information, retrying...
ACPI: ACPI: 20 ACPI AML tables successfully acquired and loadedLilu       dev: @ failed to obtain model information, retrying...
20 ACPI AML tables successfully acquired and loaded

calling mpo_policy_init for RestrictEvents
Security policy loaded: RestrictEvents Kernel Extension 1.0.5 (RestrictEvents)
AppleCredentialManager: init: called, instance = <ptr>.

The lines that appear in the graphical console appear to be the same as usual. They are a subset of the lines output to the serial port:
graphical console before serial output.jpg

Without kprintf output enabled in the boot-args, no serial port output would occur and the graphical console would continue from the point you see above to show console messages until macOS boots.
 
  • Like
Reactions: perez987 and Dayo
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.