new possibilities for X79 AppleACPIPlatform panic

[cheneyveron]

Hi guys,

My computer hardware is i signature.
Currently, 10.12.6 is perfect and my EFI is here.

Problem Description:
When I tried to boot 10.13 DP5, I encountered AppleACPIPlatform problem:

Typical Causes and Solutions:
After searching google for couple of days and with the help of @PMheart I found Alext James (@TheRacerMaster)'s article : http://alextjam.es/debugging-appleacpiplatform/

Because signed char become negative when bigger than 0x7f, Apple rewrote isprint method but seems to forget to cast char to unsigned. Thus, if OemId, Signature、OemId、OemTableId or AslCompilerId in any ACPI table contains a char greater than 0x7f, it will cause a memory overflow.

Most people can solve by:

• dropping MATS/BGRT table( or other table )
• add FixHeaders_20000000 in clover ACPI patch
• Modify MATS/BGRT/other table and change that char to lower than 0x80

But sadly none worked for me

1. I dropped all of my ACPI tables except DSDT and APIC, cuz I cannot boot without these two
2. I searched for APIC and DSDT, none of their OemId, Signature、OemId、OemTableId or AslCompilerId contains char greater than 0x7f

Untypical Situation:
I took a video of my boot process using -verbose, debug=0x100, keepsyms=1 :
see online : https://www.dropbox.com/s/p4eztglltdtqxyb/boot.mp4?dl=0
In the trace, the boot process stuck at isspace other than isprint.
Out to curiosity, I decompiled AppleACPIPlatform and saw isspace looks like this:

                     _isspace:
000000000001f5cf         push       rbp                                         ; CODE XREF=_AcpiUtStrtoul64+71, _AcpiUtStrtoul64+89
000000000001f5d0         mov        rbp, rsp
000000000001f5d3         lea        rax, qword [__ctype]
000000000001f5da         mov        al, byte [rdi+rax]
000000000001f5dd         and        al, 0x20
000000000001f5df         shr        al, 0x5
000000000001f5e2         pop        rbp
000000000001f5e3         ret

And in C language it looks like this:

int _isspace(int arg0) {
    rax = (int)__ctype[arg0];
    return (rax & 0x20) >> 5;
} 

It uses __ctype as an array and rdi, which acts as argument in assembly language, as a pointer to find some char and put it into al. 
I checked the length of __ctype is 256, thus any normal byte, which is 16 bits, won't caus overflow.
However, Apple didn't cast arg0 to unsigned char. Thus, any char that's greater than 0x7f will also cause an overflow.
 
Follw the trace, I found _AcpiUtStrtoul64 the source code is here. Looks like it just uses a loop to judge whether it's a space. No other useful information were found during further dig.
 

New Discovery and Dilemma

Occasionally, i decompiled two programs written to test signed and unsigned char, and were surprised to find,

the only difference between 'cast to unsigned' and 'stay signed' in assembly language is that when delivering argument, unsigned used 'movzx' and singed used 'movsx'.

In assembly language, arguments are delivered by register rdi. So, I think, if I change 'movsx' to 'movzx' then this problem can be solved. Here's where isspace is called inside _AcpiUtStrtoul64:

0000000000001153         mov        qword [r14], 0x0
000000000000115a         movsx      edi, byte [r15]
000000000000115e         test       edi, edi
0000000000001160         je         loc_12b5

0000000000001166         mov        dword [rbp+var_2C], esi
0000000000001169         xor        eax, eax
000000000000116b         call       _isspace
0000000000001170         lea        rbx, qword [r15+1]
0000000000001174         test       eax, eax
0000000000001176         je         loc_118d

                     loc_1178:
0000000000001178         movsx      edi, byte [rbx]                             ; argument #1 for method _isspace, CODE XREF=_AcpiUtStrtoul64+99
000000000000117b         xor        eax, eax
000000000000117d         call       _isspace
0000000000001182         inc        rbx
0000000000001185         test       eax, eax 

Note that edi is the lower 32 bit of rdi .

However, after patching in Clover, it stucks that line 0000000000001178 . And checking the register printed, register edi is empty. That means something's wrong when executing movzx .

 

If I do not change movsx to movzx, at the panic scene we can see in the above video that register rdi is 0x00000000 ffffffa4 , thus edi is 0xffff ffa4 .

Obviously, the char that caused the problem should be A4. However, I searched APIC but didn't find A4. There is a A4 in DSDT but I have no idea how to modify.

BIOS rom, all of my ACPI tables and modified dsdt/ssdt can be found in attachment.

 

Need Someone's Help

So, here I'm at a very embarrassed stage don't know where's wrong even what to do next... Maybe something's wrong with one of my ACPI tables? Or with AppleACPIPlatform? Or with AppleSMCRTC?

