BCM5722, BCM5754/M, BCM5755/M, BCM5787/M and BCM5906/M NIC driver (32/64-bit)

[Alex009988]

Hi all,

 

Just wanted to say I have been using the this kext in my Dell Optiplex 745 (Desktop) since I hackintosh'd it and it works quite well. Been updating as new versions become available and currently on 2.3.5.

 

I'm no where near as versed as you guys here with code but if I can be of assistance I am more than happy to help out.

 

Regards,

Dan

Thanks for your feedback. Could you tell me which model of Broadcom you have?

[Dan_Marshall]

Hi Alex,

Thanks for your feedback. Could you tell me which model of Broadcom you have?

No problem at all - it is the stock NIC of the Dell Optiplex 745 - Broadcom 5754 Gigabit Ethernet LAN SOlution 10/100/1000 Ethernet with Remote Wake Up and PXE support

 

The speeds have been great. Only issue I have found (rarely btw) is that the Ethernet will lose connection on system waking up from sleep. Have not tested this on the 2.3.5 version as the system is running as a Plex / iTunes server so is now on 24/7, and only rebooted once every week.

 

Currently running Mountain Lion 10.8.4

 

Hope this helps - let me know if you need anything else

 

Great job

Dan

[HazMatt]

I checked the version for ML(Debug version) and it works though I have Mavericks. In additional, it's the last version 2.3.5.

Debug version is the same that main is. The only distinguish is that it gives more info to understand in which part of code we have a mistake.

What version of Mac do you use?

Didn't you forgot to fix permissions by Kext Utility or other program?

Yeah I don't know what to say.  I've gone back and forth, installing both the regular and debug versions using the same exact install procedure.  I have had good luck before using Kext Wizard, as permissions are set automatically for me.  Kext Wizard also has some maintenance utilities that repair permissions and rebuild mkext on /Extra, which I have done after each install as well.  I'm running OS X 10.8.4.

 

Using the debug version:

• Ethernet interface disappears from System Preferences > Network.

• System Information > Hardware > Ethernet Cards reports that no cards are connected.

 

Using the regular version:

• Ethernet interface is recognized correctly in System Preferences > Network.

• Using DHCP, the IP address is always 169.254.XXX.XXX; the X's are the only numbers to change after renewing the DHCP lease.

• Physically unplugging the ethernet cable causes the Ethernet interface to report "Not Connected / Cable Unplugged", which is good.

• The LED on my 10/100 Netgear switch is always blinking like mad when plugged in, even though no traffic is probably getting through.

See screenshots below for more details…

 

Thanks for the attention, Alex!

The LED on my 10/100 Netgear switch is always blinking like mad when plugged in, even though no traffic is probably getting through.

Since I'm in the mood to be thorough, I bypassed my 10/100 switch and plugged my computer directly into a gigabit port on one of our Netgear switches.  Things appear to have switched over successfully to 1000baseT (full-duplex) in System Preferences > Network > Advanced > Hardware.  I'm not sure if this proves anything, but it's additional information that might be helpful.

[Mieze]

Using the regular version:

• Ethernet interface is recognized correctly in System Preferences > Network.

• Using DHCP, the IP address is always 169.254.XXX.XXX; the X's are the only numbers to change after renewing the DHCP lease.

• Physically unplugging the ethernet cable causes the Ethernet interface to report "Not Connected / Cable Unplugged", which is good.

• The LED on my 10/100 Netgear switch is always blinking like mad when plugged in, even though no traffic is probably getting through.

See screenshots below for more details…

 

Since I'm in the mood to be thorough, I bypassed my 10/100 switch and plugged my computer directly into a gigabit port on one of our Netgear switches.  Things appear to have switched over successfully to 1000baseT (full-duplex) in System Preferences > Network > Advanced > Hardware.  I'm not sure if this proves anything, but it's additional information that might be helpful.

 

Please also post the kernel logs from /var/log/system.log and the output of ifconfig -v -a. It looks like there might be a problem in the NIC's initialization routine which prevents the NIC from establishing a proper connection with the switch.

 

