Jump to content

Mieze

Mieze

Member Since 27 Mar 2012
Offline Last Active Yesterday, 05:47 PM
*****

#2324580 No graphics / USB / Audio after wake

Posted by Mieze on 25 November 2016 - 06:15 PM

EDIT: One last thing, did anyone ever investigate the order in which all drivers/devices are woken up? Is this deterministic? Would be interesting to know if there's a different order on working setups (e.g. iGPU=Primary or genuine Mac) and non-working setups (Hackintosh with dGPU=Primary).Three things I'd like to mention:Of course it's deterministic and, for logical reasons, the order is dictated by the device hierarchy. Searching for a solution with the AMD GPU as primary is futile because Apple designed it as a master-slave-architecture with the IGPU as master and the AMD GPU as slave, even in the 2013 MacPro where device GCON takes the role of the master. Wakeup with UEFI Video Op ROM probably doesn't work because of the UEFI driver interfering with OS X's driver as the UEFI driver gets called during wakeup. With Legacy Video OP ROM there is no such thing like wakeup support by the BIOS so that the AMD GPU is under full control of OS X's driver during sleep/wake cycles. You migh...
  • Bor likes this

#2321886 New Driver for Realtek RTL8111

Posted by Mieze on 19 November 2016 - 04:15 PM

hallo frau mieze, perhaps the new driver from http://www.realtek.com.tw/ would fix some problems in recent posts? :) your latest version works perfectly on 10.12.1, but maybe some other people need it. ciaoI'm aware of the new linux driver, I checked the code and came to the conclusion that there is nothing in it which would be a benefit for OS X. By the way, the error some users are reporting is a BIOS issue affecting only machines from Acer and Dell and in no way limited to a specific NIC. Atheros NIC's are affcetd too. The problem is that OS X fails to map the NIC's register space into kernel address space and there is nothing I can do about it.baseMap = provider->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0, kIOMapInhibitCache); if (!baseMap) { IOLog("Ethernet [AtherosE2200]: region #0 not an MMIO resource, aborting.\n"); goto done; }Mieze

#2319291 New Driver for Realtek RTL8111

Posted by Mieze on 15 November 2016 - 03:25 AM

Thank you Mieze, I double check the BIOS, again. Networking Boot is Disable and Wake on Lan also disable, :(I just saw that my Boot Priority order has two options, the last two in fact: Networking Boot IPV4 and Networking Boot IPV6, but i can not delete them. Well, thank you!I really appreciated your help,Rednaz :)Check the BIOS settings again for hidden entries affecting the NIC. Don't give up until you have check each and every entry. Unlike traditional board manufacturers, desktop and notebook vendors sometimes do strange things in their BIOS. Good luck! Mieze

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

Posted by Mieze on 09 November 2016 - 08:21 PM

@Zelda_limk64: Still nothing! Pardon me for saying so but honestly I think that this is another case of PEBKAC.  :lol: Mieze

#2299612 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 14 October 2016 - 04:57 PM

Thus I wonder whether the LAN driver AppleIntelE1000e.kext might be the culprit?  To be clear, booting is fine, OSX 10.10.5 works but from time to time it gets very laggy for no apparent reason.Honestly, I don't understand how you relate the problems to IntelMausiEthernet.kext anyway? Mieze

#2295514 New Driver for Realtek RTL8111

Posted by Mieze on 08 October 2016 - 07:16 AM

You need a PCIe card because PCI cards are unable to perform DMA operations with 64bit addresses and yes, PCIe cards would be affected of the same issue too. Mieze

#2283135 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 23 September 2016 - 09:42 AM

I decided to make version 2.2.0d4 the official version 2.2.0 and updated the prebuilt binary in the download section. As always, source code can be found on GitHub. Have fun! Mieze  :cat:

#2282817 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 22 September 2016 - 07:03 PM

I'm a little out of the loop, just installed version 2.2.0d4 on Sierra. How/where do I find the driver output? There seems to be absolutely no output in any of the Console views.I knew this question would be posted here one day because Apple reworked logging in Sierra completely. In Terminal typelog show --predicate "processID == 0" --debugin order to retrieve kernel logs. See "man log" for further information. Mieze

#2280490 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 19 September 2016 - 10:56 PM

I was asked to explain what I changed in the last version in order to make the driver work stable during large transfers. Well, after reviewing the code and checking the docs again and running several tests together with crashmaster4000, I identified 3 problems which I have fixed in the last version:There was a DMA latency issue which was easy to fix after I found the matching system call requireMaxBussStall() to tell the OS about the NIC’s latency requirement. A hardware bug with regard to descriptor management. Descriptors are small memory blocks, in this case 16 bytes in size, used to communicate commands and data to the the NIC. They are arranged in a ring from where the NIC fetches them and stores them in an internal buffer. After they have been processed, they are marked as consumed and written back. With descriptor prefetch enabled the NIC sometimes reads more descriptors from the ring than there is space in the internal buffer so that unfinished descriptors will be over...

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

Posted by Mieze on 19 September 2016 - 12:33 AM

By the way, I added support for upcoming Killer E2500 chips to the driver and made this version the official version 2.2.0. The prebuilt binaries have been updated too. Have fun!  :cat: Mieze

#2278501 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 14 September 2016 - 09:55 PM

Ok, next try! Here is version 2.2.0d4. Good luck testing! Mieze  Attached Files  IntelMausiEthernet-V2.2.0d4.zip 72.6KB 104 downloads

#2271381 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 30 August 2016 - 12:11 AM

Ok, next try! Here is version 2.2.0d3. As it's already 2 o'clock in the morning there is no time for extensive explanations but the only thing I changed is the maximum tolerated DMA latency the the driver is reporting to the kernel (now 50µs instead of 75µs in 2.2.0d2). Good luck! Mieze  Attached Files  IntelMausiEthernet-V2.2.0d3.zip 72.81KB 43 downloads

#2270263 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 26 August 2016 - 11:02 PM

Here is another development version of the driver (2.2.0d2) in which I implemented support for RXPOLL. Hopefully it might also resolve the randomly occurring tx deadlocks which some users are still experiencing. Source code can be found on GitHub. Good luck testing! Mieze Removed. Use version 2.2.0d3 instead (see below)!

#2263558 IntelMausiEthernet.kext for Intel onboard LAN

Posted by Mieze on 09 August 2016 - 01:41 PM

I just installed the latest developer preview of Sierra on my test machine, also installed the release build of IntelMausiEthernet.kext and rebooted. As expected, everything is working fine!  Screen Shot 2016-08-09 at 15.33.11.png 355.66KB 8 downloads Mieze

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

Posted by Mieze on 07 August 2016 - 11:57 PM

I only have TXSTART and not RXPOLL when I look at ifconfig -v because rxPolling is set to false inside the Info.plist. Is this feature not ready yet? AFAIK RXPOLL works but I neither tested it thoroughly nor was there a need to enable it. That's the reason why I left it disabled. I guess apple did not include the changes in the SDK because the ABI is not stable, yet. I don't know from which version you pulled the headers but I just  downloaded the newest one (10.11.6) and did a diff. And indeed inside the IONetworkInterface.h they added a variable in the middle of the ExpansionData struct. If you use a variable from that struct that comes after the addition your driver will break with subtle bugs. Fortunately this is a private struct and only used internally. But I think we should check the new releases for breaking changes when using a private API.No, it doesn't break because these variables are private variables of the base class. The driver is unable to access them...

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