I'm pretty sure I'm not alone with this question, someone willing to dig into it please check my raw ACPI tables, BIOS ROM, modified DSDT/SSDT and my current EFI folder. Thanks very much.

 

BIOS ROM:

x7946.rom.zip

Modified DSDT/SSDT, perfect on 10.10 - 10.12.6:

dsdt+ssdt.zip

Original ACPI Tables:

OriginACPI.zip

[x.di]

I am having the same problem

http://www.insanelymac.com/forum/topic/324929-applesmcrtc-panic-on-dual-xeon-system/

[Vinicius P. Miranda]

I'm stuck too. Until today I could not pass this part with any version of the clover I tested, and none Beta version of the High Sierra.

I do not know what to test anymore.

 

 

[cheneyveron]

I am having the same problem

http://www.insanelymac.com/forum/topic/324929-applesmcrtc-panic-on-dual-xeon-system/

hey, you can try record your screen and see where it stucked at?

I'm stuck too. Until today I could not pass this part with any version of the clover I tested, and none Beta version of the High Sierra.

I do not know what to test anymore.

 

boot with debug=0x100 and -keepsyms=1 and see what exactly caused this problem?

[jcds83]

Hi Cheneyveron,

 

I feel less alone after your excellent article. Thanks.

I have the same ACPIPlatform problem and I've never succeeded to install High Sierra since the beginning.

 

My system : GA-Z97MX-D3H, i7-4770S and Nvidia GT 640

 

jcds83

[cheneyveron]

Hi Cheneyveron,

 

I feel less alone after your excellent article. Thanks.

I have the same ACPIPlatform problem and I've never succeeded to install High Sierra since the beginning.

 

My system : GA-Z97MX-D3H, i7-4770S and Nvidia GT 640

 

jcds83

Sorry to hear and glad to be helpful 

[Vinicius P. Miranda]

boot with debug=0x100 and -keepsyms=1 and see what exactly caused this problem?

 

This screen appeared. I'm not very good with codes, is it the same problem?

[cheneyveron]

This screen appeared. I'm not very good with codes, is it the same problem?

IMG_3020.jpg

hi, from this pic we can't see where's wrong cuz the detailed information was overwritten. You may record your screen and replay to see the error from start

[Vinicius P. Miranda]

hi, from this pic we can't see where's wrong cuz the detailed information was overwritten. You may record your screen and replay to see the error from start

The codes go down very fast, I can not see right with the camera I have. Is there any way to slow down or navigate up and down?

Link vídeo: https://1drv.ms/v/s!AicXim8xlQdCg60TPltyWzBKAP4rBw

 

If there's no other way, I'll try get a better camera tomorrow.

[cheneyveron]

The codes go down very fast, I can not see right with the camera I have. Is there any way to slow down or navigate up and down?

Link vídeo: https://1drv.ms/v/s!AicXim8xlQdCg60TPltyWzBKAP4rBw

 

If there's no other way, I'll try get a better camera tomorrow.

Well I see your problem is "isprint".

The cause is that some of the OemId, Signature、OemId、OemTableId or AslCompilerId in your ACPI table contains a char greater than 0x7f.

You can try these methods:

• drop MATS/BGRT table( or other table ) in Clover "ACPI" -> "Table Dropping"
• add FixHeaders_20000000 in clover ACPI patch. <- this requires the latest Clover.
• Modify MATS/BGRT/other table and change the char to lower than 0x80.<- this can be done using a hex editor. Remeber to correct the checksum with the latest Rehabman's Maciasl.

[cecekpawon]

@cheneyveron from your video seems you forgot to drop CpuPm table before loading external pm SSDT / auto generate by Clover?

<key>DropTables</key>
<array>
  <dict>
    <key>Signature</key>
    <string>SSDT</string>
    <key>TableId</key>
    <string>CpuPm</string>
  </dict>
</array>

@viniciusmi00, I see you are trying to load another AppleIntelCPUPowerManagement kext (from Clover?), while its already presented on prelinked. 

[cheneyveron]

@cheneyveron from your video seems you forgot to drop CpuPm table before loading external pm SSDT / auto generate by Clover?

<key>DropTables</key>
<array>
  <dict>
    <key>Signature</key>
    <string>SSDT</string>
    <key>TableId</key>
    <string>CpuPm</string>
  </dict>
</array>

Ah thanks for mentioning, I realized it too. However After dropping CpuPm the error continues...

[cecekpawon]

Have you tried this kext patch? Please follow the links for more detail I dont have such of bad tables, so difficult for me to reproduces that issues sorry..

[cheneyveron]

Have you tried this kext patch? Please follow the links for more detail I dont have such of bad tables, so difficult for me to reproduces that issues sorry..

hi! Thanks for your advice~

