Intel Network adapters on OS X: Small Tree drivers

[the-darkvoid]

Ah I see my mistake...
Seems I have too many FakePCIID's lying around and used to wrong file to create yours.

Thanks Rehabman for spotting that!

numasan,

After your feedback I have created a more final version of the injector which handles all defined Intel GbX (10-gbit) network cards supported.

If you could please try out the attachment and confirm it is working, then it can be added to the FakePCI repository.

The behavior should be identical to the version you manually fixed the bundle ID of, only it matches to more devices.

 

[numasan]

Hi again!

Ok, weird thing - when I booted up in OSX today, the Small Tree driver could not recognise the card again... It worked yesterday, and the machine was used with Linux today, so nothing was "touched" on OSX.

Anyways, I removed (rm -rf) the FakePCIID* and SmallTree drivers, installed your new FakePCIID* drivers, rebooted, installed the SmallTree driver, rebooted again, and system.log showed successful recognition of the card by the SmallTree driver. So YAY! Strangely enough the nic didn't show up automatically in the Network preferences, until after I rebooted yet again.

I have rebooted/shutdown some more times, and booted up in Linux and back to OSX, and the card is recognised every time now, and hopefully it stays like that!

So thank you and big ups for getting this to work!

PS: Will FakePCIID* work on a real Mac?

 

[RehabMan]

...
PS: Will FakePCIID* work on a real Mac?

Yes, but anything that requires DSDT/_DSM injection is not possible unless you hack the Mac (eg. use a hackintosh bootloader).

 

[the-darkvoid]

numasan,

Your specific FakePCIID.kext for your card will work on a real Mac as it does not use DSDT injection.
However the kexts are not signed, so you would need to modify the Mac nvram to kext-dev-mode=1, which is a potential security risk.

Also to ensure the card works fine, I would always shutdown the machine fully before booting OS X.
I.e. not reboot from Linux into OS X directly, the card might have been initialized in Linux and somehow that conflicts. A power-down will ensure the card is uninitialized.

Can you confirm that you also successfully connected it to the network now?

 

[numasan]

Your specific FakePCIID.kext for your card will work on a real Mac as it does not use DSDT injection.
However the kexts are not signed, so you would need to modify the Mac nvram to kext-dev-mode=1, which is a potential security risk.

Thanks, I will try it out and report back. It might take at least a month before I have a chance to do it though, as we only have one Mac with a production starting up.

Also to ensure the card works fine, I would always shutdown the machine fully before booting OS X.
I.e. not reboot from Linux into OS X directly, the card might have been initialized in Linux and somehow that conflicts. A power-down will ensure the card is uninitialized.

Ok I see. It happened again today, with the SmallTree driver not recognising the card. The way this system is set up now, I go into the BIOS, select the hd OSX is on, and boot from there. The machine was powered down before doing this. After a couple of reboots straight into OSX and the card still unrecognised, I shutdown the machine and turned the power supply off for a minute. Once in OSX the SmallTree driver still didn't work.

Removing the SmallTree driver, rebooting, installing the driver again with kext utility, reboot, and the 10gb card is working again.

Not optimal, but I guess a small price to pay, not having to pay the artificially inflated price Small Tree demands... This machine will be in Linux 80-90% of the time. If this was a pure hackintosh, I guess the driver would work every time.

Can you confirm that you also successfully connected it to the network now?

The card is successfully connected to the network, albeit only through 1gb. Hopefully we have new CAT7a pulled within a month, and I will report back here how it performs at native speed.

 

[numasan]

Hmm.. I turned of the machine for an hour to see if the card would work again when booted. I haven't changed BIOS or boot the Linux hd, so this machine should act as a pure hackintosh. The SmallTree driver won't work again...

Here's the output from system.log, from a successful boot and the fail an hour later:

Feb 11 19:31:47 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x getNVM b3d0f0: Mac address: a0:36:9f:56:ee:0a
Feb 11 19:31:49 Slowmotions-Mac-Pro kernel[0]: Initializing SmallTreeIntel8259x: Version 3.1.1 Built Oct 7 2014 07:48:15 Build: 2210:2475M
Feb 11 19:31:49 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x phyPublishMedia b3d0f0: SFP Type 65535 optical speed is 11
Feb 11 19:31:49 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x start b3d0f0: initial sfp type 65535, phy type 3
Feb 11 19:31:49 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x checkLinkStatus b3d0f0: Link is DOWN
Feb 11 19:31:49 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x checkLinkStatus b3d0f0: Link status 1
Feb 11 19:31:49 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x setLinkStatus b3d0f0: Entered: status=1 medium=0
Feb 11 19:31:49 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x UpdatePhyList b3d0f0: SFP Type 65535
Feb 11 19:31:49 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x start b3d0f0: start: close
Feb 11 19:31:51 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x setPowerState b3d0f0: power management state set to 2
Feb 11 19:31:51 Slowmotions-Mac-Pro kernel[0]: SmallTreeIntel8259x configureInterface b3d0f0: Confg Intrface sfp type 65535, phy type 3
Feb 11 19:31:51 frog kernel[0]: SmallTreeIntel8259x setPowerState b3d0f0: power back on, Wol status WUC 0x00000010, WUS 0x00000000, WUFC 0x00000000
Feb 11 19:31:57 frog kernel[0]: SmallTreeIntel8259x selectMedium en1: Entered with medium=0 00000020
Feb 11 19:31:57 frog kernel[0]: SmallTreeIntel8259x up en1: Link up
Feb 11 19:31:57 frog kernel[0]: SmallTreeIntel8259x up en1: Returning ret=0x0
Feb 11 19:31:58 frog kernel[0]: SmallTreeIntel8259x UpdatePhyList en1: SFP Type 65535
Feb 11 19:31:58 frog kernel[0]: SmallTreeIntel8259x checkLinkStatus en1: Link is DOWN
Feb 11 19:31:58 frog kernel[0]: SmallTreeIntel8259x checkLinkStatus en1: Link status 1
Feb 11 19:31:58 frog kernel[0]: SmallTreeIntel8259x setLinkStatus en1: Entered: status=1 medium=0
Feb 11 19:31:58 frog kernel[0]: SmallTreeIntel8259x UpdatePhyList en1: SFP Type 65535
Feb 11 19:32:27 frog kernel[0]: SmallTreeIntel8259x checkLinkStatus en1: Link is UP
Feb 11 19:32:27 frog kernel[0]: SmallTreeIntel8259x checkLinkStatus en1: Link status 3
Feb 11 19:32:27 frog kernel[0]: SmallTreeIntel8259x setLinkStatus en1: Entered: status=3 medium=3
Feb 11 19:32:27 frog kernel[0]: SmallTreeIntel8259x UpdatePhyList en1: SFP Type 65535
Feb 11 19:32:28 frog kernel[0]: SmallTreeIntel8259x checkLinkStatus en1: Link is UP
Feb 11 19:32:28 frog kernel[0]: SmallTreeIntel8259x checkLinkStatus en1: Link status 3
Feb 11 19:32:28 frog kernel[0]: SmallTreeIntel8259x setLinkStatus en1: Entered: status=3 medium=2
Feb 11 19:32:28 frog kernel[0]: SmallTreeIntel8259x UpdatePhyList en1: SFP Type 65535
Feb 11 19:33:27 frog kernel[0]: considerRebuildOfPrelinkedKernel com.SmallTree.driver.SmallTreeIntel8259x triggered rebuild
Feb 11 20:37:24 localhost kernel[0]: SmallTreeIntel8259x probe b3d0f0: Unsupported Card 0x0002
Feb 11 20:37:24 localhost kernel[0]: SmallTreeIntel8259x freeResources b3d0f0: Entered freeResources

I have highlighted a message that I think is suspicious. The card was functioning during that session past 19:33 until shutdown, so can the 'rebuild' have had an effect on the consequent startup? Can it have something to do with the order of drivers loading, as in the SmallTree driver loading before the FakePCIID?

 

[RehabMan]

...
Feb 11 19:33:27 frog kernel[0]: considerRebuildOfPrelinkedKernel com.SmallTree.driver.SmallTreeIntel8259x triggered rebuild
Feb 11 20:37:24 localhost kernel[0]: SmallTreeIntel8259x probe b3d0f0: Unsupported Card 0x0002
Feb 11 20:37:24 localhost kernel[0]: SmallTreeIntel8259x freeResources b3d0f0: Entered freeResources

I have highlighted a message that I think is suspicious. The card was functioning during that session past 19:33 until shutdown, so can the 'rebuild' have had an effect on the consequent startup? Can it have something to do with the order of drivers loading, as in the SmallTree driver loading before the FakePCIID?

It means it wasn't in the cache when the computer booted that session, but the kext then loaded, and OS X says "hey, this kext loads at startup... I should rebuild cache".

After installing a kext, it is a good idea to rebuild cache explicitly before rebooting. Then test.

Did you install the driver to /S/L/E? Is your cache rebuild without errors? Always check for errors during a cache rebuild (good idea to use DPCIManager for that or to monitor system.log during the cache rebuild).

 

[jusetan]

Thanks for setting this all up!

I have the intelx540.
I copied the kext for

Attached Files

• 
  FakePCIID_Intel_GbX.zip (14.2 KB, 12 views)

I only copied the FakePCIID_Intel_GbX.kext using kext wizard installation. Copied to s/l/e.
Ran Maintenence - rebuild cache
Installed the small tree driver - SmallTreeIntel8259x-3.1.1
Rebooted system.

Opened about this mac - system report - ethernet cards - and it's not visible.
Open system prefs - network - not visible.

Am I missing a step or doing something incorrectly?

Should I install both KEXT files?
Does the install order change things?

Thanks in advance for your assistance...

 

[RehabMan]

Thanks for setting this all up!

I have the intelx540.
I copied the kext for

Attached Files

• 
  FakePCIID_Intel_GbX.zip (14.2 KB, 12 views)

I only copied the FakePCIID_Intel_GbX.kext using kext wizard installation. Copied to s/l/e.
Ran Maintenence - rebuild cache
Installed the small tree driver - SmallTreeIntel8259x-3.1.1
Rebooted system.

Opened about this mac - system report - ethernet cards - and it's not visible.
Open system prefs - network - not visible.

Am I missing a step or doing something incorrectly?

Should I install both KEXT files?
Does the install order change things?

Thanks in advance for your assistance...

Check if the driver loaded in ioreg....

Post ioreg: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply to an ioreg from any other version of IORegistryExplorer.app.

 

[jusetan]

Is this what you are looking for? Attached file.

Thanks again for your assistance.