You might also want to try to connect the machine directly to the remote machine and use Wireshark in order to see if transmission / reception of packets works. I described the method before in this thread.

 

With regard to the gigabit connection your post is not 100% clear. Does this mean that the NIC exhibits the same problem with a gigabit connection?

 

Mieze

[HazMatt]

With regard to the gigabit connection your post is not 100% clear. Does this mean that the NIC exhibits the same problem with a gigabit connection?

Yes, all I meant was that my ethernet port appears to be able to communicate successfully with the outside world to some minimal extent.  While it knows what speed it should be connecting at, I get the same problem, regardless of the switch on the other end.

 

var/log/system.log:

(When I plug the ethernet cable in…)

Sep  5 08:01:01 <computer name omitted> kernel[0]: my_name_adlan_BCM5722D: Link up: 100 MBps, full duplex. Flow control: symmetric

Sep  5 08:01:20 <computer name omitted>.local configd[17]: network changed: v4(en0:10.0.1.241, en1+:169.254.36.234) DNS* Proxy SMB

 

(When I unplug the ethernet cable…)

Sep  5 08:03:04 <computer name omitted> kernel[0]: my_name_adlan_BCM5722D: Link down

Sep  5 08:03:04 --- last message repeated 1 time ---

Sep  5 08:03:04 <computer name omitted>.local configd[17]: network changed: v4(en0:10.0.1.241, en1-:169.254.36.234) DNS* Proxy SMB

 

(When I plug the ethernet cable in…)

Sep  5 08:03:43 <computer name omitted> kernel[0]: my_name_adlan_BCM5722D: Link up: 100 MBps, full duplex. Flow control: symmetric

Sep  5 08:04:03 <computer name omitted>.local configd[17]: network changed: v4(en0:10.0.1.241, en1+:169.254.20.115) DNS* Proxy SMB

 

Output of ifconfig -v -a:

Last login: Thu Sep  5 07:56:49 on console

<computer name omitted>:~ <username omitted>$ ifconfig -v -a

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 index 1

eflags=10000000<SENDLIST>

options=3<RXCSUM,TXCSUM>

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 

inet 127.0.0.1 netmask 0xff000000 

inet6 ::1 prefixlen 128 

link quality: 100 (good)

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 index 2

stf0: flags=0<> mtu 1280 index 3

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 index 4

eflags=841<AUTOCONFIGURING,ACCEPT_RTADV,ARPLL>

options=3<RXCSUM,TXCSUM>

ether bc:5f:f4:ba:46:b1 

inet6 fe80::be5f:f4ff:feba:46b1%en1 prefixlen 64 scopeid 0x4 

inet 169.254.20.115 netmask 0xffff0000 broadcast 169.254.255.255

media: autoselect (100baseTX <full-duplex>)

status: active

link rate: 100.00 Mbps

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 index 5

eflags=200840<ACCEPT_RTADV,ARPLL,NOACKPRI>

ether 90:f6:52:e5:61:66 

inet6 fe80::92f6:52ff:fee5:6166%en0 prefixlen 64 scopeid 0x5 

inet 10.0.1.241 netmask 0xffffff00 broadcast 10.0.1.255

media: autoselect

status: active

link rate: 130.00 Mbps

p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304 index 6

eflags=20080<TXSTART,LOCALNET_PRIVATE>

ether 02:f6:52:e5:61:66 

media: autoselect

status: active

scheduler: TCQ (driver managed)

link rate: 10.00 Mbps

 

I'll look into the Wireshark test in a moment and post back…

[HazMatt]

You might also want to try to connect the machine directly to the remote machine and use Wireshark in order to see if transmission / reception of packets works. I described the method before in this thread.

I downloaded and successfully installed Wireshark on my wife's MacBook Pro but didn't have time to really dive into the program (wife needed it for work).  By "connect the machine directly to the remote machine", I'm assuming you mean via a crossover cable?  There was a heck of a lot of noise going on when I was doing a "Capture" (due to all of the other devices on our network), so I think it would be wise to isolate that a little bit.

 