Sadly I'm not getting "isprint" error, so patch "isprint" may not be helpful

I tried to patch "isspace" to force it search in _AcpiGbl_Ctypes instead of __ctype, and modified 0x20 to 0x08 to let "isspace" behave like the function in acpia but it doesn't work cuz I still can't cast it to unsigned char.

My expression is poor, hope you can understand

I'm now trying to fix my acpi tables. I'm almost sure that the problem happens inside APIC table.

[jcds83]

First I thought it was a RAM problem; I kept only two modules. Same crash.

Here my screen capture:

[Vinicius P. Miranda]

 

Well I see your problem is "isprint".

The cause is that some of the OemId, Signature、OemId、OemTableId or AslCompilerId in your ACPI table contains a char greater than 0x7f.

You can try these methods:

• drop MATS/BGRT table( or other table ) in Clover "ACPI" -> "Table Dropping"
• add FixHeaders_20000000 in clover ACPI patch. <- this requires the latest Clover.
• Modify MATS/BGRT/other table and change the char to lower than 0x80.<- this can be done using a hex editor. Remeber to correct the checksum with the latest Rehabman's Maciasl.

I did several tests here. I was able to enter the installer only with "FixHeaders_20000000", did not have to drop tables.

Now the problem is that after installing, when I start the HD is giving an error

"The path /System/Installation/Packages/OSInstall.mpkg appears to be missing or damaged" Shut down the installer ...

I'll try to fix this, and I'll bring more news later.

 

Edit 1: I was able to install the High Sierra. I needed to remove the "EmuVariableUefi.efi". I'm doing some testing now.

Edit 2: My HDs containing Windows 10 are not working. Every time I start Higher Sierra, a warning appears that could not be mounted, and asks if I want to eject or format. (2 HDs in raid and 1 normal).

 

@viniciusmi00, I see you are trying to load another AppleIntelCPUPowerManagement kext (from Clover?), while its already presented on prelinked. 

Yep, now I've removed "AppleIntelCPUPowerManagement.kext" from Clover.

[cheneyveron]

I did several tests here. I was able to enter the installer only with "FixHeaders_20000000", did not have to drop tables.

Now the problem is that after installing, when I start the HD is giving an error

"The path /System/Installation/Packages/OSInstall.mpkg appears to be missing or damaged" Shut down the installer ...

I'll try to fix this, and I'll bring more news later.

 

Edit 1: I was able to install the High Sierra. I needed to remove the "EmuVariableUefi.efi". I'm doing some testing now.

Edit 2: My HDs containing Windows 10 are not working. Every time I start Higher Sierra, a warning appears that could not be mounted, and asks if I want to eject or format. (2 HDs in raid and 1 normal).

 

Yep, now I've removed "AppleIntelCPUPowerManagement.kext" from Clover.

Check here：https://pikeralpha.wordpress.com/2017/08/05/osinstall-mpkg-appears-to-be-missing-or-damaged/

First I thought it was a RAM problem; I kept only two modules. Same crash.

Here my screen capture:

hi, have you tried the solution here:http://www.insanelymac.com/forum/topic/326200-new-possibilities-for-x79-appleacpiplatform-panic/?p=2480719

[jcds83]

Hi Cheneyveron,

 

Thanks for your advices.

• drop MATS/BGRT table( or other table ) in Clover "ACPI" -> "Table Dropping"   -> Done
• add FixHeaders_20000000 in clover ACPI patch. <- this requires the latest Clover. -> Done
• Modify MATS/BGRT/other table and change the char to lower than 0x80.<- this can be done using a hex editor. Remeber to correct the checksum with the latest Rehabman's Maciasl. -> How and where do you modify MATS/BGRT table?

I try whatever to install High Sierra; the installer went a bit further but stalled on disk4s1: the USB key.

 

jcds83

[cheneyveron]

Hi Cheneyveron,

 

Thanks for your advices.

• drop MATS/BGRT table( or other table ) in Clover "ACPI" -> "Table Dropping"   -> Done
• add FixHeaders_20000000 in clover ACPI patch. <- this requires the latest Clover. -> Done
• Modify MATS/BGRT/other table and change the char to lower than 0x80.<- this can be done using a hex editor. Remeber to correct the checksum with the latest Rehabman's Maciasl. -> How and where do you modify MATS/BGRT table?

I try whatever to install High Sierra; the installer went a bit further but stalled on disk4s1: the USB key.

 

jcds83

glad it helped. As for USB, I would check the driver for update or seek if the dsdt fits the system

U can use a Hex editor or Maciasl to edit MATS/BGRT table.

[Arkanis]

Guys,

 

I'm currently running an X9DAi (Supermicro) with dual Xeons Sandy Bridge and 32Gb, it is working perfectly under 10.12.6... alas for 10.13 I'm getting the same problem with AppleACPIPlatform as you guys.

 

