Jump to content

Clover Problems and Solutions


ErmaC
3,206 posts in this topic

Recommended Posts

Solved by adding line below, in "Settings.c"

GetUserSettings(
  IN  EFI_FILE *RootDir,
      TagPtr CfgDict
      )
{
  ...
    // KernelAndKextPatches
    DictPointer = GetProperty (Dict, "KernelAndKextPatches");
    if (DictPointer != NULL) {
      FillinKextPatches ((KERNEL_AND_KEXT_PATCHES *)(((UINTN)&gSettings) + OFFSET_OF(SETTINGS_DATA, KernelAndKextPatches)), DictPointer);
    }
    SaveSettings();
  }
//DBG ("config.plist read and return %r\n", Status);
  return EFI_SUCCESS;
}
Link to comment
Share on other sites

 

Solved by adding line below, in "Settings.c"

GetUserSettings(
  IN  EFI_FILE *RootDir,
      TagPtr CfgDict
      )
{
  ...
    // KernelAndKextPatches
    DictPointer = GetProperty (Dict, "KernelAndKextPatches");
    if (DictPointer != NULL) {
      FillinKextPatches ((KERNEL_AND_KEXT_PATCHES *)(((UINTN)&gSettings) + OFFSET_OF(SETTINGS_DATA, KernelAndKextPatches)), DictPointer);
    }
    SaveSettings();
  }
//DBG ("config.plist read and return %r\n", Status);
  return EFI_SUCCESS;
}

Sorry,

You said that KernelAndKextPatches should be at bottom of GetUserSettings()? line 4738?

It present at line 2058.  :huh:

Link to comment
Share on other sites

Hello, im blind in C coding, so dont know which procedure are invoked first
I thought Clover just forgot / incomplete to re-read some of user settings with given new config name from GUI menu after read default config.plist.
Although i solved my problem with patch above, thanks for the answer..

Link to comment
Share on other sites

Clover 3272 cannot boot my Z97 Gryphon workstation, but I am successfully booting it with Clover 3229. It hasn't been bootable with newer builds for quite a while but I'd like to get it squared away before release of 10.11 if I can. I'm using the same config.plist, but this is a photo of the display when I boot into verbose mode with 3272. Symptoms without verbose mode are just a status bar under the logo that appears stuck indefinitely.

 

21650349351_2451664208_c.jpg

 

I have a zpool with an SSD for zil and l2arc installed on this workstation in addition to the OS and applications SSD which is HFS+. 

 

One thing I found puzzling is that:

 

## 3272

2:319  0:000  found 39 volumes with blockIO

while

 

## 3229

3:330  0:000  found 34 volumes with blockIO

Both Clover instances arrive at the Clover GUI correctly and default to the correct boot volume and successfully (apparently insert nvram values and EFI payloads.)

 

Both get my boot variables as well. Mostly. My config has:

<string>slide=0 darkwake=10 nvda_drv=1 kext-dev-mode=1 keepsyms=y</string>

But both record in preboot:

 

## 3272

2:608  0:000  found boot-args in NVRAM:kext-dev-mode=1 keepsyms=y nvda_drv=1, size=37

## 3329

3:444  0:000  found boot-args in NVRAM:kext-dev-mode=1 keepsyms=y nvda_drv=1, size=37

So not everything is making it into nvram? 

 

My config.plist is available on pastebin.

 

I'm not opposed to spamming pastebin urls of my preboot logs if it's relevant, I just don't know how to proceed debugging on my own at this point.

 

Note: I use RampageDev's SSDT on this workstation and apply Clover-centric fixes for the audio device but I use SPDIF into my audio equipment for digital audio.

Link to comment
Share on other sites

3272 works fine here on the same board.

 

Any chance I could eyeball your config and see what I'm doing wrong? I'd hate to think it's my zfs pool confusing things; that would be a big problem for me. I'm not trying to do anything stupid like boot off it or anything so I don't think it's related.

 

No longer desired, issue was with my SSDT-1 that I believe Toleda's script created? At any rate, removing that file and it's fine. I went back to Voodoo HD for my audio since I only use USB devices and SPDIF anyway.

Link to comment
Share on other sites