During my initial ping tests with a manual IP config, I was getting "No route to host" error messages.  While I'm familiar with the Ping tool and have used it many times before, the extra diagnostic steps you're describing are new to me, so I'll have to muddle my way through it and post back later.

[Mieze]

During my initial ping tests with a manual IP config, I was getting "No route to host" error messages.  While I'm familiar with the Ping tool and have used it many times before, the extra diagnostic steps you're describing are new to me, so I'll have to muddle my way through it and post back later.

 

You can use "arp -s ip-addr ethernet-addr" to add an ARP entry manually in order to get around the "no route to host" errors.

 

Mieze

[HazMatt]

New information…  Apparently something in the kernel_task process is mucked up, because it is eating up all of my spare RAM:

[Mieze]

New information…  Apparently something in the kernel_task process is mucked up, because it is eating up all of my spare RAM:

 

Looks like there is a memory leak in a loaded kext! Maybe it's a bug in this driver but I can't rule out that it's another kext. Question: Has anyone using this driver observed this behavior too?

 

Mieze

[joe75]

kernel task shows the mem leak of osx, not this driver.. since 10.7 it has just been getting worse, I'm surprised you didn't notice before now. it will steadily creep up in mem use to almost 3gb in most cases if you have 8gb or more a ram.

[Mieze]

kernel task shows the mem leak of osx, not this driver.. since 10.7 it has just been getting worse, I'm surprised you didn't notice before now. it will steadily creep up in mem use to almost 3gb in most cases if you have 8gb or more a ram.

In case a driver leaks packet buffers the leak would be attributed to the kernel itself because the buffers are allocated by the network stack, not the driver.

 

Maybe I should take a look at the driver's buffer management.

 

Mieze

[joe75]

if you suspect a leak it could definitely contribute to the higher kernel task but judging by kernel task alone is not enough.

[HazMatt]

I restarted, left the ethernet cable unplugged overnight and my RAM usage appears to be back at a more reasonable level.  kernel_task is still steadily eating up RAM (currently at 1.81 GB), but I don't know if that's abnormal for my system or not.  This is with the driver installed.

 

I still have yet to run those Wireshark tests, hopefully I'll have some results by the end of the weekend.

[joe75]

that is a little high from just over night.. i can't say how much would be related from the driver itself tho. my system averages about 300mb a day leaking to kernel_task. My biggest leaks are colloquy and an rss app snackr that i know have problems.

[Mieze]

I have checked the code and found no memory leaks but a serious problem with the output queue handling which might cause packet buffers to linger in the queue indefinitely.

 

1. enable() shouldn't start the output queue because at this point the NIC is still waiting for the connection to become established.
2. Queue management should be left to the link status change interrupt handler in order to prevent the queue from overflowing while there is actually no connection.
3. When the link goes up the handler should start the queue. In case it was stalled before this condition should be cleared to in order to resume normal operation.
4. When the link goes down the driver has to stop the output queue, flush it and clear out the transmitter ring freeing all packet buffers. This includes the ones which haven't been transmitted yet.

@Alex: Do think you can manage to make these changes on your own or do you need my help? The problem is that I'll go on a trip to Spain on Monday which means that I won't be able to help before 9/17.

 

Mieze

[Alex009988]

I have checked the code and found no memory leaks but a serious problem with the output queue handling which might cause packet buffers to linger in the queue indefinitely.

 

1. enable() shouldn't start the output queue because at this point the NIC is still waiting for the connection to become established.
2. Queue management should be left to the link status change interrupt handler in order to prevent the queue from overflowing while there is actually no connection.
3. When the link goes up the handler should start the queue. In case it was stalled before this condition should be cleared to in order to resume normal operation.
4. When the link goes down the driver has to stop the output queue, flush it and clear out the transmitter ring freeing all packet buffers. This includes the ones which haven't been transmitted yet.

@Alex: Do think you can manage to make these changes on your own or do you need my help? The problem is that I'll go on a trip to Spain on Monday which means that I won't be able to help before 9/17.

 

