Posts Tagged ‘drivers’

Hackintosh, Networking updates

Thursday, March 24th, 2011

I’ve made a few sporadic updates to my Hackintosh, so I thought I’d share them here.

First, the update to 10.6.7 went smoothly, as anticipated.

Second, I put in wired networking in my house, so I needed a wired-NIC solution. (I had been using wireless). I also needed something better than 100mbit, because that was a big motivator of bothering to put in wired networking in the first place. After enabling the onboard realtek gigabit NIC in my BIOS, it “just worked” in macos using built-in drivers. (Remember, I have a patched DSDT). However, realtek nics are less than stellar performers and are not that reliable. I could never get more than 750 mbit/s with it, and it would periodically just go down — this happened in both MacOS and Windows. Resetting the driver wouldn’t work. I’d have to reboot the machine. This is actually somewhat common with realtek hardware because of their crappy heavily MMIO-based interface — too many MMIOs in a short period of time and the state machine in the NIC’s firmware gets wedged (because some portions of the state machine do not have positive acknowledgement that they’ve completed – you do step A, then B, then C from the driver), and that’s it, you’re done.

So, I looked for an add-in card. I have a BCM5721 gigabit NIC, but I could not get this to work with stock drivers. I’d read people had success copying drivers from old MacOS builds, but I wanted to avoid this path because it could get killed in any subsequent update, and I’d have to redo it. There were multiple problems here. First, the driver attempts to enable wake-on-lan, and it fails given my system + hackintosh’s acpi information. However, you can disable wake-on-lan in the driver’s Info.plist. (this setting *is* sticky across most updates, btw). Even doing that, however, I couldn’t get the driver up. After a great deal of debugging (and playing with writing my own driver, which I discovered others had started on as well), I found that basically the stock driver isn’t handling message-signaled interrupts (MSIs) correctly. Likely Apple does not have this hardware installed on any systems that use MSI, or for those that do, the default interrupt vector is the correct one. I considered either modifying other drivers or writing my own, but at this point, I’d already spent a lot of time on this problem.

So, I took a gamble on a Marvell-based gigabit NIC. I bought a Rosewill RC-401-EX from Newegg for $23. And, I’m happy to report that it works out-of-the-box, with stock drivers. (No modified plists, nothing). I get line-rate with it (~940mbit/s using TCP netperf), and I have yet to have the interface wedge on me. It’s a great solution to this sort of problem, if you run in to it.

DSDT and kext information for my Hackintosh

Wednesday, May 5th, 2010

As previously mentioned, I’ve built a hackintosh using a Gigabyte GA-X58A-UD5 motherboard (with the F4 bios), an i7 950 processor, and an nvidia GTX 260 graphics card.  The information one might need to get Empire EFI/Chameleon RC4 booting this machine is present in that other post.  However, a few people have asked for my DSDT information, so here are the diffs to the the disassembled dsdt.  As previously mentioned, I simply followed the guidelines here and adapted them to my DSDT.  Note that there is processor-specific information here regarding power states (in this case, for my i7 950).  To use this, you just need your disassembled dsdt file (called dsdt.dsl), which you can get by first getting the compiled version (I used an Ubuntu Live CD) and disassembling it (using iasl — again, I used Ubuntu).  With your disassembled DSDT and this diff, simply do:

patch -p0 < dsdt.dsl.diff

And then recompile doing:

iasl -sa dsdt.dsl

which will create a “dsdt.aml” file suitable for various PC EFI projects (including Chameleon RC4).

Using this, I don’t need a null power kext or any modified power management kext.  Stock Apple power-management kexts just work.  What doesn’t work:  sleep.  Apparently other people have used some sleep enabler kext to get this to work, but I haven’t tried that, since I don’t need it.  What also doesn’t work without a driver:  sound.  Also, as a reminder, I’m using the 32-bit kernel.  And to summarize, (native) SATA (without IDE emulation), USB, firewire, and graphics all just work (using GraphicsEnabler=Y, PciRoot=1) w/ Chameleon RC4.  Without a kext fix, however, the hard disk icons are the orange external ones.  There are several methods to fixing this.  The machine will shut down, but not reboot.  So, I also use a snow-leopard compatible OpenHaltRestart.

So, the drivers (kexts) I use are:

VoodooHDA (for sound)

Fake SMC 2.5 (platform workarounds to make the sucker boot – I had to install this on my System partition rather than in Chameleon’s Extra folder.  It wouldn’t work otherwise, for me)

IOACHIBlockStorageInjector (Just to make the hard-drive icons gray rather than the orange external ones)

OpenHaltRestart for 10.6 — I can’t find the source for this right now, and I’m not hosting kexts on my blog.  The version for 10.5 will not work – I see several different options over at insanelymac.com, so have a look over there if you need this.  As I recall, shutdown would work, but reboot would not.

Before you ask, no, I will not provide the compiled version of my DSDT.  The diffs are more useful for you because you can use them to generate a new DSDT against newer BIOS revisions or against slightly different motherboards.  (People inexplicably mix & match DSDTs that aren’t for their motherboard — if/when this works, it’s purely accidental).  If you’re mucking around with a Hackintosh, you ought to be able to boot an Ubuntu Live CD, follow some simple commands, and apply a patch.

New-computer choices

Monday, September 28th, 2009

My 2006 Core 2 Duo iMac is showing its age a bit (well, compared to Nehalem-class hardware), and I’m wanting to get a new computer, but the choices here are not easy.  My requirements for my primary operating system are:

  1. Must support an Exchange 2007 client
  2. Must support my work VPN
  3. Must be reliable

For now, #1 whittles things down to either Windows or MacOS.  (I’ve used wine to run outlook.  It crashes randomly).  If an open-source Exchange 2007 client comes about soon (it may be possible considering ongoing interoperability legal action in Europe, and I’ve read rumors of a Google-developed library), this might no longer be true.  Both Windows and MacOS support my VPN, so that’s a nonissue.  Reliability is the remaining issue.  At work, my desktop is Windows, and for the most part, it works.  That said, every now & then I have to waste about 2 hours out of my day with some bullshit issue (updates stop working, networking goes batty, stuff like that), and my time is valuable.  2 hours of time at home is 2 hours not spent with my family, or not regrouping after a day at work, or possibly 2 hours not working when I need to be.  Hence, I’m strongly leaning toward a new Mac, but the only hardware I’m remotely interested in right now is a Mac Pro, which costs more than $1000 more than a Dell of equivalent class.  (Yeah yeah, they use Xeons versus regular Core i7s.  I’ve seen the benchmarks.  BFD).  Even so, it might be worth it, but this is a tough choice to make — if only Apple had the mythical midrange tower (the laptop-component-featuring iMac does not count).  I may be going back to running Windows primarily at home, and I’m not too thrilled about that.

Microsoft and the GPL

Thursday, July 23rd, 2009

Microsoft recently released several paravirtualization drivers under the GPL (version 2).  People are making way too big of a deal about this.  (I suppose that’s to be expected from “Linux Magazine”).  There are two primary reasons that Microsoft chose the GPL:  maintenance of their own code, and proliferation.  This is not an attack on Linux.  This is not a trick on the GPL.  This is not Microsoft experimenting with Linux.  This is not a patch to the Linux kernel.  (“Linux Magazine”, indeed).  Modules are not the kernel proper, people!  My nVidia driver is no more “a kernel patch” than are Microsoft’s paravirt drivers.  The difference is that Microsoft’s drivers will ship with the overall kernel tree and get built with it, but so do drivers for arcane capture cards from 1994.

This is a practical move given the realities of how Linux is structured and distributed, and it’s comical (if not annoying) to see people who are supposedly Linux advocates completely misunderstand and mischaracterize what’s going on.  Look, the way the Linux kernel is structured, almost all useful APIs are exported ONLY to GPL-declared code.  That means if Microsoft was to declare its module as any other license, it could not use a ton of high-level APIs, including basic stuff like, say, the entire devfs API or any of the IOMMU APIs. There are numerous other examples.  This means that Microsoft would be forced to implement their own versions of these APIs, based on low-level constructs in the kernel that are subject to frequent change.  This is a maintenance nightmare, and Microsoft would have to be insane to pursue this strategy.

The other major reason to use the GPL for their drivers is that, without it, Microsoft’s drivers won’t ship with the base Linux kernel + drivers distribution.  Microsoft wants to get these drivers out to as many people as possible so that Hyper-V’s paravirtualized features “just work” with as many Linux installations as possible.  This move by them increases those odds, so it’s a smart business decision.  It’s no different than Intel wanting their drivers to ship with the kernel.

I understand that Linux enthusiasts are (justifiably) leery of Microsoft, but making up crazy theories does not exactly make you look like a rational, reasoned critic.  Rather, it makes it easier for Microsoft to publicly discount any and all claims that the Linux community may ever have regarding Microsoft’s tactics, because they can point to previous nutty behavior.  Acting “shocked” that Microsoft would pursue its business interests is the juvenile equivalent of rolling one’s eyes.  And, claiming (even in jest) that this is a first step to Microsoft using a Linux kernel inside a Microsoft product does, indeed, count as nutty.  I’m reading this crap all over the Internet — it’s not funny, it’s not clever, and it makes OSS people look like idiots.