Badeendje

Wifi kext's are highly unstable due to probably adding 801.22ac support which I think requires a major overhaul.
It'll take same major testing and we also saw an increase from 5.2.2 to 5.3 which tells it's a major revision, not just a simple one.
Just keep in mind these are development builds, they are and never were meant to be stable in the first place.
They give developers a chance to test there hard- and software previous to releasing a new build which may or may not break part(s) of their products.
And that's exactly what we use it for, I not only test certain software we made in house but also some hardware for upgrades.
Only after I give the green light we'll upgrade to the new update or new os for that matter.
Due to some issues we still haven't upgraded some of our iMacs from 10.7 to 10.8.
That's what dev builds are for, not more, not less and anyone can quote all of this all day long.

We'll see, still new kext's or added id's have been known to be included in dev builds (and sometimes even removed from final builds).
But indeed it's great news for a lot of us as there are quite some broadcom id's that won't work atm but do have the potential to work (http://www.insanelym...ss-driver-beta/).

For me it's all about a replacement mini pci-e card for the Mac Pro's at work, some genius over there has decided we could do without ethernet in our new office and time machine over wlan is far from funny to me.
In the past I was all about finding a faster gfx card for them but the ati 7950 is plenty fast for now, and if I can fix this time machine 'issue' these Mac Pro's will last us another 2 years.

Badeendje, on 10 April 2013 - 09:48 PM, said:

Have been reading a bit more about the 802.11ac standards and there's a high probability we'll see a BCM4352(6) card, matching 14e4:43b1.
This weekend when I got more time I'll look if it's in the latest beta.

Here
Let us know if you can identify any supported cards.

Quick scan on my part (only broadcomm as it's suspected apple will be using those).
supported:

pci14e4,4311
pci14e4,4312
pci14e4,4313
pci14e4,4318
pci14e4,4319
pci14e4,431a
pci14e4,4320
pci14e4,4324
pci14e4,4325
pci14e4,4328
pci14e4,4331
pci14e4,432c
pci14e4,432d
pci14e4,4353
pci14e4,432b

Finally had the time to sort out the log;

31-03-13 15:20:53,000 kernel[0]: RealtekR1000: init
31-03-13 15:20:53,000 kernel[0]: RealtekR1000: start
31-03-13 15:20:53,000 kernel[0]: RealtekR1000: R1000InitBoard @ PCI 0x7,00
31-03-13 15:20:53,000 kernel[0]: RTL8xxx@0xce00: Found chip reg=2f900d00
31-03-13 15:20:53,000 kernel[0]: RTL8xxx@0xce00: Realtek RTL8168E-VL/8111E-VL (mcfg 30)
31-03-13 15:20:53,000 kernel[0]: identified as RTL8168E-VL/8111E-VL
31-03-13 15:20:53,000 kernel[0]: RTL8xxx@0xce00: 1000Mbps Full-duplex operation, TBI Link Failed
31-03-13 15:20:53,000 kernel[0]: RTL8xxx@0xce00: Link Status: Not Linked
31-03-13 15:20:53,000 kernel[0]: RTL8xxx@0xce00: registerWithPolicyMaker
31-03-13 15:20:53,000 kernel[0]: RTL8xxx@0xce00: setPowerState(1)
31-03-13 15:20:53,000 kernel[0]: RTL8xxx@0xce00: configureInterface
31-03-13 15:20:53,000 kernel[0]: RTL8xxx@0xce00: attaching as en0
31-03-13 15:20:53,000 kernel[0]: en0: start: returning '1'
31-03-13 15:20:55,000 kernel[0]: en0: enable
31-03-13 15:20:55,000 kernel[0]: en0: setActivationLevel(2)
31-03-13 15:20:55,000 kernel[0]: en0: Selected medium is NULL, forcing to autonegotiation
31-03-13 15:20:55,000 kernel[0]: en0: selectMedium, index=6
31-03-13 15:20:55,000 kernel[0]: en0: R1000SetMedium(0x2, 0x2, 0x1)
31-03-13 15:20:57,000 kernel[0]: en0: Link up

Again this on a GA

-Z68X-UD3H-B3 board, an otherwise well supported and

popular board, except I never had the ethernet working stable.
This is the first kext working great except the occasional lockups which are pretty bothersome.