Jump to content


  • Content count

  • Joined

  • Last visited

About Gen_

  • Rank
    InsanelyMac Protégé

Recent Profile Visitors

1,847 profile views
  1. Gen_

    Is OSX86 doomed?

    Also, I might add this interesting facet. If Apple did transition completely to ARM, that could likely be fantastic news. All the existing x86 code now has no value to them so likely won't be compiled for x86 at any point in their chain post EOL, updates clearly won't work for existing models and hacks without recompilation to x86, and recompiling software to another arch would be a great test case for the 'making parts for existing but out of production goods' protections in copyright law that China loves so much. Essentially it would be like handing over the source of OS X to hackintosh devs, and the existing Macs would eventually rely on the community for updates. What's the best developed, community and OS centric dev space right now on Mac: Hackintoshers We're the Apple equivalent of the Android OS dev forums.
  2. Gen_

    VGA on Hackintosh

    Let's just clear this up because it appears this thread hasn't been seen to by the people that made the whole 'VGA is unsupported' statement all that time ago: It was T who shall not be named. Considering the fact that they are quite reliant on ad revenue from actual hardware manufacturers (what do you think Customac guides was charity?), removing VGA as an option essentially ensures that you do not have to support anyone who hasn't got a new screen.... chances are they don't have a new computer either. Cue Custo-recommendation. VGA WORKS on most setups, sometimes you need to add an NVCAP value that includes an analog output to the plist in order to get it to work. Doesn't seem to matter that NVCAP is for Nvidia cards. What it doesn't seem to work with is multiple displays, VGA+Digital and VGA+VGA. Unsupported GPUs I have personally got VGA working with on HS: HD530, HD4400, GTX970, GTX560Ti, GTX550Ti, GT240, HD6670, HD6450 (XFX, which is bad for Hacks and needed DSDT edits). The vast majority work first time, but immediately black out on boot if a digital display is connected simultaneously. I believe this is DSDT fixable and relates to connector values, but as already mentioned because there are no VGA macs, we would need ReactOS levels of reverse engineering to do it in any other way than trial and error.
  3. Gen_

    Is OSX86 doomed?

    In a word: No. Apple will never move Pro range from x86. They may move MacBook one day but Adobe are not going to move Creative Suite to ARM and simply put it sells too many Macs. Intel also have the capability to blow away ARM offerings should they need to. Apple moving to ARM would be too symbolic to the rest of the world of the end of desktop computing on x86. Intel bringing AMD Vega iGPUs should show already how much Intel is willing to bend over backward to make sure that their main customer sticks with them, but Intel has stalled the PC industry with it's lack of performance gains since Sandy Bridge.
  4. Gen_

    Changing default VESA modes on graphics card.

    Use clover configurator to alter your config plist's theme resolution. Remember that the actual images will not be stretched by clover so you will likely still have issues due to nobody making ultrawidescreen themes built into Clover. You'll probably be able to google a useable one though. Also remember that your native resolution is probably quite a bit larger than the maximum resolution supported by both your theme and the VESA standard implemented into MacOS (which is ultimately used in Clover, and also hasn't been touched since 10.6 latest for lack of need). You will need to pick a lower resolution at the same aspect ratio to fill your display border to border.
  5. Without being rude, I think you have too much green in your goggles. You should be aware that there isn't any HDD or SSD outside a vacuum sealed magnetically shielded military/interstellar hard drive that is immune to bit rot. ECC checks for errors on the way in or out to see if it was damaged in TRANSIT, but does nothing to check that what it read in the first place is correct, so even the metadata needs a software fix. ECC has existed on all SSDs and HDDs since at least 2001, hasn't changed or improved (it's a static definition) and is pretty irrelevant to filesystem rot. It's main purpose is making sure that any 1 or 0 travelling down the SATA cable isn't disrupted by electromagnetic interference and flipped... put another way it counters people wrecking your data by putting the cable next to magnets. The type of error correction ZFS (for your data) and APFS deals with (for metadata) is that which happens to data sitting on-disk as a result of quantum effects and other unavoidable errors that happen to everyone more and more often the denser and smaller we make our storage bits and bytes. This is the fundamental reason why ZFS as a filesystem takes 1/3rd of your HDD for checksumming, and Google says it's the reason for well over 60% of freezes and app crashes. APFS protects your filesystem, basically stopping hard resets from damaging filesystem metadata, which is the data that stores 'where your files are', but does not protect the actual content of your data. And to quote Pike in the comments "Listen. APFS is a great filesystem, but there is still work to be done. The fact that Apple didn’t open it up, so that third party tools could be developed, is one of the reasons that I pass. Note that Apple won’t even let you read the S.M.A.R.T data from their flash storage. Why is that? I mean. If you don’t have anything to hide… but wait. The data that I have read out from brand new hardware showed me that Apple hardware is not without failures. And since there’s no checksumming for user data. Just meta data. Another reason for me to pass. In the end. If I lose (some of) my data. Like pictures and what not. Then than is my problem. I can’t bring them back. No third party tools can even give it a try to restore my data. What about Apple? Just read the fine print…"
  6. I'm on the bus with you Arkanis (GA-X79-UP4)! I'm sure we don't have many options until we understand High Sierra a bit more but I'd steer clear from downgrading AHCI drivers to get it running. Are you running a modified DSDT btw? If not then you might find most of your issues fixed there with patches. The main difference between High Sierra and (Low?) Sierra is the APFS and I don't like to think of the consequences of the drivers missing certain steps when taking care of your data because they were rolled back to a pre-APFS using driver, but I'd no idea of the really awesome method you showed and will try an offline install to a blank SSD tonight. It's very convenient to be able to install the OS from terminal.
  7. You've probably worked it out already but that really deserves it's own thread as it's based around a different system and may confuse people looking for solutions to the gigabyte board. For the record. 1. Applies to all boards. You need a new SSDT with the new clocks applied. Use the SSDTPRGen script from Pike R Alpha. Your BIOS settings are basically ignored because Clover is acting as your BIOS like VMWare would be to a VM, and it reads your CPU data from the SSDT file as your BIOS would. It does not however apply overclocks on most machines. NullCPUPM literally stands for Nullify CPU Power Management, so I recommend you don't ever try overclocking whilst using it. Get Clover Configurator and you can set the CPU Clock there that will be shown in "About my Mac". Bear in mind OS X cannot run on any processor at over 4.7 Ghz... software limitation. 2. Google the chipset. 3. Almost certainly not. Google the device IDs. If they share the same one then 99.9% no as they are a combo chip and Apple don't use them or support the concept. Do not install VoodooHDA, use AppleALC892 assuming you have a ga-up4. Do not use the machine until it's finished indexing after first install, and make sure you NEVER shutdown via the power button. You seem to be experiencing things that point to a dodgy hard drive so if you have the time do a secure erase on your next install and make sure there's no bad blocks fudging things up.
  8. 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.
  9. Not much in OSX86 will kill your parts instantly but there are things here that will over time. Also please get Clover Configurator and use the GUI, it's much easier and I see all these people stumbling over editing their config.plist in text edit... painful. FakePCIID.kext, FakePCIID_XHCIMux.kext and USBinjectAll.kext altogether with no DSDT edits will damage the devices you plug into your ports if they do large transfers because together they mangle the data sent. You need to create a DSDT patch listing the amount of devices on the buses and ports and get rid of USBInjectAll. This is not my recommendation, it's on the download page of the kexts. Everyone having issues with kernel panics caused by AppleIntelCPUPM need to read this: http://www.insanelymac.com/forum/topic/312859-sandy-bridge-e-ivy-bridge-e-power-management-1012-beta/ and create an SSDT for their CPU model and stock/turbo clocks. After that, you will need to enable DTGP patch and HPET patch, then AICPUPM patch in clover. And you DO need to do a lot of the things that seem optional here, because this is not an easy mode board. Take it from me who has run this since 10.7, RMA'd twice over damage and even bought another up4 two years ago. Using VoodooTSCSync/NullCPUPM without a working SSDT over time damages your processor and you will get a CPU self-check failure after a while stopping you from booting any OS because it's a hacky solution.
  10. Apple will not go into ARM chips with macOS unless it's still planning iOS convergence: thy have forked a lot of ARM code when they spun off iOS and rewriting that code for more functionality is inefficient compared to just glossing over those features with simpler application "updates". Apple also won't go into ARM chips because it would take them a sizeable chunk of their bank to catch up with Intel on performance. Worse still is the fact that all the stuff Intel did recently is definitely still under patent so every single modern method in the chip must be reinvented. (This is why it took AMD so long to catch up with Ryzen; if you take too long to get to the patent office, you have to think of a new way to do exactly the same thing, often a less efficient way just to avoid the patent)
  11. Gen_

    USB Sound Card and VoodooHDA have same problems

    Okay, first you need to actually ascertain if it is indeed something that needs a DSDT fix and if then, what fix does it need. Does the crackle happen more of then at any particular time? Maybe it happens more when the mouse moves (IRQ clash with GPU), or when the system is under load, or when the HDD is being used heavily (Kext issue with IOPCI I think).
  12. Interestingly enough I have been using exFAT on two other 1TB hard drives hooked up to my Mac mini for the better part of 2 years with no problems. I'll switch one to NTFS and just use it read-only if need be... I'd rather it be accessible in some capacity on both sides than use HFS+ Thanks for the heads up about the drive. Carried out the instructions under that link anyway, park head was still set to sleep every 8s... despite the drive having come out two years after that article. Worse than that I've had the drive no longer than a month and I have 17 bad sectors and counting, SMART says the drive is failing... and it took me a week to move all my important stuff spanning several drives to it. Doesn't really tell me why my SSD corrupted but I guess I'll have to cross that bridge when I get to it. Ah well, thanks for the help either way RD.
  13. Bang on the money, it's a WD Caviar Green 3TB Shutdown works fine, even faster than on my Windows partition, although occasionally I get the terminal style text over the grey shutting down screen for a few seconds, I chalk that up to the fact that I usually have 6 devices on the SATA of this machine. I just know it's a shutdown problem because it's not happening consistently on every startup of OSX. (Which has actually meant I've used Windows unless I've absolutely HAD to this week). Whenever I startup now, the exFAT partition fails to mount and refuses to repair. So did the Time Machine partition even after I formatted it (it doesn't now as I have stopped running backups on it full stop and it never gets written to). I can fix the partition by running Testdisk and restoring the superblock from Backup, but that means the main partition boot block for the exFAT drive is consistently getting corrupted every startup. I've checked and nothing else on the drive is damaged, all changes I've made whilst running OSX before the shutdown are unaffected etc. So how does one go about fixing the firmware, is there an update that will fix compatibility? I've even gone as far as trying to learn some unix shellscript to unmount the drives and eject them before OS X starts shutdown procedures. EDIT: Thanks for the heads up. Is this the issue and fix for what you were talking about? http://news.softpedia.com/news/WD-Caviar-Green-HDDs-Suffer-From-a-Critical-Design-Flaw-196159.shtml
  14. Gen_

    nvidia drivers

    My general policy and probably that of my peers here is 'if it ain't broke, don't fix it'. Technically though, it shouldn't mess up anything. Open it up with Pacifist and check what kexts it installs, then backup any particular kexts it will overwrite first. If something bad happens, boot up in safe mode, replace the kexts with the old ones and delete any extra new kexts.