Jump to content
Mieze

New Driver for Realtek RTL8111

1,333 posts in this topic

Recommended Posts

Windows driver: Realtek, 10.6.2011., 7.46.610.2011. I think it's installed from mobo CD, but I do not know if it's updated from Windows Update.

 

Linux: there are two drivers:

- r8169 which is part of Linux - Windows -> reboot into Linux (net works) -> reboot into OSX (net works)

- r8168 from Realtek - Windows -> reboot into Linux (net works) -> reboot into OSX (net does not work)

 

Thanks for still thinking about this. If you think that some registers dumps at some point will help, just tell. I can do them from Linux and OSX driver.

Share this post


Link to post
Share on other sites
Advertisement

Windows driver: Realtek, 10.6.2011., 7.46.610.2011. I think it's installed from mobo CD, but I do not know if it's updated from Windows Update.

 

Realtek released new Windows drivers during the last days. Maybe you should try them to see if they resolve the problem as I assume that they use a similar setup/firmware as the Linux drivers?

 

http://www.realtek.c...3&GetDown=false

 

Thanks for still thinking about this. If you think that some registers dumps at some point will help, just tell. I can do them from Linux and OSX driver.

 

We've found a lot of facts but what we need most now is a new theory how to reconcile them. As far as I know only chipset 14 is affected of the problem so that it might be the best approach to check the initialization steps that are specific to this chip. As soon as I have an idea I'll let you know.

 

Mieze

Share this post


Link to post
Share on other sites

Hi Mieze,

Thank you so much for this dev work. Using lnx2mac which had a very slow dev cycle, i was having problems with extended high traffic use of the nic one one of my systems. It would just die until a reboot. I would also have to inactivate and reactivate if i unplugged and replugged the cable. Both these issues seem solved by your driver, and i am also getting a good %10 more bandwidth it seems. I have not tried the Slice driver yet but i am happy with yours. Maybe you guys should join forces :)

 

Anyway, i do use windows occasionally and would lobe to see that issue resolved. I will test it on my system to see if i have the same issue. One request i have is, since you say that offload wont work with jumbo frame is if you can allow offload to disabled when jumbo frames are used or if thats not possible release a version with jumbo frame support (and no offload). That would be helpful as sometimes i use this feature on internal network setups.

Thanks!

g\

Share this post


Link to post
Share on other sites
Anyway, i do use windows occasionally and would lobe to see that issue resolved. I will test it on my system to see if i have the same issue. One request i have is, since you say that offload wont work with jumbo frame is if you can allow offload to disabled when jumbo frames are used or if thats not possible release a version with jumbo frame support (and no offload). That would be helpful as sometimes i use this feature on internal network setups.

 

As far as I know only chipset 14 is affected by the problem while the 8111E-VL (Chipset 16) and 8111F (Chipset 17) found on recent mainboards seem to work fine.

 

On the receiver side the driver should tolerate jumbo frames as long as they fit into a single buffer. Eventually you'll have to increase kRxBufferPktSize (current value 2000) to cope with your setup.

 

On the transmitter side it makes no sense to use jumbo frames as every devices works well with standard frames and disabling the offload features will result in a significant performance impact even on fast systems.

 

Mieze

Share this post


Link to post
Share on other sites

Limitations

  • Support for the Realtek RTL8111B/8168B is still experimental and might not work at all. Therefore it is only included in debug builds and has never been tested successfully because I don't have access to a board with one of these outdated chips.

Known Issues

  • The code for RTL8111B/8168B NICs is untested and will probably not work as expected.

 

Hoping I can help out with that. I've got an old EP35-DS3 w/ 8111B that I don't really value for anything but testing.

 

I installed the debug version of your driver and it works mostly fine with the massive exception of TCP. There's also a lot of spam in the system log from a timer loop.

 

I've attached my system.log and netstat -s output. Let me know what else I can do to help test.

 

netstat.txt

system.log.txt

Share this post


Link to post
Share on other sites

