Contribute
Register

[Solved] new possibilities for X79 AppleACPIPlatform panic

Status
Not open for further replies.
Joined
Aug 26, 2015
Messages
4
Motherboard
HUANAN X79 V2.46 C602 Chipset
CPU
E5-2670 V1 C2
Graphics
GTX 1050Ti
Mac
  1. MacBook Pro
Mobile Phone
  1. Android
  2. iOS
  3. Other
Hi guys,

My computer hardware is my 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: https://www.dropbox.com/s/izzhtildypf0ur1/IMG_1912.JPG?dl=0

Typical Causes and Solutions:
After searching google for couple of days and with the help of PMheart I found Alext James's article : http://alextjam.es/d...leacpiplatform/

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 here : https://www.dropbox....b/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:
Code:
                     _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:
Code:
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 cause 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:
Code:
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 sticks 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.
 

Attachments

  • dsdt+ssdt.zip
    12.2 KB · Views: 198
  • OriginACPI.zip
    24.5 KB · Views: 153
  • x7946.rom.zip
    4.4 MB · Views: 185
Last edited by a moderator:
hey... anyone here...
 
There is no requirement to host your images / files on third party sites - You may attach them to your posts here.
 
There is no requirement to host your images / files on third party sites - You may attach them to your posts here.
hi, I tried editing many times but the editor says it contains spam-like content and don't allow me to save...
the AppleACPIPlatform error:
IMG_1912.JPG
panic at isspace:
isspace.png
 
https://www.tonymacx86.com/threads/success-x79-ud5-10-13-high-sierra.226347/
Please check this. Using this config and all patches. and you would pass this panci.
Thanks buddy! You've been very helpful ;)
I finally solved this problem by modifying DSDT table.
Before modifying, my dsdt look like this:
processor2-modi.jpg

I deleted Device(SCK0) to Device(SCK3) and all things in the red box.
Finally after modifying, all Processor locate directly inside _SB instead of _SB.SCKN.
Hope you guys with X79 motherboard can solve this problem soon :)
 
I deleted Device(SCK0) to Device(SCK3) and all things in the red box.
Finally after modifying, all Processor locate directly inside _SB instead of _SB.SCKN.

Hey cheneyveron, Can you explain further what you did as I have similar motherboard and want to try to install HS 10.13.
Thanks
 
@cheneyveron
Followed your guide and worked was able to boot HS finally just deleted (SCK0) lines as detailed.made usb edits in clover to get my USB ported agin with injectALL method.now I can not shutdown .It only Reboots .I wanted to SSDT edit there see if that helps, not sure how to edit them ,or try another rout ,so far I ticked a lot of Clover options in Tables,SSDT to no avail
best,
Drone4zone
 
Status
Not open for further replies.
Back
Top