Mieze

Hello, Mieze. I will try, but I'm not sure that I will be able to cope with that.

As I understood. Should Changes  be done at BCM5722D.cpp?

I noticed the last Driver BCM5722D doesn't know what it is LinkUp and LinkDown at all.

I glance over your code of  RealtecRTL8111. Is it enough hard to adapt parts of code for BCM5722D?

void RTL8111::setLinkDown()
{
    deadlockWarn = 0;
    needsUpdate = false;
    //txIntrRate = 0;

    /* Update link status. */
    linkUp = false;
    setLinkStatus(kIONetworkLinkValid);
    
    /* Stop txQueue and cleanup descriptor ring. */
    txQueue->stop();
    txQueue->flush();
    IOLockLock(txLock);
    txClearDescriptors(false);
    IOLockUnlock(txLock);
    IOLog("Ethernet [RealtekRTL8111]: Link down on en%u\n", unitNumber);
}

Should I add  that to mine driver something like that and...?(So I think differences between Realtek and BCM are great and it is not the best idea..., so I have to use it smartly)

PS. Thank you a lot for your help. You've already done a lot. Even not every developer  take on that work if he or she  don't have the equipment.

I wish you would have a good time at your coming holiday.

Thanks again to you.

[Mieze]

Hello, Mieze. I will try, but I'm not sure that I will be able to cope with that.

As I understood. Should Changes  be done at BCM5722D.cpp?

I noticed the last Driver BCM5722D doesn't know what it is LinkUp and LinkDown at all.

I glance over your code of  RealtecRTL8111. Is it enough hard to adapt parts of code for BCM5722D?

 

Should I add  that to mine driver something like that and...?(So I think differences between Realtek and BCM are great and it is not the best idea..., so I have to use it smartly)

PS. Thank you a lot for your help. You've already done a lot. Even not every developer  take on that work if he or she  don't have the equipment.

I wish you would have a good time at your coming holiday.

Thanks again to you.

 

Yes, my Realtek driver is a good tutorial to show you what has to be done. I suggest you start with the queue management because this is completely hardware independent. Also take a look the documentation of the queue management functions: start(), stop() and flush(). Xcode is your friend. After you got this working properly you can add the cleanup of the transmitter ring.

void BCM5722D::serviceLinkInterrupt()
{
  statusBlock->statusWord &= ~STATUS_WORD_LNKCHGD;

  setupPHY();

  if (media.state == kLinkStateUp) {
    setLinkStatus(kIONetworkLinkValid | kIONetworkLinkActive,
                  IONetworkMedium::getMediumWithIndex(mediumDict,
                                                      currentMediumIndex));
  } else {
    setLinkStatus(kIONetworkLinkValid, 0);
  }

  reportLinkStatus();
} // serviceLinkInterrupt()

This is the routine where you'll have to apply most of the changes. The general structure should be quite clear.

 

Good luck!

 

Mieze

[HazMatt]

Some updates…

 

Over the last couple of days I kept an eye on the level of RAM that kernel_task was consuming, and this time it did NOT ramp up to eat it all up.  For the first day I left the cable unplugged and it remained at 1.45 GB.  It climbed to 1.77 GB and then I plugged in the ethernet cable.  A day later it was still at 1.77 GB.  I don't really know what that all means, but perhaps my previous RAM usage was a fluke.

 

I decided to give my original .kext file a try again (the now defunct one, formerly available here), and it worked, but only after I deleted both my existing WiFi and Ethernet interfaces from System Preferences > Network.  So, the good news is I'm back up and running, but I'm not using the .kext available in this thread.  I'm going to watch this thread and will likely be able to test out newly released versions.

[Alex009988]

@Mieze, thanks for your help. But it seems that Register.h also has  some inaccuracy.

Here is a data sheet for bcm57781. For the time present, I haven't gain an understanding of it yet. But I don't give up.

http://www.broadcom.com/collateral/pg/57785-PG103-R.pdf

I also looked at tg3 and bge

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/drivers/net/tg3.c