I was working on one of my projects here, starting to use config.plist/ACPI/DSDT/Patches a bit more heavily...

 

With each patch added, I noticed time to the Apple logo getting longer and longer... as if the simple search/replace in DSDT/Patches was taking a very long time to process.

 

So... I had a look at the code and discovered a few things...

 

First in the case of equal sized find/replace, move_data is called with offset=0. In that instance it does not need to move any data

 

change:

UINT32 move_data(UINT32 start, UINT8* buffer, UINT32 len, INT32 offset)
{
  UINT32 i;
  
  if (offset<0) {
    for (i=start; i<len+offset; i++) {
      buffer[i] = buffer[i-offset];
    }
  }
  else { // data move to back
    for (i=len-1; i>=start; i--) {
      buffer[i+offset] = buffer[i];
    }
  }
  return len + offset;
}
to:

UINT32 move_data(UINT32 start, UINT8* buffer, UINT32 len, INT32 offset)
{
  UINT32 i;
  
  if (offset<0) {
    for (i=start; i<len+offset; i++) {
      buffer[i] = buffer[i-offset];
    }
  }
  else if (offset>0) { // data move to back
    for (i=len-1; i>=start; i--) {
      buffer[i+offset] = buffer[i];
    }
  }
  return len + offset;
}
When offset==0, buffer[i+offset] refers to the same memory location as buffer. The read/store loop is not needed.

 

OK, but that still didn't improve the performance significantly, so I started looking closer at FixAny.

 

  for (i = 20; i < len; i++) {
    adr = FindBin(dsdt + i, len, ToFind, LenTF);
FindBin searches for ToFind at the data pointed at by dsdt+i for len bytes. The len is the entire length of the AML. Note that len is not adjusted to account for the starting point of the search. Hence it is searching (and potentially replacing) beyond the bounds of the AML being patched.

 

Corrected code:

  for (i = 20; i < len; i++) {
    adr = FindBin(dsdt + i, len - i, ToFind, LenTF);
And some attention to the loop here...

  for (i = 20; i < len; i++) {
    adr = FindBin(dsdt + i, len - i, ToFind, LenTF);
FindBin searches the entire AML for the pattern, so this loop (between the two bugs mentioned above) is O*N^2...

Since FindBin returns the index of the found pattern, there is no need to search data prior to the end of the replacement data on subsequent iterations.

 

Tweaked loop:

  for (i = 20; i < len; ) {
...
    i = i + adr + LenTR;
  }
Essentially, we can skip past the end of the replacement and search from that point to the end...

 

But we need to deal with the case that LenTR is zero, as code higher in the call hierarchy does not check.

 

From:

   BOOLEAN found = FALSE;
   if (!ToFind) {
     return len;
   }
To:

   BOOLEAN found = FALSE;
   if (!ToFind || !LenTF || !LenTR) {
     return len;
   }
Please do check my work.

 

I'm testing it and it is working for me (all expected patches are still applied as before), but it is faster. Ummm... a LOT faster.

 

The full diffs (against v3277) are here:

Speedy-OSX:Clover RehabMan$ svn diff
Index: rEFIt_UEFI/Platform/FixBiosDsdt.c
===================================================================
--- rEFIt_UEFI/Platform/FixBiosDsdt.c	(revision 3277)
+++ rEFIt_UEFI/Platform/FixBiosDsdt.c	(working copy)
@@ -1077,7 +1077,7 @@
       buffer[i] = buffer[i-offset];
     }
   }
-  else  { // data move to back        
+  else if (offset>0) { // data move to back
     for (i=len-1; i>=start; i--) {
       buffer[i+offset] = buffer[i];
     }
@@ -1687,7 +1687,7 @@
   INT32 sizeoffset, adr;
   UINT32 i;
   BOOLEAN found = FALSE;
-  if (!ToFind) {
+  if (!ToFind || !LenTF || !LenTR) {
     return len;
   }
   DBG(" patch pattern %01x%01x%01x%01x\n", ToFind[0], ToFind[1], ToFind[2], ToFind[3]);
@@ -1696,8 +1696,8 @@
     return len;
   }
   sizeoffset = LenTR - LenTF;
-  for (i = 20; i < len; i++) {
-    adr = FindBin(dsdt + i, len, ToFind, LenTF);
+  for (i = 20; i < len; ) {
+    adr = FindBin(dsdt + i, len - i, ToFind, LenTF);
     if (adr < 0) {
       if (!found) {
         DBG("  bin not found\n");
@@ -1712,6 +1712,7 @@
     }
     len = CorrectOuterMethod(dsdt, len, adr + i - 2, sizeoffset);
     len = CorrectOuters(dsdt, len, adr + i - 3, sizeoffset);
+    i = i + adr + LenTR;
   }
 
   return len;
Also, whoever accepts this might want to fix this small cosmetic (but potentially confusing) problem:

-  DBG(" patch pattern %01x%01x%01x%01x\n", ToFind[0], ToFind[1], ToFind[2], ToFind[3]);
+  DBG(" patch pattern %02x%02x%02x%02x\n", ToFind[0], ToFind[1], ToFind[2], ToFind[3]);
  • Like 2
Link to comment
Share on other sites

Here's another for you.

 

Problem: Devices/Arbitrary is broken.

 

Problems:

- in most cases, it causes a hang before reaching the Apple logo. Endless loop is the problem.

- fixing the looping bug, bogus data is injected due to using the wrong index (i vs. PropIndex)

- zero length data properties are not accommodated (needed for PinConfigurations injection on HDA)

 

Index: rEFIt_UEFI/Platform/Settings.c
===================================================================
--- rEFIt_UEFI/Platform/Settings.c	(revision 3277)
+++ rEFIt_UEFI/Platform/Settings.c	(working copy)
@@ -403,7 +403,7 @@
     
   Prop = GetProperty (Dict, PropName);
   if (Prop != NULL) {
-    if (Prop->data != NULL && Prop->dataLen > 0) {
+    if (Prop->data != NULL /*&& Prop->dataLen > 0*/) { //rehabman: allow zero length data
       // data property
       Data = AllocateZeroPool (Prop->dataLen);
       CopyMem (Data, Prop->data, Prop->dataLen);
@@ -3557,7 +3557,7 @@
               
               for (PropIndex = 0; PropIndex < PropCount; PropIndex++) {
                 UINTN Size = 0;
-                if (!EFI_ERROR (GetElement (Dict2, i, &Dict3))) {
+                if (!EFI_ERROR (GetElement (Dict2, PropIndex, &Dict3))) {
                   
                   DevProp = gSettings.AddProperties;
                   gSettings.AddProperties = AllocateZeroPool (sizeof(DEV_PROPERTY));
@@ -3583,7 +3583,7 @@
                     //else  data
                     gSettings.AddProperties->Value = GetDataSetting (Dict3, "Value", &Size);
                     gSettings.AddProperties->ValueLen = Size;
                 }
                // gSettings.NrAddProperties++;
               }   //for() device properties
@@ -5246,6 +5246,7 @@
           }
           while (Prop) {
             if (Prop->Device != PCIdevice.dev.addr) {
+              Prop = Prop->Next;
               continue;
             }
             if (Once) {
Index: rEFIt_UEFI/Platform/device_inject.c
===================================================================
--- rEFIt_UEFI/Platform/device_inject.c	(revision 3277)
+++ rEFIt_UEFI/Platform/device_inject.c	(working copy)
@@ -211,7 +211,7 @@
   UINT32 *datalength;
   UINT8 *newdata;
   
-  if(!device || !nm || !vl || !len)
+  if(!device || !nm || !vl /*|| !len*/) //rehabman: allow zero length data
     return FALSE;
   /*	DBG("devprop_add_value %a=", nm);
    for (i=0; i<len; i++) {
  • Like 2
Link to comment
Share on other sites

I edited my SSDT :

EHC1 > EH01

EHC2 > EH02

XHC > XHC1

And add your kext to /EFI kext folder 

 

And it seems to work !!! Thanks a lot !  :D

 

So it was not really Clover related ...

I changed my mind and tried other solutions to get vanilla support for my USB ... I just added :

<key>ACPI</key>
	<dict>
		<key>DSDT</key>
		<dict>
...
			<key>Fixes</key>
			<dict>
				<key>FixShutdown_0004</key>
				<true/>
			</dict>
		</dict>
...

And it worked ... so it was Clover related (DSDT in fact) !

 

All my USB port are handled by XHC though ... but at the right speed so I don't mind  :P

Link to comment
Share on other sites

And it worked ... so it was Clover related (DSDT in fact) !

 

All my USB port are handled by XHC though ... but at the right speed so I don't mind  :P

 

Which is more likely: your USB ports are working because of a kernel extension and SSDT change you made, or the addition of a completely unrelated DSDT patch mask to Clover that adds a method to _PTS at shutdown? 

Link to comment
Share on other sites

With this way, i could force clover to detect & inject my intel even as 2nd display (nvidia as primary)

0:100  0:000  PCI (00|01:00.00) : 10DE 0FC6 class=030000 | 03 00 PCI_CLASS_DISPLAY_VGA
0:100  0:000  Found NVidia model=MSi GeForce GTX 650
0:100  0:000  PCI (00|01:00.01) : 10DE 0E1B class=040300
0:100  0:000  PCI (00|00:02.00) : 8086 0162 class=038000 | 03 80 PCI_CLASS_DISPLAY_OTHER
0:100  0:000  Found GFX model=Intel HD Graphics 4000
--- /Original/Settings.c 2015-12-17 10:48:29.000000000
+++ /Patch/Settings.c 2015-12-04 19:43:49.000000000
@@ -5039,12 +5039,14 @@
             Pci.Hdr.ClassCode[0]
             );

         // GFX
         if ((Pci.Hdr.ClassCode[2] == PCI_CLASS_DISPLAY) &&
-            (Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_VGA) &&
+            ((Pci.Hdr.ClassCode[1] == (PCI_CLASS_DISPLAY_VGA)) ||
+            (Pci.Hdr.ClassCode[1] == (PCI_CLASS_DISPLAY_OTHER))) &&
             (NGFX < 4)) {
           GFX_PROPERTIES *gfx = &gGraphics[NGFX];
           gfx->DeviceID       = Pci.Hdr.DeviceId;
           gfx->Segment        = Segment;
           gfx->Bus            = Bus;
           gfx->Device         = Device;
@@ -5290,12 +5292,14 @@
                Bus, Device, Function);
           continue;
         }
         // GFX
         if (/* gSettings.GraphicsInjector && */
             (Pci.Hdr.ClassCode[2] == PCI_CLASS_DISPLAY) &&
-            (Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_VGA)) {
+            //(Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_VGA)) {
+            ((Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_VGA) || (Pci.Hdr.ClassCode[1] == PCI_CLASS_DISPLAY_OTHER))) {
           UINT32 LevelW = 0xC0000000;
           UINT32 IntelDisable = 0x03;

//        gGraphics.DeviceID = Pci.Hdr.DeviceId;

Edit: with rev 3330

Edited by cecekpawon
  • Like 1
Link to comment
Share on other sites

Which is more likely: your USB ports are working because of a kernel extension and SSDT change you made, or the addition of a completely unrelated DSDT patch mask to Clover that adds a method to _PTS at shutdown? 

 

I don't know and i can't see a method to determine this. Those two configurations work:

 

- Nothing USB related (except cosmetic USB by SSDT, no EHC1>EH01, no dummy/Rehabman's kext ...) + Clover "Shutdown Fix"

- SSDT edit (EHC1>EH01 ...) + Rehabman's kexts (no clover shutdown fix) 

Link to comment
Share on other sites

Hi,

 

Clover 3270 (Release) on X9Dai Dual CPU/PCI-Bus Motherboard with El Capitan (Release) reports only half of Memory Slots AND half of Memory.

In Yosemite, amount of Memory was ok, but also only half of the slots was reported. The Slot Detection Mechanism changed after Clover 3113, before Clover detected 16 Slots.

 

Secondly, I assume related to this Bug, the El Capitan System reports (hardwired) PhysMem: 16T used (16T wired), 86G unused. VM: 754G vsize, 467M framework vsize, so somehow the reported Physical Memory falls back to the maximum amount of addressable Memory as a static value. The 86G unused are connected to my total amount of Ram (96GB) i assume, so this is weird.

 

Attached is Darwindumper output and Screenshot of Activity Monitor.

 

If anyone needs more information, please post.

 

Thanks,

 

 

000_2015-10-05_21-41-49_MacPro5,1.zip

post-478472-0-76976200-1444128085_thumb.png

Link to comment
Share on other sites

I mentioned this bug in the general discussion but as it's now the sole cause for me to use SSDT injection I'll bring it up here as well.

 

My P9X79 doesn't have a HDEF device in the DSDT. With FixHDA and Devices\Audio\Inject properties set in Clover's config it creates the HDEF device and properties, but in the wrong path. It should be PCI0\HDEF but instead it creates it in PCI0\^UNC0\HDEF. As a result audio doesn't work.

 

On my P8Z68 which has a HDEF device the same config entries work fine. Clover just injects the values for layout-id, pinconfig etc into the existing device.

 

The issue appears to be when Clover has to create the device entry from scratch.

Link to comment
Share on other sites

My P9X79 doesn't have a HDEF device in the DSDT. With FixHDA and Devices\Audio\Inject properties set in Clover's config it creates the HDEF device and properties, but in the wrong path. It should be PCI0\HDEF but instead it creates it in PCI0\^UNC0\HDEF.

I think this is a right path. Look ioreg.

Link to comment
Share on other sites

Thanks for the feedback guys.

 

@Slice: There's no HDEF device in IOReg with Clover injection. Only when the device is injected via SSDT.aml (see attachments).

 

@WinstonAce: As far as I know (from looking at the Wiki) Devices\Audio is for injecting the layout-id. It won't create the HDEF device itself.

post-267996-0-90530800-1444243561_thumb.png

post-267996-0-46724400-1444243568_thumb.png

Link to comment
Share on other sites

Thanks for the feedback guys.

 

@Slice: There's no HDEF device in IOReg with Clover injection. Only when the device is injected via SSDT.aml.

 

@WinstonAce: As far as I know (from looking at the Wiki) Devices\Audio is for injecting the layout-id. It won't create the HDEF device itself.

What is the device ^UNC0?

It looks like it is the same PCI0 just in shred of DSDT.

Some DSDT is shredded into small pieces and Clover can't correctly calculate a path.

In such cases it is good to make own DSDT.

Link to comment
Share on other sites

@Slice: I've no idea what it is. But that's where Clover has decided to inject the HDEF device.

 

I know it can be fixed by DSDT/SSDT injection but I've managed to move all of the fixes I made using SSDT to Clover's config.plist. Now the only fix I still need a SSDT for is HDEF because of this path issue.

 

@WinstonAce: I tried with just Devices\Audio\Inject=1 but as I suspected, it didn't work. The core of the issue is lack of a HDEF device.

Link to comment
Share on other sites

What about EFI string injection?

let's say your HDEF(with ssdt) is under pci0@0 at 1B

you need to inject something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
  <dict>
      <key>layout-id</key>
      <string>0x00000001</string>
   </dict>
</dict>
</plist>

which in HEX is

e80000000100000001000000dc0000000500000002010c00d041030a0000000001010600001b7fff04001c0000007200650076006900730069006f006e002d00690064000000080000000100000018000000760065006e0064006f0072002d006900640000000800000086800000180000006c00610079006f00750074002d00690064000000080000000c0000002c000000730075006200730079007300740065006d002d00760065006e0064006f0072002d0069006400000008000000581400001e000000730075006200730079007300740065006d002d006900640000000800000002a00000

in clover you'll need to add this

 

<key>Devices</key>
<dict>
<key>Inject</key>
<true/>
<key>Properties</key>
<string>e80000000100000001000000dc0000000500000002010c00d041030a0000000001010600001b7fff04001c0000007200650076006900730069006f006e002d00690064000000080000000100000018000000760065006e0064006f0072002d006900640000000800000086800000180000006c00610079006f00750074002d00690064000000080000000c0000002c000000730075006200730079007300740065006d002d00760065006e0064006f0072002d0069006400000008000000581400001e000000730075006200730079007300740065006d002d006900640000000800000002a00000</string>
</dict>

Link to comment
Share on other sites

×
×
  • Create New...