Jump to content


  • Content count

  • Joined

  • Last visited

About Shailua

  • Rank
    InsanelyMac Protégé

Profile Information

  • Gender
  1. Glad to hear it's working for those it's working for. I've been tinkering with my AO522 netbook and managed to get Snow Leopard working on it, albeit rather poorly given it's an AMD C-50 processor with only fallback 800x600 graphics working. It's been good enough to allow me to install a Snow Leopard build of ALXEthernet however, so now I have an AR8152 v2.0 chipset to test things out on as well. I discovered a previously reported bug with running 32-bit drivers compiled with Xcode 4.5, so I'm back to using 4.4 for now. Xcode 4.4 with the Snow Leopard APIs and a minor code change later and the driver was working fine on the netbook. Still going to do some more testing but then I should be able to release builds for 10.6 as well as 10.7/10.8.
  2. The AR8152 is a 100Mb/s (non-gigabit) adapter, so it might not be worth switching if the other driver works fine. Speed is only really an issue if you transfer a lot of files around over your ethernet LAN or have a *really* fast Internet connection. That's very unfortunate. The MAC reset errors seem to be the issue. These are sent out by some of the low-level internal hardware code when something goes wrong. Was there any other [ALXEthernet] messages other than the MAC reset errors that you can see in /var/log/system.log from the Console app? If not it might be a problem that can only be fixed with a Linux patch from Atheros themselves. I'll try and investigate further if I can though. Sometimes I've noticed the ethernet card can go a little odd when a new kext is loaded for the first time though. You could try unplugging all power from your PC for a few seconds and then booting and see if it helps. There's a (very slim) chance that it might help.
  3. 1.0.2 is now up. Hopefully the memory allocation will be more forgiving now, but if the problems persist for some folks then I'll have look into rewriting some of the descriptor stuff. Hmm, unless it's a 32-bit issue. I haven't tried this driver at all in 32-bit mode since I'm on 10.8. One day I might add another HDD and install 10.7 with the 32-bit kernel for testing purposes. I have a old netbook I could also try that has an 8152 chipset in it, but getting Mac OS X working on an AMD Fusion laptop is a bit of a headache. Anyway, enough of my ranting. Good luck with testing everyone. Everything's fine on my machine so far while sending several gigabytes back and forth between it and my MacBook. Things definitely seem to transfer in both directions about 10-20MB/s faster with this driver than the AtherosL1cEthernet driver.
  4. Thanks for the error report! That's one of my "oh no this should never happen!" messages, so it's easy for me to pinpoint. I've been tinkering with the memory allocation code a bit lately, so I've hopefully fixed it with a more suitable allocation method that isn't a holdover from the original AtherosL1cEthernet code. Asking the kernel to allocate chunks of contiguous physical memory tends to be rather touchy, but I don't think these cards tolerate anything less. I'll double check everything is still working okay on my desktop machine when I'm back home tomorrow and hopefully get 1.0.2 out soon after that.
  5. Hi. I'm not sure why sleep might not be working. Does your motherboard use UEFI or a regular BIOS? If it's a BIOS, there may be a DSDT issue or something related to ACPI. I'm afraid my knowledge of such things is very limited. You might perhaps try the ALXEthernet driver instead. It's mostly on par with the AtherosL1cEthernet driver aside from some more advanced features I haven't enabled yet. The power management code might be more up to date. Part of the power management for these cards is in the low-level undocumented Atheros MAC/PHY code that is difficult for me to modify blindly. The rest is just PCI and IOKit stuff that should be working fine according to my understanding of the specs and sample code.
  6. Thank you for the great debug info! I'm glad it's all running fine now for you anyway, but to be sure I'll plug the panic values into the debugger and see what comes up just in case. It's possible that your kernel cache simply got corrupted. I've had that happen to me once or twice in the past. It might have to do with deleting the cache while the kextd daemon has partially rebuilt it already. I might alter my installation instructions to be less "aggressive", I guess you could say. Typically kextd just rescans stuff anyway as soon as it detects a change in /System/Library/Extensions. Manually deleting the cache seems to mostly only be needed from single user mode. I'm not too sure what the issue would be with the bootloader, unless you're trying to install things outside of /System/Library/Extensions. I don't have any issues with (recent build) Chameleon myself. I've heard good things about Clover though, so if it works for you I say stick with it.
  7. Okay, new 1.2.3 version posted. If everything works smoothly enough with it then I'll mostly stick to bug fixes on this driver and focus more on the ALXEthernet driver since it supports the same cards and more. About the only differences I've noticed on my 8151 between the two drivers is that link autonegotiation seems better with AtherosL1cEthernet, but top speeds seem greater with ALXEthernet. The former seems to have trouble breaking over the 100MB/s rate in my very limited testing. Thank you for the kind feedback! If there's one board that should definitely work well with the driver, it's the UD5H.
  8. Ah. Well they're definitely not the same files. The version number I assign can be confirmed with a right-click "Get Info" on the kext itself.
  9. I'm not quite sure what you mean. The top post contains both 1.0.0 and 1.0.1 under the Downloads subsection. They are both different files.
  10. hehe, good point. I tend to forget sometimes that some machines don't have their ethernet cable plugged in at boot. Thank you for the feedback! In general the process of smoothing out the link status reporting and still keeping everything working such as Bonjour entries in Finder with Wake On Demand has been a bit of a trial-and-error headache process. I've been looking through what I can in the (mostly pre-Intel) sourcecode for Apple's own ethernet drivers and I think I've narrowed down the "right" way of doing things. I'll try to get another bugfix release out ASAP now that I've finished the second ALXEthernet release. Fortunately both drivers share some very similar high-level code so it shouldn't be too difficult.
  11. Thank you for the feedback, it's good to know the AR8161 is at least (somewhat) working! I'll continue to improve what code I can as well as keep an eye out for newer low-level Linux code to merge. Sadly the ALX driver this is based on isn't even part of the stock-standard Linux kernel at this point as far as I can tell, but is a patch upon a patch upon a patch for adding experimental but badly-needed driver support to distros and is placed in a sub-directory ominously called "{censored}".
  12. Thank you for the feedback. The kext routine that tells Mac OS X that the card is enabled will delay for at least two seconds in this latest version until the software detects that the link is up properly. If the link detection in the hardware is being odd, it will pause anywhere up to six seconds, which is probably a bit too conservative. I'll have a look at adjusting it.
  13. Provided it works okay for you, the one not in the Debug folder. The debug version is the same thing but it just prints more log information. The regular one should only print major errors if they occur.
  14. EXPERIMENTAL! UNSTABLE! WARNING! KITTENS! Hi again everybody. After tinkering with updating the AtherosL1cEthernet drivers (http://www.insanelym...ver-for-107108/) I decided to try porting from scratch the newer ALX driver from here: http://www.linuxfoun.../networking/alx Much of what I said in the AtherosL1cEthernet thread also goes for this driver, so please browse over it quickly if you get a chance. While the latest news update on the ALX page suggested they were stripping out support for the earlier drivers, the code for these seems to be still intact in the latest patches so it seemed worth trying to port, especially with many newer motherboard revisions apparently containing the AR8161 chip and causing people much frustration. Once again I've only been able to test this code on my AR8151. There are a lot of rough edges, but "release early, release often" as they say. There are essentially two low-level sections of code, one for the AR81(31/32/51/52) and another for the newer ones. I can't really vouch for the stability of the newer chipset code. Most of the low-level stuff is mostly portable and unmodified from the Linux code though. Wake on LAN/demand works for me so far, but I haven't yet enabled TSO, VLAN and other advanced stuff. For now I'm just attempting to get the basic driver working. Installing: Use your favourite method of adding kexts to /System/Library/Extensions. Personally I prefer doing it manually from the terminal. For testing or reporting bugs, please use the kext in the "Debug" subdirectory. This will output much more info to /var/log/system.log. Remove any old version: sudo rm -rf /System/Library/Extensions/ALXEthernet.kext (Don't forget to also remove any potentially conflicting kexts from the Extensions directory, e.g. AtherosL1cEthernet.kext!) Copy the new version from wherever you extracted it, such as Downloads: sudo cp -r /Users/yourusername/Downloads/ALXEthernet/ALXEthernet.kext /System/Library/Extensions/ Update the kernel cache: sudo touch /System/Library/Extensions Then wait a couple of minutes or so before rebooting. This should trigger kextd to rebuild the cache. (Alternatively you could completely remove the old cache first: sudo rm -rf /System/Library/Caches/com.apple.kext.caches/* But this is best ran from single user mode (-s) where kextd isn't active and watching for changes in the background.) If you find your system becomes unbootable due to panics, the easiest way to fix this is to temporarily disable the ethernet card in the BIOS/UEFI, boot into Mac OS X and then perform the the first and last installation steps above. Alternative (test) install: To avoid breaking your system if the module is installed but panics every time, you can just test by installing to the temporary directory: sudo cp -r /Users/yourusername/Downloads/ALXEthernet/ALXEthernet.ext /tmp/ Then load the module for testing: sudo kextload /tmp/ALXEthernet.kext The contents of /tmp will be automatically wiped upon reboot so you'll have to repeat these two steps each time. Changelog: 1.0.2 - Bug fixes that should help clean up memory allocation problems at boot time (with a little luck). VLAN is now possible for anyone that needs it, but I've only tested it minimally. 1.0.1 - Bug fixes and refinements. Manually setting the link speed should work properly now and might be an option if autonegotiation is causing issues. The link watchdog timer should generally be working better now. Changed some Linux code that was automatically enabling MSI-X interrupts on newer chips. I have no idea if these are supported properly on Mac OS X, but to be safe I'd rather keep everything on plain old MSI for now. 1.0.0 - The initial release. Don't be fooled, it's likely very unstable! Downloads: The zip files are (hopefully) attached to this post. They contain the kext module and the GPL sourcecode. The kext in the "Debug" folder is mostly the same as the regular kext, but prints much more information to the system logs. Latest: 20121117 ALXEthernet-1.0.2.zip MD5 (ALXEthernet-1.0.2.zip) = dbdc587f2b4905515571a7ce2bd55c8f Previous: 20121106 ALXEthernet-1.0.1.zip MD5 (ALXEthernet-1.0.1.zip) = ed621f34f91e60b5422734401b6bdb6e 20121103 ALXEthernet-1.0.0.zip MD5 (ALXEthernet-1.0.0.zip) = 78c0d329237e1ac726bd737493b45724 Like I said in the other thread: I'm just throwing this driver/code out there and seeing what happens. I can't provide serious help or even guarantee a reply if things don't work for anyone. Enjoy and please tell me what card type you have for any feedback if possible! While kernel panics should hopefully not happen if everything is installed correctly, if anybody gets a regular panic and feels up to it then it would be incredibly useful for me if you were to enable verbose mode at boot with the -v flag and snap me a (readable) photograph of the panic screen along with which Mac OS X version they're using (e.g. 10.8.2) along with the driver version used (e.g. 1.0.1). I can then hopefully trace exactly where in the code things are going wrong. Usually these things are from buffer allocations gone horribly wrong.
  15. Thank you for the further feedback, everybody. It's definitely useful for me to know what specific cards are working and what aren't. I've uploaded a new version that should hopefully keep a better eye on the link status and changes to it. It might help with some oddities when the card goes up/down during sleep/wake.