Jump to content



Member Since 27 Mar 2012
Offline Last Active Yesterday, 11:42 PM

#2192841 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on Yesterday, 11:27 PM

HI Mieze, there is any prevision of availability regards i219 support by the way of your driver? I'm sniffing around Z170 motherboards and I'm wondering what would be the best choice regards the LAN support... thank you!  :)Well, I updated the Realtek driver and published an update for the Atheros driver this weekend. IntelMausiEthernet will be the next to update but taking all the problems into account that the Intel NICs have, I'd recommend to get a mainboard with an Atheros Killer NIC as these chips are known to work perfectly under OS X with my driver. Mieze

#2192549 Solution for Qualcomm Atheros AR816x, AR817x and Killer E220x

Posted by Mieze on 28 November 2015 - 09:18 PM

Last night I couldn't sleep so that I decided to get up again and wrote some lines of code. This is the result, version 2.1.0d0 of the driver, which adds:Support for Killer E2400.EEE support.On my test system it works fine, although I must confess that a few hours of testing is not enough, but see for yourself... EDIT: I forgot to add the Killer E2400's device id to the Info.plist file in version 2.1.0d0 but corrected that error in version 2.1.0d1 which you'll find attached to this post now. Good luck testing! Mieze Attached Files  AtherosE2200Ethernet-V2.1.0d1.zip 822.64KB 4 downloads

#2191208 No graphics / USB / Audio after wake

Posted by Mieze on 23 November 2015 - 06:53 PM

