Jump to content

Gen_

Members
  • Content count

    27
  • Joined

  • Last visited

About Gen_

  • Rank
    InsanelyMac Protégé

Recent Profile Visitors

1,969 profile views
  1. Gen_

    80 Core Hackintosh :)

    You don't want a max count that isn't base 2, simply because reasons like the original being base 2 and the possibility that code reliant on it may have recursive functions (which could expect that number to be divisible by 2 down to 1 and make the function faster by limiting code width - not because Apple plan a 64 core Mac) so I would recommend 127 + 0 core or 7F. Remember that having higher than the max cores you physically have available is standard behavior for everyone else because we don't patch this kernel value, even through voodooTSCsync. Also think that there may be 'dummy' or virtual cores used by the kernel that we don't see, as there isn't a precisely 64 core build I've heard of (only a 32 and 40). There might have been a typo in why the 8f figure was used, or said poster has deeper knowledge and MacOS uses lots of fake cores for other stuff like uncore on-die DSP. Finally, a word to anyone else that is patching this in case it doesn't work alone: 64 is the highest representation of a binary word and the patch may overflow other kernel elements because it turns the port count into dword element in binary. Follow the pointers and make sure they can use asm dword elements or recompile from source with the limit changes and the compiler should take care of it.
  2. Gen_

    Frustrating GPU error detected

    Not from just that. At least post the PDFExpert window and your spec so we can see where you are experiencing this issue. Channel timeouts are actually an oft reported sign of version mismatches too so it could be the app version relative to the Os version. CT is a failure to receive data for processing from the OS, and the log you see there is the GPU restarting so it's quite a poor explanation on it's own. Try old freezefix, which keeps some GPUs from generating this by themselves on idle.
  3. Two things you need to consider. 1 is if you were using a GPT formatting and you lost the first partition, this will happen. Windows and Mac both assume the first partition to be EFI/ESP so they will write protect it. If it disappears in a way that splats the drive, and the repair process 'fixes' the pointer to the first drive, they can assume the next partition (your data probably) is the ESP. Try booting in OSX, verifying that your drive is present in Disk Utility (but not mounted), then close DU, open terminal and type "sudo dd if=/dev/zero of=/dev/hdX bs=512 count=1" replacing hdX with the number that is your drive. You can use "diskutil list" to find that out. PLEASE BE CAUTIOUS. It will start with block 0 on any drive you point it at, meaning basically it will have killed your access to the data on the drive in the first second of wiping (block 0 will point to the partition record, so no partitions). Please make sure that you picked the right drive. This is as close to a factory format as a PC will let you go. Essentially it's zeroing the drive, including the boot blocks.
  4. @MaLd0n In ref to the page 1 guide. I think if this iGPU is like mine, he's more likely to get QE/CI with InjectIntel disabled and correct ID and ig platform. My HD520 (which is almost identical to setup according to guides) doesn't get full acceleration with inject enabled unless I set 001 or 002-ending device id's; disabling port 1. I think the DSDT patch doesn't strip existing iGPU code so the injected code is (I think) duplicated to the root PCI-e controller (like where you'd add dummy Radeon code for MP6,1 SMBIOS). Not calling you out, just wanna be sure your guide is platform specific (for his board) and not an accident.
  5. Gen_

    Is OSX86 doomed?

    Depends on how you look at it. I was saying the same thing first then I realised something. The last time this happened was PPC. This was because no matter how much (water) cooling and grunt they stuck in a Powermac it just couldn't keep up with new Intel chips. Jobs was as vocal about his dislike of PPCs progress as he was of Flash, but hopeful as the tech plateaued and they moved on. Intel are going through the same thing. tl;dr they are being very reactionary and scared because x86 won't get much faster for a long time. Spectre/Meltdown hardware fixes still mean having to replace technology, initially with worse (much worse judging by how far back it reaches) tech. This is the last in a long line of publicly visible problems within their org, all alongside Apple doing their own ARM for a long time now. Plenty more things to point out if need be: tl;dr SkyX practically forced an entire product range out of Apple. Apple didn't like being forced to do anything. ARM will eat x86 alive on desktop because Apple can have them fabricated on desktop TDP processes, even if it takes them building fabrication themselves... they could also go to AMD for this as AMD has Opteron ARM A1100 server cores already.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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…"
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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)
×