I installed the debug version of your driver and it works mostly fine with the massive exception of TCP. There's also a lot of spam in the system log from a timer loop.

 

Hello saltspork,

 

thank you very much for the debug data. In order to get rid of the timer log messages comment out the following two lines in timerActionRTL8111B(IOTimerEventSource *timer):

 

DebugLog("timerActionRTL8111B() ===>\n");

 

DebugLog("timerActionRTL8111B() <===\n");

 

As only TCP isn't working I guess that this is an issue with TCP segmentation offload. Please change this method

 

UInt32 RTL8111::getFeatures() const

{

return (kIONetworkFeatureMultiPages | kIONetworkFeatureHardwareVlan | kIONetworkFeatureTSOIPv4 /*| kIONetworkFeatureTSOIPv6*/);

}

 

into

 

UInt32 RTL8111::getFeatures() const

{

return (kIONetworkFeatureMultiPages | kIONetworkFeatureHardwareVlan);

}

 

to disable it. Good luck!

 

I'm currently preparing a new release and will include improved 8111B support if we can get it working with TCP.

 

Mieze

Share this post


Link to post
Share on other sites

Hi Mieze.

 

I've commented out all the bits above and while the debug messages are cleared up TCP still isn't working.

 

An updated system.log is attached although I doubt it will help much.

 

Thanks for your efforts in any case.

 

system.log.txt

Share this post


Link to post
Share on other sites

Hi Mieze.

 

I've commented out all the bits above and while the debug messages are cleared up TCP still isn't working.

 

An updated system.log is attached although I doubt it will help much.

 

Thanks for your efforts in any case.

 

system.log.txt

 

Hello saltspork!

 

Thanks for the log data. What makes me wonder is the fact that TCP packets seem to go out but there is nothing coming back as if they all ended up in a black hole. No bad packets, no errors. Can you please describe the way you tested TCP?

 

Mieze

Share this post


Link to post
Share on other sites

Thanks for the log data. What makes me wonder is the fact that TCP packets seem to go out but there is nothing coming back as if they all ended up in a black hole. No bad packets, no errors. Can you please describe the way you tested TCP?

 

At first I wasn't testing very scientifically but I've gone back and done things properly with Wireshark on both ends. First trying to SSH to a remote system, and then the same remote system trying to SSH to the Hackintosh.

 

I don't know enough about TCP to say anything for certain, but it appears that the driver spits out invalid TCP packets that aren't even worthy of acknowledgement from a remote system, literally.

 

I've attached pcap files from each end, nicely synchronised.

 

pcap.tar.gz

Share this post


Link to post
Share on other sites

Update Notification

 

I released version 1.0.1 (source and binary) which includes two important changes:

  • Improved behavior when rx checksum offload isn't working. When hardware checksum verification of received packets fails, the driver now considers the packet as unchecked and hands it over to the network stack letting it repeat the verification in software instead of marking the packet as bad.
  • The NIC's model name is added to IORegistry so that System Profiler will show it properly.

The download URL is still the same.

 

Mieze

Share this post


Link to post
Share on other sites

Realtek released new Windows drivers during the last days. Maybe you should try them to see if they resolve the problem as I assume that they use a similar setup/firmware as the Linux drivers?

Tried. No luck with new drivers.

 

Since I know that

r8169 from Linux leaves controller in a good condition and your driver works after it, while after

r8168 it does not, maybe comparing "shutdown" code would help? Can you give me the hint what routines to check?

Share this post


Link to post
Share on other sites

Tried. No luck with new drivers.

 

Since I know that

r8169 from Linux leaves controller in a good condition and your driver works after it, while after

r8168 it does not, maybe comparing "shutdown" code would help? Can you give me the hint what routines to check?

 

The drivers entry points are usually a good starting point:

 

static struct pci_driver rtl8169_pci_driver = {

.name = MODULENAME,

.id_table = rtl8169_pci_tbl,

.probe = rtl_init_one,

.remove = rtl_remove_one,

.shutdown = rtl_shutdown,

.driver.pm = RTL8169_PM_OPS,

};

 

 

