Jump to content
30960 posts in this topic

Recommended Posts

AptioFix2 does not relocate the allocation for the kernel, where AptioFix does. Use whichever works. There are modified versions, DO NOT USE THEM, because they free random regions of memory, you don't want this.

This tip is for the all Hacks (old and new ones)?

 

Thanks

This tip is for the all Hacks (old and new ones)?

 

Thanks

 

Unsure what you mean? Only use AptioFix, AptioFix2, or LowMemFix. Those other drivers are not a good idea, if they were, I would have implemented it in the drivers already. They came about from a proof of concept and conversation I had with Nick on sf.net. They are terrible drivers intended only to help me resolve the issue, which actually was never really resolved. I had another idea a minute back to try to reserve the region first, then free region before actual boot, appears this would be the best solution. However, I am not in the best of health and can't really get stuff done as I'd like.... My computer was also stolen, so I lost everything I was developing....

 

EDIT: If someone would like to modify those drivers to achieve this here is a basic algorithm:

 

1. Start with slide=0 and a max region size, probably 0x20000 pages is good.

2. Get memory map.

3. Search memory map for free region(s). Calculate the slide that each region would require [slide = (address - 0x100000) / 0x200000]. Notice that this can put you above or below the starting address, so you have to make sure it's still inside the region and adjust the page count accordingly. Choose the lowest slide with the largest free region, the first region with max pages should be chosen and searching can stop. Actually the memory map may not be in order...

4. Allocate this region to prevent it from being used.

5. Add (or modify) slide=X argument for entry if it's boot.efi, where X is the slide that was just calculated in step 3.

6. Free this region when a loader is started.

 

This driver would need to be specially loaded before any other drivers so the drivers loading would need to be modified - it would also help if the driver was loaded at top of memory to prevent from using prime real estate in low memory.

  • Like 2

I've mean that we shouldn't use these drivers in the new Hardwares as @oSxFr33k has mentioned (Skylake board)? Or in the old Hardwares as mine (Ivy Bridge), if these drivers can be dangerous.

 

Yeah, do not use them unless it's entirely a last resort, legacy booting should be attempted first. It's very likely they will result in unintended side effects, especially if the region is needed for a device. Really even LowMemFix probably shouldn't be used as it also just releases low memory regions, however it's for specific hardware that is known not to have an issue with releasing these regions...

  • Like 3

Yeah, do not use them unless it's entirely a last resort, legacy booting should be attempted first. It's very likely they will result in unintended side effects, especially if the region is needed for a device. Really even LowMemFix probably shouldn't be used as it also just releases low memory regions, however it's for specific hardware that is known not to have an issue with releasing these regions...

Thank you so much @apianti, I'm gonna do this here right now!  ;)

I've mean that we shouldn't use these drivers in the new Hardwares as @oSxFr33k has mentioned (Skylake board)? Or in the old Hardwares as mine (Ivy Bridge), if these drivers can be dangerous.

On my skylake board osxaptiofix2 works fine.

On my skylake board osxaptiofix2 works fine.

I used osxaptiofix2 on my skylake but I recently switched to OsxAptioFixDrv-64 and it seems to be working better that the other one (at least for me).

I also used osxaptiofix2 on my Ivy-Bridge and it started to acting up specially when I used RC Scripts, the computer couldn't boot I had to reset the BIOS. After running some tests I noticed that the RC Script was causing the problem in combination with osxaptiofix2 so I switched form osxaptiofix2 to OsxAptioFixDrv-64 instead (On both systems). I still don't use RC Scripts on my IvyBridge (Second system in my signature) but it has no problem on my SkyLake.

@slice,

 

I was referring to the modified drivers, the originals should work fine. However, I know that AptioFix2 has a bug in it somewhere determining the page count(s) but I can't seem to figure out where. As you shouldn't have a problem ever allocating the memory with AptioFix2, yet it sometimes tries to allocate less than it needs resulting in some users forced to use AptioFix.

 

@DF,

 

Well because the problem is that for some reason firmwares have started randomizing the address where drivers are loading. So instead of the drivers getting clumped together at the top or bottom of memory they are randomly dispersed, effectively fragmenting the memory beyond the ability to have a region big enough to load the kernel space. There is of course no reasonable fix for firmwares that do this and are loading lots of device option ROMs, that would involve modifying the firmware and as far as I know only appears to be X99 related, I haven't seen this problem in other platforms. Of course it could just be that X99 mobos happen to be able to support a lot of devices.... But this problem started appearing with that platform and has never really went away, I'm guessing that aptio firmwares were changed around this point to allocate memory differently.

 

EDIT: Should also point out that the more EFI drivers you have in drivers folder loading and more kexts that are injected, the more likely you are to get a failed boot due to not a large enough free region.

EDIT2: The advice - if you are getting this error, remove as many EFI drivers and injected kexts as possible. Then try the other AptioFix, then try legacy boot. Then probably just give up and cry.... lol

  • Like 2

I used osxaptiofix2 on my skylake but I recently switched to OsxAptioFixDrv-64 and it seems to be working better that the other one (at least for me).

I also used osxaptiofix2 on my Ivy-Bridge and it started to acting up specially when I used RC Scripts, the computer couldn't boot I had to reset the BIOS. After running some tests I noticed that the RC Script was causing the problem in combination with osxaptiofix2 so I switched form osxaptiofix2 to OsxAptioFixDrv-64 instead (On both systems). I still don't use RC Scripts on my IvyBridge (Second system in my signature) but it has no problem on my SkyLake.

My case, rare(random) failed boot(maybe shorted enter osx,apple logo stop)

All My build switched osxaptiofixv2 to osxaptiofixv2-free2000+apianti's slide method.

free2000 supported single mode correctly and stable(never see failed boot case) for all my build. Long time ago, i reported this true on bug/report thread.

 

As result, i dont worry aptio issue.

 

나의 LG-F800S 의 Tapatalk에서 보냄

  • Like 1

My case, rare(random) failed boot(maybe shorted enter osx,apple logo stop)

All My build switched osxaptiofixv2 to osxaptiofixv2-free2000+apianti's slide method.

free2000 supported single mode correctly and stable for all my build. Long time ago, i reported this true on bug/report thread.

 

나의 LG-F800S 의 Tapatalk에서 보냄

So is it safe for me to use RC Scripts on my IvyBridge again? I really don't like to open the case again because the clear CMOS jumper is beneath the GPU and I have to take it out to reset the BIOS. :rofl:

So is it safe for me to use RC Scripts on my IvyBridge again? I really don't like to open the case again because the clear CMOS jumper is beneath the GPU and I have to take it out to reset the BIOS. :rofl:

My skylake laptop and skylake desktop(pentium) use rc script for unsupported native nvram on bios.

 

I never see cmos issue. Try it. But not sure your case

 

나의 LG-F800S 의 Tapatalk에서 보냄

  • Like 1

My case, rare(random) failed boot(maybe shorted enter osx,apple logo stop)

All My build switched osxaptiofixv2 to osxaptiofixv2-free2000+apianti's slide method.

free2000 supported single mode correctly and stable(never see failed boot case) for all my build. Long time ago, i reported this true on bug/report thread.

 

As result, i dont worry aptio issue.

 

My whole point is that you should NOT use that modified driver. It's just freeing memory without regard to what that memory is...

 

 

So is it safe for me to use RC Scripts on my IvyBridge again? I really don't like to open the case again because the clear CMOS jumper is beneath the GPU and I have to take it out to reset the BIOS. :rofl:

 

You really only need the RC scripts if you want to like save boot.log, mount ESP by default, or don't have working NVRAM and use emulation. Otherwise you don't need them.

  • Like 3

My whole point is that you should NOT use that modified driver. It's just freeing memory without regard to what that memory is...

 

 

 

You really only need the RC scripts if you want to like save boot.log, mount ESP by default, or don't have working NVRAM and use emulation. Otherwise you don't need them.

Thanks for the info. So I won't be needing the RC Scripts on my IvyBridge because I don't need any of these on my test rig. :)

AMD sleep wake needs IGPU and connection to monitor. If no monitor is connected to IGPU no Wake.

Hm, no, I did :

 

- Set Igpu As primary

- connected monitor to amd

- Removed all Intel kexts except Azul frame buffer

 

In result, Igpu is not available in macos, but sleep wakeup works. Azul frame buffer is loaded.

 

Now if I also remove Intel Azul frame buffer, sleep does not work.

 

So I conclude in that frame buffer there must be some essential code to make wakeup work. If that code could be run without igpu as primary, maybe sleep wakeup still would work?

 

Edit: nvm, these are too individual problems, I didn't realize. The Azul frame buffer is needed to enter sleep, but not for wakeup.

 

What, if clover could display on secondary gfx device (if only there a monitor is attached)? Is that possible?

That's because the legacy layer (CSM) is limited to few 4:3 resolutions (may vary for the different boards). The UEFI native mode has no such limitations. The only requirement is the Video BIOS to be UEFI - compatible as well (mostly for all external video cards).

 

Sent from my MI 5s using Tapatalk

That's because the legacy layer (CSM) is limited to few 4:3 resolutions (may vary for the different boards). The UEFI native mode has no such limitations. The only requirement is the Video BIOS to be UEFI - compatible as well (mostly for all external video cards).

 

Maybe it sounds strange. My CSM always disabled & looks differ when I boot to Windows with Clover vs Ozmosis / direct from boot menu.

That's because the legacy layer (CSM) is limited to few 4:3 resolutions (may vary for the different boards). The UEFI native mode has no such limitations. The only requirement is the Video BIOS to be UEFI - compatible as well (mostly for all external video cards).

 

Sent from my MI 5s using Tapatalk

So not compatible for Internal HD Graphics 4000 ?

×
×
  • Create New...