I've already done steps 1 and 2, and I've edited the AppleACPIPlatform binary following Pike's guide but still no dice. So what I did is install High Sierra (last PB) from my Sierra install, then proceeded to replace AppleACPIPlatform with the one from 10.12.6. I know this is not optimal but it gets me passed the Kernel Panic and the _isprint error.

 

Problem is that then I stumble on another problem, screen gets garbled and then the stop sign appears... Maybe some of you have a clue about this ? I'm attaching here my SSD and my config.plist.

 

Any help would be greatly appreciated, thank you already for all the research you guys have been doing.

 

 

 

 

config.plist.zip

SSDT.aml.zip

[cheneyveron]

Guys,

 

I'm currently running an X9DAi (Supermicro) with dual Xeons Sandy Bridge and 32Gb, it is working perfectly under 10.12.6... alas for 10.13 I'm getting the same problem with AppleACPIPlatform as you guys.

 

I've already done steps 1 and 2, and I've edited the AppleACPIPlatform binary following Pike's guide but still no dice. So what I did is install High Sierra (last PB) from my Sierra install, then proceeded to replace AppleACPIPlatform with the one from 10.12.6. I know this is not optimal but it gets me passed the Kernel Panic and the _isprint error.

 

Problem is that then I stumble on another problem, screen gets garbled and then the stop sign appears... Maybe some of you have a clue about this ? I'm attaching here my SSD and my config.plist.

 

Any help would be greatly appreciated, thank you already for all the research you guys have been doing.

It is very likely you're facing ACPI tables problems. If you're really stucking at isprint, then method 1 and 2 should work. Since they do not work, you may need to check your ACPI tables.

[Arkanis]

Thank you for the reply, any advice on how to do that and what to look for ?

 

Guess I can extract those with MacIASL I suppose ? but then what should I do ?

 

P.S: Any idea when replacing the AppleACPI why the screen gets garbled ? I looks like the old USB problem, but I'm already fixing that in the SSDT normally...  Here are the screenshots:

 

 

 

 

[cheneyveron]

Thank you for the reply, any advice on how to do that and what to look for ?

 

Guess I can extract those with MacIASL I suppose ? but then what should I do ?

There're many docs on extracting, decompiling and editing ACPI tables, which you can search on your own. After decompiling, you may find the unprintable char in whatever table.

[Arkanis]

Sure I've already found docs for extracting and such, I'm just a little clueless on what to look exactly for and with what should I replace it.

 

My daily bread is design not code , so I'm cautious on this and prefer to ask.

[Gen_]

Sure I've already found docs for extracting and such, I'm just a little clueless on what to look exactly for and with what should I replace it.

 

My daily bread is design not code , so I'm cautious on this and prefer to ask.

Even if you daily bread was code, you wouldn't know what to look for and what to replace it with without several hours if not days of research on the ACPI standard and how Apple's ACPI conventions differ. This is not a problem with a 'replace x with y' solution, nor is it a problem that's even been fixed yet really. It's still a strictly programmers problem until it's understood because there are people here that have done things that should fix it but didn't. Right now they are doing the Hackintosh equivalent of prodding the strange x79 High Sierra creature with a stick to see if it moves so you are right to be cautious lol. 

 

It takes some studying of Apple's existing stuff to learn what youre doing, on top of programming ability... because you're not going to get their own whitepaper specification. A DSDT is in every computer AND Mac, but much like EFI is in every computer, Apple lays waste to the public spec in order to ensure compatibility issues, adds plenty of it's own stuff, and keeps their own private spec to ensure that OSX stays (mostly) on Macs. To make matters worse, your x79/C600 DSDT is likely 3 to 10 times bigger and more complex than Apple's equivalent for whatever Mac is in your SMBIOS... And is practically the only chipset that ever came out and was entirely ignored by Apple, giving vanilla OSX very little knowledge of your device off the bat... with more logic being done by the DSDT (this is just how Intel made X79) to access your much bigger array of connectivity and features... This is why everyone here is using a DSDT when most Hackintoshes in the wild can run 100% DSDT free with kexts. X79 needs a lot of actually reprogramming.

 

Anyway, this is not a stable, functional set of changes that are being made with full understanding of their effects.... this is bare metal 'try it and see even if I may break my computer' reverse engineering, and it's more than likely that by DP2 or release the changes needed will be entirely different and may break hacks with this change implemented anyway. Apple does a lot between DPs, and rolls back half of the changes they make later. 

 

Oh and FYI, anywhere you see people talking about Assembler, run. Run and don't look back, for there is serious geekery afoot.   To read even 1 kext entirely in assembler would probably take a week and you'll only see it when those far more hardcore than I are reverse engineering and researching.