http://fxr.watson.org/fxr/source/dev/bge/if_bgereg.h

I decided to start off with simplicity.

I added what you suggested me. But I get a mistake during a compilation.

Ld /Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Products/Debug/BCM5722D.kext/Contents/MacOS/BCM5722D normal x86_64
    cd /Users/admin/Downloads/BCM5722D
    setenv MACOSX_DEPLOYMENT_TARGET 10.9
    /Applications/Xcode5-DP.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode5-DP.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -L/Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Products/Debug -F/Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Products/Debug -filelist /Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Intermediates/BCM5722D.build/Debug/BCM5722D.build/Objects-normal/x86_64/BCM5722D.LinkFileList -mmacosx-version-min=10.9 -Xlinker -kext -nostdlib -lkmodc++ /Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Intermediates/BCM5722D.build/Debug/BCM5722D.build/Objects-normal/x86_64/BCM5722D_info.o -lkmod -lcc_kext -Xlinker -dependency_info -Xlinker /Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Intermediates/BCM5722D.build/Debug/BCM5722D.build/Objects-normal/x86_64/BCM5722D_dependency_info.dat -o /Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Products/Debug/BCM5722D.kext/Contents/MacOS/BCM5722D

duplicate symbol __ZN22my_name_adlan_BCM5722D20serviceLinkInterruptEv in:
    /Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Intermediates/BCM5722D.build/Debug/BCM5722D.build/Objects-normal/x86_64/PHY.o
    /Users/admin/Library/Developer/Xcode/DerivedData/BCM5722D-fcooihstpbdwkhezjwqbemonljsx/Build/Intermediates/BCM5722D.build/Debug/BCM5722D.build/Objects-normal/x86_64/BCM5722D.o
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I tried it added in several places but anytime I get the same mistake.

What is the appropriate place in the code for it?

[Huberer]

Hello Alex,

 

are there any news in progress with bcm57781? I'm having the Asrock Z77E-ITX with bcm57781 LAN and with your v2.3.5 kext I face the same problems which HazMat has (using Mountain Lion 10.8.5).

 

I get the similar IP-address instead of 192.168.1.x. Adding the IP and subnet manuell doesn't work either. I've added the kext to S/L/E.

How can I get my lan-card to work prober with your kext?

 

Yeah I don't know what to say.  I've gone back and forth, installing both the regular and debug versions using the same exact install procedure.  I have had good luck before using Kext Wizard, as permissions are set automatically for me.  Kext Wizard also has some maintenance utilities that repair permissions and rebuild mkext on /Extra, which I have done after each install as well.  I'm running OS X 10.8.4.

 

Using the debug version:

• Ethernet interface disappears from System Preferences > Network.

• System Information > Hardware > Ethernet Cards reports that no cards are connected.

 

Using the regular version:

• Ethernet interface is recognized correctly in System Preferences > Network.

• Using DHCP, the IP address is always 169.254.XXX.XXX; the X's are the only numbers to change after renewing the DHCP lease.

• Physically unplugging the ethernet cable causes the Ethernet interface to report "Not Connected / Cable Unplugged", which is good.

• The LED on my 10/100 Netgear switch is always blinking like mad when plugged in, even though no traffic is probably getting through.

See screenshots below for more details…

 

Thanks for the attention, Alex!

Since I'm in the mood to be thorough, I bypassed my 10/100 switch and plugged my computer directly into a gigabit port on one of our Netgear switches.  Things appear to have switched over successfully to 1000baseT (full-duplex) in System Preferences > Network > Advanced > Hardware.  I'm not sure if this proves anything, but it's additional information that might be helpful.

 

@HazMatt

 

which kext do you use? Your link in your post just show the start page of osx86

 

Thanks in advance

 

Huberer

[HazMatt]

which kext do you use? Your link in your post just show the start page of osx86

I'll PM you the .kext I use.  I don't know why they took down that page.

[Mieze]

Hello Alex,

 