static const struct net_device_ops rtl_netdev_ops = {

.ndo_open = rtl_open,

.ndo_stop = rtl8169_close,

.ndo_get_stats64 = rtl8169_get_stats64,

.ndo_start_xmit = rtl8169_start_xmit,

.ndo_tx_timeout = rtl8169_tx_timeout,

.ndo_validate_addr = eth_validate_addr,

.ndo_change_mtu = rtl8169_change_mtu,

.ndo_fix_features = rtl8169_fix_features,

.ndo_set_features = rtl8169_set_features,

.ndo_set_mac_address = rtl_set_mac_address,

.ndo_do_ioctl = rtl8169_ioctl,

.ndo_set_rx_mode = rtl_set_rx_mode,

#ifdef CONFIG_NET_POLL_CONTROLLER

.ndo_poll_controller = rtl8169_netpoll,

#endif

 

I assume that you are familiar with driver programming for Linux but in case you need an introduction "Linux Device Drivers" will help you. The 3rd edition is available as a PDF file for free. Personally I would start with the driver's remove or shutdown routines. If you have further questions, in particular with regard to the mapping between Linux and OS X routines, feel free to contact me again (PM or mail are also ok).

 

Good luck!

 

Mieze

Share this post


Link to post
Share on other sites

Hi there, thanks for your hard work !

I tried with 8105E but it don't work, if it's not too hard to do could you add the suport for 8105E please ^^ ? i only have one PCIe slot for my HD7770 so i can't add an working one :/

 

The original driver for the 8105E work but only in 10Mbps i can't get it working in 100Mbps mode , it connect but give me an false IP so nothing work ..

10Mbps is okay but i work with big files so it's a little annoying at times ..

here is my original post :

http://www.insanelym...ce-for-100mbps/

Share this post


Link to post
Share on other sites

Hi there, thanks for your hard work !

I tried with 8105E but it don't work, if it's not too hard to do could you add the suport for 8105E please ^^ ? i only have one PCIe slot for my HD7770 so i can't add an working one :/

 

The original driver for the 8105E work but only in 10Mbps i can't get it working in 100Mbps mode , it connect but give me an false IP so nothing work ..

10Mbps is okay but i work with big files so it's a little annoying at times ..

here is my original post :

http://www.insanelym...ce-for-100mbps/

Hello scellow,

 

unfortunately its not that easy just to add support for the 8105E and I'm very busy at the moment. My driver is based on the Realtek's r8168 linux driver for their gigabit NICs but they have a different linux driver for their FE devices. Basically we would have to create a completely new driver or try to merge both.

 

Maybe you should talk to Slice because he has already implemented basic support for the 8105E. Although the code isn't working for this chip and there is still a lot of work to be done, he has the the better starting point.

 

Mieze

Share this post


Link to post
Share on other sites

Hi Mieze,

 

Thanks for your reply :) , i guess this is hard to port even an app so i bet a driver is painfull :/

I asked Slice about a way to modify the actual official driver for the 8105E to correct the problem of the 100Mbps mode, maybe it'll be easier to do than to make an full port since we have something wich is partially ok

 

I found the datasheet for this model maybe it could help. Everything is on my original post here :http://www.insanelymac.com/forum/topic/287568-realtek-rtl8105e-only-10mbps-any-chance-for-100mbps/

 

Or maybe i just need to send an mail to Realtek for the 100Mbps issue ? If anyone have their mail adress just pm me :)

 

Thanks again to Insanelymac public, you are all awesome

Share this post


Link to post
Share on other sites

would anyone have any information on making this work on snow leopard? im running an asus p7p55d-e pro on 10.6.8, the 8111D's performance is awful on this board, i can never get above 50mb/sec (usually more around 30-35) while all my other devices can pull the same file off my server at close to maxing out the gigabit connection (the files in question are on a raid50, so its not a bottleneck on the server side)

using the driver as provided compiled does not see the NIC at all (as to be expected, it says 10.8 only)

i tried to build it using the xcode project in xcode 4.2 on my machine but it just throws a lot of errors, mostly about "use of undeclared identifier 'kChecksumTCPIPv6'" or 'kChecksumUDPIPv6'; did you mean 'kChecksumUDP'

im no coding expert so I dont really know what to do about these.

 

i'd very much love to get better networking performance out of my machine without having to resort to buying an additional NIC. whole point of building a hackintosh was having extra expansion slots over a mac pro. ive already gotten stung once with my original logic board choice (evga p55 ftw200) as there is no osx support at all and never will be for the marvell 88e8057 chipset.

any help would be appreciated to get this working. and before people suggest it, going to lion or mountain lion is *NOT* an option. i have multiple specific reasons for staying on snow leopard both technical and personal.

Share this post


Link to post
Share on other sites
i tried to build it using the xcode project in xcode 4.2 on my machine but it just throws a lot of errors, mostly about "use of undeclared identifier 'kChecksumTCPIPv6'" or 'kChecksumUDPIPv6'; did you mean 'kChecksumUDP'

im no coding expert so I dont really know what to do about these.

Try to update Xcode to 4.4.1 or newer and select "10.6" as "OS X Deployment Target". This should make the errors go away. At least on my machine there are no build errors with this configuration. If the driver isn't working as expected after a successful build please send me the debug messages from kernel.log, ifconfig -a and the netstat -s output. Please keep in mind that this driver is 64bit-only. In case your system is still running in 32bit-mode it won't work at all.

 

Good luck!

 

Mieze

Share this post


Link to post
Share on other sites

Try to update Xcode to 4.4.1 or newer and select "10.6" as "OS X Deployment Target". This should make the errors go away. At least on my machine there are no build errors with this configuration. If the driver isn't working as expected after a successful build please send me the debug messages from kernel.log, ifconfig -a and the netstat -s output. Please keep in mind that this driver is 64bit-only. In case your system is still running in 32bit-mode it won't work at all.

 

Using SDK 10.8 and target 10.6 will make it build, but it will not load on Snow Leopard. This is because the definition of IONetworkController has changed in both Lion and ML (with additional virtual member functions). As a result, it is necessary to build with SDK 10.6 where these items are not defined.

 

I have forked this code in an effort to provide one (64-bit) binary for ML, Lion, and SL, as we are considering using this in the ProBook Installer. My fork is located at: https://github.com/R...Realtek-Network. The README.md there provides details on installation (there are special considerations on SL), where to download, and some background on what's changed (my change log is a bit behind, but you can see the commits).

 

A side effect of me pushing the archive (which is a git repo) to github is that it retains Mieze's commit log to her own local repo. For me, merging future changes is a little tricky, in that I have a separate local copy of your repo and when you make an update, I overwrite that repo with the new contents of the archive you post, then I'm able to treat it as a normal git remote and do a git fetch/merge to merge in those changes. It would be easier if your repo was available on a public site such as github, but for now this works...

 

Initially, I tried to make the kext work building with any SDK and still targeting all three systems (ML, Lion, SL) and was able to get it to work, but only with some ugly hacks. These hacks are disabled right now, and I'm just building with SDK 10.6 (Note: current Xcode doesn't come with SDK 10.6, so you have to copy it from an older Xcode that does, and copy it into the appropriate place (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs). If you want to see the ugly hacks that enable it to work on the three OS X versions with any SDK, search the project for DISABLE_ALL_HACKS.

 

To get around the undefined symbols with 10.6 SDK:

//HACK: from 10.7 SDK headers...
#ifndef __MAC_10_7
enum {
kChecksumTCPIPv6 = 0x0020,
kChecksumUDPIPv6 = 0x0040,
};
#define kIOMessageDeviceSignaledWakeup iokit_common_msg(0x350)
#endif

 