Just in case someone is still looking for a method to disable certain hardware components of the chipset completely, here is the solution I found. You can use register FD Function Disable found at memory address 0x3418 of the 6/7/8/9 chipsets to disable a device so that it won't be recognized by OS X anymore as the bits disable the device's PCI config space. I used these lines of code to disable EHCI 1 & 2. First you might need to define the corresponding bits of the register in Field RCRB, in my case I added EH1D and EH2D. Caution! Double check what you are doing. Disabling the wrong device might render you system unable to boot OS X. OperationRegion (RCRB, SystemMemory, SRCB, 0x4000) Field (RCRB, DWordAcc, Lock, Preserve) { Offset (0x1000), Offset (0x2330), AFEA, 32, AFED, 32, AFES, 16, AFER, 16, Offset (0x3000), Offse...

#2190769 No graphics / USB / Audio after wake

Posted by Mieze on 22 November 2015 - 02:16 PM

 What is the role of this other device?Device (SLPB) { Name (_HID, EisaId ("PNP0C0E")) Name (_STA, 0x0B) }It's the Sleep Button. Please see section of the ACPI 5.0 specification for a detailed description. You can download a copy using this link: http://www.acpi.info.../ACPIspec50.pdf Mieze

#2190722 No graphics / USB / Audio after wake

Posted by Mieze on 22 November 2015 - 11:14 AM

 What is the role of AppleMCCSControl kext? It is loaded and it has dependency on SMC in ElCapitan unlike Yosemite.I think it is for backlight control because it binds to device PNLF: Bildschirmfoto 2015-11-22 um 12.09.44.png 17.44KB 5 downloads Device (PNLF) { Name (_ADR, 0x00) // _ADR: Address Name (_HID, EisaId ("APP0002")) // _HID: Hardware ID Name (_CID, "backlight") // _CID: Compatible ID Name (_UID, 0x0A) // _UID: Unique ID Name (_STA, 0x0B) // _STA: Status Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x04) { "refnum", 0x00, "type", 0x49324300 }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } }Adding these lines of...

#2190634 No graphics / USB / Audio after wake

Posted by Mieze on 22 November 2015 - 12:26 AM

 I’m starting to suspect that actually IGPU doesn’t have much with this problem.  I check both situation, with enabled IGPU in the BIOS and disabled variation, also with implemented DSDT patch and without them, and the last one where IGPU is completely disabled from the system tree, but the result is always the same. I also switch AppleGraphicsControl.kext & AppleGraphicsPowerManagement.kext with the one from the OS X 10.10.5, just because I suspect in importance of those in this matter. And yes, the GPU is working that way, but the wake result is the same.  Which brings me to the conclusion that the core of the problem is actually in the AMDRadeonX4000 & AMDRadeonX3000 kexts. We all know that the Apple has made some changes, but I think that the crucial one is the elimination of the sensor-properties lines under the both mentioned kexts. Wake is working only when both IGPU and GPU are enabled, but of course where IGPU is set in the BIOS as firs...

#2190364 No graphics / USB / Audio after wake

Posted by Mieze on 21 November 2015 - 11:46 AM

I have another approach to find out what exactly the dependency is. The MacPro6,1 is equipped with a Radeon D300, which is basically a Radeon R9 270X according to its device ID. Unlike the iMac, it doesn't have Intel graphics but instead you can find device GCON and its driver AppleMGPUPowerControl.kext, which is in turn a plugin of AppleGraphicsControl.kext. Compared in size and complexity with the Intel graphics drivers, this driver is tightly structured and it seems to take the Intel driver's part when it comes to wakeup on these machines. If we can figure out how it helps the AMD driver to wake up, then we know what the Intel driver has to do on other machines with IGPU. Mieze 

#2190054 No graphics / USB / Audio after wake

Posted by Mieze on 20 November 2015 - 12:54 PM

One more thing: If the IGPU is enabled this also means that it claims VGA memory and I/O cycles. As a result of that any attempt to access the AMD GPU using these methods will fail. I don't know if the driver still uses the legacy registers, but it would be an explanation. In my old dump I see lspci output says that @0x50==0x03. Already done? And this old report contains only Radeon graphics.New dump50: 11 02 00 00 GMCH Graphics Control Register set to 0x3 means that the register is locked, IGPU VGA access is disabled and that there is no memory preallocated for the IGPU. Mieze

#2189365 No graphics / USB / Audio after wake

Posted by Mieze on 17 November 2015 - 11:13 PM

Although I haven't found a solution for the wakeup issue yet, at least I made some progress with AppleGraphicsDeviceControll. In order to make it work you have to patch AMD7000Controller.kext's Info.plist and change 'CFG_USE_AGDC' from false to true.<key>aty_config</key><dict> <key>CFG_USE_AGDC</key> <true/>Unfortunately this doesn't solve the wakeup problem, but at lest it prevents the framebuffer from reenumerating all attached displays when the screen goes online again. I also observed that the primary display always gets the "AAPL,boot-display" property, on real Macs with IPGU and/or discrete GPU. This is also true for an hackintosh with onboard graphics but on an hackintosh with an AMD GPU as the primary display this property is missing, no matter what you selected in BIOS setup. You might think that this is just a cosmetic issue but I think it's not. Searching through the source code of IOGraphics.kext that Apple publi...

#2189341 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 17 November 2015 - 09:52 PM

Looks like you are posting in the wrong forum as it seems to be a Clover related problem, not a driver issue. Mieze

#2188239 New Driver for Realtek RTL8111

Posted by Mieze on 14 November 2015 - 10:58 AM

Ok, next try. After comparing Realtek's latest source code with version 8.037.000, which has been the base for my driver during the last 2 years,  I modified the receiver configuration for some family members because this was one of the most important changes they made. Good luck! Mieze  Attached Files  RealtekRTL8111-V2.1.0d1.zip 3.54MB 68 downloads

#2188145 New Driver for Realtek RTL8111

Posted by Mieze on 13 November 2015 - 11:09 PM

Hmm, As I'm quite sure that packets are going out (the statistics are based on hardware packet counters), the problem might be located in the receiver's configuration. I will check the source code again. Maybe I'll find something... Mieze

#2187870 New Driver for Realtek RTL8111

Posted by Mieze on 12 November 2015 - 11:02 PM

Here is a first development release of version 2.1.0 of the driver which adds support for the RTL8111EP and the RTL8111H. I'm publishing it for testing purposes only as it's still far away from a final release. Good luck! Mieze EDIT: Please use version 2.1.0d1 instead of this one!

#2187410 New Driver for Realtek RTL8111

Posted by Mieze on 11 November 2015 - 12:12 AM

I just wanted to let you know that I started work on version 2.1.0 which is based on Realtek's driver source 8.040.000 and will add support for the latest members of the RTL8111 family including the RTL8111H. Mieze

#2186155 New Driver for Realtek RTL8111

Posted by Mieze on 07 November 2015 - 12:28 AM

Currently the driver lacks support for the RTL8111H. I will update it as soon as possible to add support for this chip found on recent boards. Mieze

© 2015 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy