Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/03/2019 in all areas

  1. https://developer.apple.com/news/releases/?id=10032019a
    2 points
  2. 2 points
  3. Take a look to this part of Clover config.plist. May be this value helps you. <key>EDID</key> <dict> <key>HorizontalSyncPulseWidth</key> <string>0x11</string>
    2 points
  4. 1% chance that it is possible. look if you have some aptiofix or lowmemoryfix anywhere.
    2 points
  5. Apparently there is no coincidence that when the boot finishes faster, there is no flashing. Since this issue is time dependent. The issue seems to occur due to mode switching from ARGB8888 to ARGB2101010. And getting or not getting the flash depends on the point in time when that switch is performed. That's why sometimes we get a smaller flash, sometimes a bigger flash, and sometimes no flash at all. Good news is that there might be a fix for it. Bad news is that it requires Clover devs' help, since this can't be fixed with a DSDT patch. It needs to be done before MacOS is loaded. So...getting them to help with this might make the entire difference.
    2 points
  6. About the ports issue I was mentioning above, this is what the user gets when it can't access the site due to restricted ports. This is why I was suggesting switching from ftp:// to https:// so it can access the URLs. buildme, Clover v2.5k r5093 (SHA: 9ee0998f) TOOLCHAIN: GCC53 (override example: './buildme XCODE8') 1) build Clover 2) make pkg 3) make iso 4) build all 5) test build (no autogen, no boot files) 6) status 7) update Clover 8) update Clover (reset changes) 9) show diff 10) open drivers directory 11) clean BaseTools 12) quit Please enter your choice: 4 [CHECK XCODE] - Building GCC 9.2.0 toolchain for x64 - to /Users/jimmy/src/opt/local/cross/bin/x86_64-clover-linux-gnu Running on Mac OS X 10.15, with x86_64 architecture. Using Xcode SDK: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk Status: gmp-6.1.2 not found. % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:02:36 --:--:-- 0 curl: (7) Failed to connect to ftp.gnu.org port 21: Operation timed out logout Saving session... ...copying shared history... ...saving history...truncating history files... ...completed. Deleting expired sessions...35 completed. [Process completed] This issue does not occur when building with ".buildme XCODE8", I'm guessing probably because it's not using those URLs in this case. Also, there might be a fix to the forever known "screen flashes on boot" for AMD video cards. The issue seems to occur due to mode switching from ARGB8888 to ARGB2101010. And it might require something similar to RadeonDeInit which was already implemented a while ago. So it needs Clover devs' help. So...anyone willing to help fix this ancient issue once and for all? If you guys already know what I'm talking about, then I guess you don't need more details. If not, I can provide more info, if anyone's interested in helping with a fix.
    2 points
  7. Being asked to add support for Realtek's Fast Ethernet PCIe NICs to my RTL8111 driver I got tired of answering the same old question again and again so that I finally decided to write a separate driver for these chips and to make a few of you guys and gals happy. As of now the driver supports the following members the RTL810X Fast Ethernet family: RTL8101E RTL8102E RTL8103E RTL8401E RTL8105E RTL8402 RTL8106E RTL8106EUS RTL8107E Here is a list of the driver's basic features: Supports Sierra (maybe El Capitan). 64 bit architecture only. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). TCP segmentation offload under IPv4. Support for TCP/IPv6 and UDP/IPv6 checksum offload. Supports Wake on LAN. Support for Energy Efficient Ethernet (EEE) which can be disabled by setting enableEEE to NO in the drivers Info.plist without rebuild. The default is YES. The driver is published under GPLv2. Built using Xcode 4.6.3. Changelog Version 2.0.1 (2018-05-10): Fixes a problem with retrieval of the permanent MAC address on some chips. Version 2.0.0 (2017-04-04): Uses Apple's private driver interface introduced with 10.8. Adds support for the RTL8107E. Supports packet scheduling with QFQ. Adds support for flow control and EEE. Version 1.0.0 (2014-05-24): First offical release. Installation Before you install the driver you have to remove any installed driver for RTL810X. Goto /S/L/E and delete the old driver. Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. g. en0. If you forget this step you might experience strange problems with certain Apple domains, iTunes and iCloud later. Install the new driver and recreate the kernel cache. Reboot Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface. Help - I'm getting kernel panics! Well, before you start complaining about bugs after you upgraded macOS and ask me to publish a driver update, you should first try to resolve the issue on your own by cleaning the system caches. As the driver uses macOS's private network driver interface, which is supposed to be used by Apple provided drivers only, you might run into problems after an OS update because the linker may fail to recognize that IONetworking.kext has been updated and that the driver needs to be linked against the new version (Apple provided drivers avoid this problem because they are always updated together with IONetworking.kext). As a result, the linking process produces garbage and the driver may call arbitrary code when trying to call functions from IONetworking.kext. This usually results in unpredicted behavior or a kernel panic. In order to recover from such a situation, you should clean the System Caches forcing the linker to recreate it's caches: Delete all the files in /System/Library/Caches and it's subdirectories but leave the directories and the symbolic links intact. This is very important! Reboot. Recreate the kernel cache. Reboot again. Troubleshooting Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be retrieved with "grep kernel /var/log/system.log" in Terminal. Starting from Sierra use "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Don't copy and paste large amounts of log data to your post. Create an archive with the log data and attach it to your post. In case you don't want to make your log data publicly accessible, contact me via PM and I will provide you a mail address to send it directly to me.  Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver. Double check that you have removed any other Realtek kext from your system because they could prevent the driver from working properly. Delete the following files: /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000. In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard, different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable. Getting the driver There is a prebuilt binary in the Download section of this site: http://www.insanelymac.com/forum/files/file/259-realtekrtl8100-binary/ The source code can be found on Github: https://github.com/Mieze/RealtekRTL8100 Mieze
    1 point
  8. Yeah, you are right! I'll publish the official release during the next days! Mieze
    1 point
  9. In my own experience, and believe me, I've been trying to find a fix/workaround to this issue ever since I bought my RX 580, which was maybe a year ago, this doesn't help. But I'll let the others test the same thing in case they have more luck with this. For as far as I understood, the issue is the switch from ARGB8888 to ARGB2101010 which isn't synced to vertical blanking, causing the flash. And depending when that switch is performed, the intensity of the flash can vary, from almost full screen, to just a little bit at the bottom of the screen, and no flash at all sometimes. Additional info, such as setting up the hardware for ARGB2101010 mode can be found in the Radeon driver's source code here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/atombios_crtc.c?h=v5.4-rc1 Once that's done, the only remaining thing would be handing the information regarding framebuffer mode to MacOS. Which is where Clover would come really handy, since this needs to be done before MacOS is loaded.
    1 point
  10. Wow. Wonderful news. Hope we can get rid of this problem soon.
    1 point
  11. I assume this might be of interest here. Discovered quite by accident. I have a couple of Asrock ITX Z390 systems. At some point fairly recently i updated clover and it removed my AptioMemoryFix driver. The fun part is that these boards boot just fine without any aptio driver. Thats not supposed to be possible is it? g\
    1 point
  12. sim, tudo por lá vc pode usar o hackintool pra isso tb, mas é somente cosmético, não é solução nenhuma como um dsdt full patched
    1 point
  13. Big bug in Intel Power Gadget 3.6.1, first try return 0 randomly. Restart multiple time (joke) or use HWMonitorSMC2 v2.5.0
    1 point
  14. Is this possible to correct the Pure Legacy boot file and the Legacy script for installing in APFS System ?
    1 point
  15. in truth I see only two guys with this problem.. Can you remove boot sectors from /usr/standalone/i386 and retry?
    1 point
  16. ...but bootsectors are always installed in /usr/standalone/i386 even if you select the ESP..... if you install Clover EFI.
    1 point
  17. Well, I checked his changes and besides support for kernel debugging there is nothing useful in it. vit9696 and I, we had a discussion about a kernel panic he encountered while using IntelMausiEthernet.kext some time ago and he wanted to convince me that there is a bug in the driver. Tracing back the call chain in the kernel panic report he sent me, I finally came to the conclusion that it was a linker error, although he insisted on his point of view. Maybe that's one of the reasons why he forked. For a detailed explanation of the problem and how to avoid it (clean system caches), please see the section about kernel panics in post #1 of this thread. As already, mentioned, the only valuable addition is support for kernel debugging. If you need it, his fork is the way to go. Otherwise there is not much reason to use it. I may integrate support for kernel debugging at some point of time in the future but as most users don't need it, it's a low priority feature for me.
    1 point
  18. GeForce 210 works AGAIN! Thanks to @ASentientBot
    1 point
  19. Thank you. You are made a good observation btw. Especially when the boot process takes longer, white flashes happening. Hope someday someone can find a solution for that.
    1 point
  20. MacOS does not support natively the keyboard backlight for non-Apple hardware. I wrote an open source Kext project (ClevoService) to perform this task on Clevo laptops. It's fully working on my Clevo P9XXEN_EF_ED laptop with Mojave (18G95) and it should works on many other Clevo laptops. If you own a Clevo laptop with full color backlight keyboard, take a look at: https://github.com/FreeJHack/ClevoService The big advantage is that the backlight function is fully controlled from the numeric keypad and it's saved between boot/reboot and sleep/wake. You can change color, backlight level and ON/OFF. For the installation, download the kext from release page and follow the instruction given in the GitHub repository.
    1 point
  21. 2) Q: Is it legal? A: Installing a legally purchased copy of OSX on your own hardware is not illegal. It is possible for it to be considered a breach of the EULA, which is a personal contract between YOU and Apple. So while not a criminal offense, you are responsible for your own actions. This is my opinion based on my experience and understanding, but am not a lawyer, and my views don't necessarily reflect those of InsanelyMac or the owners of this website.
    1 point
×
×
  • Create New...