And to set those bits only when running on SL (note check for running kernel):


IOReturn RTL8111::getChecksumSupport(UInt32 *checksumMask, UInt32 checksumFamily, bool isOutput)
{
IOReturn result = kIOReturnUnsupported;

if ((checksumFamily == kChecksumFamilyTCPIP) && checksumMask) {
if (isOutput) {
*checksumMask = (kChecksumTCP | kChecksumUDP | kChecksumIP);
if (GetKernelVersion() >= MakeKernelVersion(11, 0, 0))
*checksumMask |= (kChecksumTCPIPv6 | kChecksumUDPIPv6);
}
else
*checksumMask = (kChecksumTCP | kChecksumUDP | kChecksumIP);

result = kIOReturnSuccess;
}
return result;
}

 

Provided the following is in the header:

#include <Availability.h>

#define MakeKernelVersion(maj,min,rev) (maj<<16|min<<8|rev)
#include <libkern/version.h>
#define GetKernelVersion() MakeKernelVersion(version_major,version_minor,version_revision)

 

BTW, we were previously using lnx2mac's driver. And while it works on the ProBook 4530s, it does not on the ProBook 4540s (next generation). And a nice side effect of using your driver on the ProBook 4530s is that it shaves ~7-8 seconds off of the boot time compared with using lnx2mac (my Chameleon to Login time is down from 15 sec to 8). Thanks for that. There is the problem posted here elsewhere about the driver not working after a warm boot from Windows, but small price to pay for a driver that 1) has source, 2) works on the 4540s, 3) trims boot time by 7 seconds.

Share this post


Link to post
Share on other sites

Thanks for figuring out how to build the driver under 10.6 but using an outdated SDK in order to build a driver for Lion and Mountain Lion is definitely not a reasonable solution with regard to future changes in particular as networks drivers have been evolving in Lion and ML. But with the information you provided it becomes clear what is needed to make a version that can be build with any of the mentioned SDKs without using ugly hacks. As far as I can see most differences are related to the introduction of checksum offload under IPv6 with Lion so that only a handful of methods need an alternate implementation for Snow Leopard.

 

I hope that I will find some time to add the missing code next week.

 

Mieze

Share this post


Link to post
Share on other sites

Thanks for figuring out how to build the driver under 10.6 but using an outdated SDK in order to build a driver for Lion and Mountain Lion is definitely not a reasonable solution with regard to future changes in particular as networks drivers have been evolving in Lion and ML. But with the information you provided it becomes clear what is needed to make a version that can be build with any of the mentioned SDKs without using ugly hacks. As far as I can see most differences are related to the introduction of checksum offload under IPv6 with Lion so that only a handful of methods need an alternate implementation for Snow Leopard.

 

I hope that I will find some time to add the missing code next week.

 

Mieze

 

Good luck there. The problem stems from the games Apple is playing in the base classes IOEthernetController : IONetworkController

 

In the 10.7 and 10.8 IONetworkController they define additional virtual methods in IONetworkController (inherited into IOEthernetController and thus RTL8111):


virtual UInt32 getDebuggerLinkStatus(void);
virtual bool setDebuggerMode(bool active);

 

So, if you build against 10.8 headers (or 10.7), RTL8111's vtable imports them. Of course, they don't exist on SL, so the system cannot load the binary (there are no weak references in kernel/IOKit). Maybe you, being more experienced with IOKit drivers, know of some way around this fundamental problem.

 

And if you look at 10.8.3 sources, you will see even more funny business going on with the vtable of IONetworkController... I'm really not sure what Apple is up to and what the strategy for backward compatibilty (building w/ old headers running on new system)/forward compatibility (building w/ new headers running on old system). The whole system looks pretty fragile to me.

Share this post


Link to post
Share on other sites

So, if you build against 10.8 headers (or 10.7), RTL8111's vtable imports them. Of course, they don't exist on SL, so the system cannot load the binary (there are no weak references in kernel/IOKit). Maybe you, being more experienced with IOKit drivers, know of some way around this fundamental problem.

 

Of couse you'll have to use 10.6 SDK to build for Snow Leopard. There is no way to get around this requirement for a clean solution. Creating one binary for SL, L and ML won't work and is not the way it was designed by Apple. Even Apple's Lion drivers cause problems when used under ML.

 

And if you look at 10.8.3 sources, you will see even more funny business going on with the vtable of IONetworkController... I'm really not sure what Apple is up to and what the strategy for backward compatibilty (building w/ old headers running on new system)/forward compatibility (building w/ new headers running on old system). The whole system looks pretty fragile to me.

 

It's not fragile, they are improving the network subsystem making it fit for 10GE because without offloading most of the network related tasks to the NIC the next generation of Ethernet would be almost useless due to CPU load and speed limitations.

 

Mieze

Share this post


Link to post
Share on other sites

Of couse you'll have to use 10.6 SDK to build for Snow Leopard. There is no way to get around this requirement for a clean solution. Creating one binary for SL, L and ML won't work and is not the way it was designed by Apple. Even Apple's Lion drivers cause problems when used under ML.

 

Working here. I've tested my kext on ML 10.8.3, Lion 10.7.5 and SL 10.6.8. I guess I'll roll with it until it is proven not to work.

 

It's not fragile, they are improving the network subsystem making it fit for 10GE because without offloading most of the network related tasks to the NIC the next generation of Ethernet would be almost useless due to CPU load and speed limitations.

 

I'm saying modifying the base classes the way they do and even using C++ as a driver model is fragile. Perhaps Apple has intended hardware vendors to release new drivers each time the OS is updated... but that, to me, is the definition of "fragile." The ability for the OS to evolve, still work with older drivers (not taking advantage of new OS features, of course), and providing a way for new drivers to take advantage of new features in the OS, should they be present, would be "not fragile."

Share this post


Link to post
Share on other sites

Working here. I've tested my kext on ML 10.8.3, Lion 10.7.5 and SL 10.6.8. I guess I'll roll with it until it is proven not to work.

 

Have you thoroughly tested IPv6? As its hardly used problems are not obvious but may cause serious problems including KPs in certain conditions.

 

I'm saying modifying the base classes the way they do and even using C++ as a driver model is fragile. Perhaps Apple has intended hardware vendors to release new drivers each time the OS is updated... but that, to me, is the definition of "fragile." The ability for the OS to evolve, still work with older drivers (not taking advantage of new OS features, of course), and providing a way for new drivers to take advantage of new features in the OS, should they be present, would be "not fragile."

Since SL OS X's internal architecture has dramatically changed. By the way, have you studied the linux code the driver is based on? OS X has a much cleaner driver architecture than linux ever had and the kernel interfaces are quite stable, compared to Linux, provided you use it the way it was meant to be. The only difference is that on the linux side no one is complaining about the drivers because a new kernel release always comes with a complete set of matching drivers.

 

Mieze

Share this post


Link to post
Share on other sites

Have you thoroughly tested IPv6? As its hardly used problems are not obvious but may cause serious problems including KPs in certain conditions.

 

Thanks for the tip. My ability to test IPv6 is limited. I have an IPv6 enabled router, but my ISP is IPv4 only. So far I don't see any outward signs of IPv6 being supported (w/ my setup) in OS X, but I'll see if I can find some tools w/in OS X for IPv6 status.

 

Since SL OS X's internal architecture has dramatically changed. By the way, have you studied the linux code the driver is based on? OS X has a much cleaner driver architecture than linux ever had and the kernel interfaces are quite stable, compared to Linux, provided you use it the way it was meant to be. The only difference is that on the linux side no one is complaining about the drivers because a new kernel release always comes with a complete set of matching drivers.

 

I don't have any experience w/ Linux drivers. More experience in Windows... And yes, it is an amazing feat that Linux does to be able to rev. everything at once like that. Of course, last time I tried Linux on my desktop, the LAN drivers for Intel 82579 won't work...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By ITzTravelInTime
      KX AUDIO DRIVER MOD
       
      Hi guys i am a small developer, i really like to use my sound blaster cards on my machines and i love also coding, so when i find the source code for the kx audio driver on git hub and then Eugene, the creator of kx audio driver decided to no longer maintain the project, i decided to start working on a mod of this driver. 
       
      With my mod, created starting from the sources of the last version of kx audio driver, and also by using apple developer documentation for pci and audio drivers as reference, i am working to achieve 2 things mainly: get all the cards supported by the driver to work with all the recent versions os macOS and add support for other cards that are not officially supported by the driver that works or could, but needs to be more properly supported.
       
      This driver is made to support cards based on the E-mu 10k1, 10k2 and similars (like what is used by audigy rx and audigy 4 cards).
       
      Supported cards are:
       
       - most of the sound blaster live!, live! 5.1 and live! 5.1 digital series
       - sound blaster 512
       - sound blaster 256
       - other creative and e-mu sound cards based on the 10k1 chip (cards with the ES1370/ES1371/ES1372/ES1373 chips are not supported)
       - sound blaster Audigy series (1 st gen)
       - sound blaster Audigy 2  and audigy 2 zs series
       - E-MU cards based on the 10k2 sound chip
       - Some Audigy 4 cards (SB0610 only) and the audigy 4 pro
       - Sound blaster Audigy RX (sb0155)
       - other creative and e-mu cards based on the (10k2, 10k2,5 and CA10300 based cards)
       
      NOT supported cards:
       
       - Any ISA Sound card
       - ES1370/ES1371/ES1372/ES1373 based sound cards
       - CMI8738/CMI8788 based cards
       - Any CA0106 based card and cards with similar architectures (like sound blaster live! 24 bit, sound blaster audigy SE SB0570, audigy LS and similars, but audigy SA is supported)
       - Any sound blaster x-fi (some of them works on macOS using a modified version of voodoo hda)
       - Any sound blaster recon3D
       - Any sound blaster Z/ZS/ZX and similar series
       - Any sound blaster AE5 series
       
      In the time being the things i have modded or added with this mod are:
       
      - increased the simple buffer frames number with different values for emu10k1 based cards and emu10k2 based cards (including recent audigy 4 and rx) to reduce and all the audio cracking issues and possibly fixing all of them on a lot of cards
       
      - added a more proper support for the pci express sound blaster audigy rx (which basically is an audigy 4 with a pcie bridge chip) 
       
      - added more fancy names for the cards in the settings and other menus (so the name will be, for example, SB live! 5.1 SB0060 instead of kx SB0060 [e880] witch was shown in the original driver)
       
      - added support to sample rate changing and added lots of sample rates (from 8 khz to 176,4 khz) to accomodate any possible usecase (note that 10k1 sound cards are limited up to 48khz sample rate, and 10k2 based cards are limited to 176,4 khz because of issues getting 192 khz to work, for now the driver goes up to 176,4 khz for such cards) 
       
      - added boot args to manage the driver:
       
      Boot args to use with the kx audio driver mod: -kx_disable or -kxdisable or -kxoff This will prevent the driver from doing any initialization work, so the driver is basically disabled, use it to boot your ssytem in case the driver is giving you issues and kernel panics while you are trying to boot/using your system, so you are able to remove this driver or replace it with another version of it or to do some truble shooting. -kx_debug or -kxdebug or -kxspec Will show more debug info about the card, mainly the i/o port address and the kind of bus that it uses -kx_exp_deb or -kx_beta or -kxbeta Will enable experimental and probably not working or unstable features like showing inputs for the card or 192 khz sampling rate, use it only for testing and debug purposes, this may likely cause instability and problems in the everyday usage! Use it at your own risk! -kx_original or -kxoriginal This will basically turn off almost all the mods of this mod, so the driver will come to work as it was before modding it, this can be usefoul as a "safe mode" like feture to have a working driver in case of problems with features of the mod, so using this means no crsking issues improvements, only 48 khz sample rate and only features of the non-modded kx audio driver for mac os x  
      - created a script file to use with the driver for installing the driver and also to load/unload, update, repolace it and it's libraries.
       
      What i'd like to implement but i don't know how to do:
       
       - I'd like mainly to add a more proper support to the pci bridge chip of the audigy rx,
       
       - have audio inputs working,
       
       - fix the support when using more than one card, to get all the cards shown in the settings and other menus,
       
       - have the gameport/midi port of older cards to be used in mac os as a midi in/out
       
      If other developers would like to join and help me, you can, and also an hand from other people with testing and feedback will be nice.
       
      link for the kext only (if you have clover put it in [your clover efi folder]/clover/kexts/[your macOS version]/ so it will not be deleted when updating macOS):
               - download from the downloads section:          kX Audio Driver Mod by ITzTravelInTime 1.01                                                                                    - external download:                                      https://dl.dropboxus...Driver.kext.zip   link for the installer pack (the best way to install it, but you have to reinstall it when you upgrade macOS, remeber to fix kext permitions and rebuild the kernelcache if you want to remove the kext from it's install directory without using the unistall feature of the provvided script):              - download:                                                   https://dl.dropboxus...aller pack.zip   Source code from Git Hub:          -  github repo:                                               https://github.com/ITzTravelInTime/kx-audio-driver   NOTE: Some system because of some problems with the HPET may need to use FixHPET in clover and to install the kext in /System/Library/Extensions or to do other kind of hpet mods to run the driver properly, but only on some systems, most systems should not require it  






    • By Abz79
      up guys,
      I've been hockintoshing for a long while, since Leopard to be exact and last week I replaced my Nvidia 9600GT with a brand new 1050 Ti...
      I have a Lion and El Capitan both were running fine before the 1050 Ti arrived, I read that my new Geforce needs new drivers that are readily supported by Sierra and High sierra.
      So I deleted Capitano and installed High Sierra 10.13 using Niresh distro. All went well and smooth and all my hardware was recognized the only problem left is this:
      My Nvidia driver "WebDriver-378.10.10.10.15.121" installs well with SIP enabled (aka 0x0 with clover) and after reboot the system is perfect with Nvidia web driver running fine
      However after rebooting the Default slow OSX graphics driver is loaded and stays that way until I resinstall the web driver....
       
      It's very annoying, I just can't make it work, I've been reading posts and tutorials for more that a week, nothing works, help is needed
       
      Things I've tried already:
      1. Boot using different clover revisions as old as 3911 and as new as 3509 (the latest)
      2. Tried with clover in the EFI partion and/or Boot partition
      3. Tried using different combos of nvda_drv,, nvidia webdriver, inject stuff (all possible combos in boot and graphics settings)
      4. Tried all available kext (Lilu, Nvidia fixup, Nvidiaegpusupport, NVlibvalfix..) single and combos - in clover kext folder and L/E folder
      5. Tried all different NVram recommendation - problem persisted even when nvram.plist is present or not
      6. Tried running the postscripts from the driver installer pkg
      7. Tried installing the driver via webdriver.sh
      8. Fixing permissions and what not
      And maybe other stuff that I forgot
       
      Things to note:
      When the graphics web driver loads fine KCPM kext utility works fine too but when the default driver is loaded KPCM warns that B0 and B1 SIP options are not enabled even though they are when I test csrutil status
      So I'm somehow thinking of a bug in Clover not applying the SIP restrictions correctly
      I don't know what happens when the driver is reinstalled that makes it work after reboot for 1 time only (I've went through all the pre post scripts in the installer and didn't find anything magical)
       
      It seems nothings works except reinstalling the driver - nothing else matters
      I'm almost pulling my hair - haven't faced such a problem since a very long time
      Any advice is greatly appreciated
       
      Abz
    • By Mieze
      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.     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
×