are there any news in progress with bcm57781? I'm having the Asrock Z77E-ITX with bcm57781 LAN and with your v2.3.5 kext I face the same problems which HazMat has (using Mountain Lion 10.8.5).

 

As of now patching Apple's Broadcom driver is still the easiest and most compatible way to get the BCM57781 working. I created a patch for the 10.9 beta and 10.8.3, which should work for 10.8.4 and 10.8.5 too. In case someone is interested please open up a new topic and tell me where I can find it via PM so that I can post the instructions there.

 

Mieze

[Alex009988]

As of now patching Apple's Broadcom driver is still the easiest and most compatible way to get the BCM57781 working. I created a patch for the 10.9 beta and 10.8.3, which should work for 10.8.4 and 10.8.5 too. In case someone is interested please open up a new topic and tell me where I can find it via PM so that I can post the instructions there.

 

Mieze

Hello, Mieze. I'm very glad to see you. As you suggested above to open up a new topic, I've already done even though  BCM5722D works for me very well. But at the same time I long to try native driver out.

Thanks for your work and help.

Could you go in my topic, please, to discuss about it more exactly. Thanks in advance!

http://www.insanelymac.com/forum/topic/292175-patch-of-applebcm5701ethernet-for-ml-mavericks/

[existation]

Can I use this kext for bcm57781 (14e4-16b1) in MLion & Mavr?

And where i can download him?

Lets see.

I downloaded MLIon version, installed and:

- i can see ethernet in Network

- i can see ethernet in System profile

- but no traffic 

Reason: kext don't work in MLION 10.8.5

output from dmesg:

 

.

.

BCM5722D (Build date/time: Jun 24 2013 12:24:10)

my_name_adlan_BCM5722D: Model: BCM57781 NetLink Gigabit Ethernet

my_name_adlan_BCM5722D: Loaded successfully

my_name_adlan_BCM5722D: Ethernet address dc:xx:xx:xx:xx:ea // mac address is good

.

.

my_name_adlan_BCM5722D: Link up: 100 MBps, full duplex. Flow control: disabled

.

considerRebuildOfPrelinkedKernel my.name.adlan.BCM5722D triggered rebuild

.

my_name_adlan_BCM5722D: Link down

my_name_adlan_BCM5722D: Link up: 100 MBps, full duplex. Flow control: disabled

.

my_name_adlan_BCM5722D: Link up: 100 MBps, full duplex. Flow control: disabled

 

PS I forgot. In my DSDT i have this method:

Device (LAN0)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
                {
                    0x09, 
                    0x04
                })
                Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    Store (Package (0x0E)
                        {
                            "AAPL,slot-name", 
                            Buffer (0x09)
                            {
                                "Built-In"
                            }, 

                            "name", 
                            "Ethernet", 
                            "model", 
                            Buffer (0x26)
                            {
                                "Broadcom BCM57781 Ethernet Controller"
                            }, 

                            "device_type", 
                            Buffer (0x14)
                            {
                                "Ethernet Controller"
                            }, 

                            "compatible", 
                            "pci14e4,16b1", 
                            "built-in", 
                            Buffer (One)
                            {
                                 0x01
                            }, 

                            "location", 
                            Buffer (0x02)
                            {
                                "1"
                            }
                        }, Local0)
                    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                    Return (Local0)
                }
            } 

Next Mavericks test...

 

same things in 10.9.

In dmesg i have

BCM5722D (Build date/time: Jun 24 2013 12:20:29)

my_name_adlan_BCM5722D: Model: BCM57781 NetLink Gigabit Ethernet

my_name_adlan_BCM5722D: Loaded successfully

 

my_name_adlan_BCM5722D: Link up: 100 MBps, full duplex. Flow control: disabled

 

considerRebuildOfPrelinkedKernel my.name.adlan.BCM5722D triggered rebuild

[Alex009988]

Many users complain about not-working BCM5722D on BCM57781. I have BCM57780 and it works excellent.

Try this old version and tell if it works in order to find out if it doesn't work only on the latest versions of the driver or with the old kext it is the same.

http://www.osx86.net/files/file/916-bcm5722d-kext/