Jump to content


  • Content count

  • Joined

  • Last visited

About lewellyn

  • Rank
    InsanelyMac Protégé
  • Birthday July 17

Contact Methods

  • Website URL

Profile Information

  • Gender
  1. Any status updates on this? It'd certainly be neat to see it when you've gotten it working! (And happy belated birthday to your wife. )
  2. North bridge support!

    Hm... This is what I get... Duchess:~ lewellyn$ ioreg -l|grep 0600 | | | | "class-code" = <01040600> | | | | | "FireWire Device ROM" = <0425c74531333934f800a2420011060000303587000927043800000403000a27810000071700 00a8100000d0c0083c08d000011d1000013d10000150007ac7500000000000000004170706c65204 6f$ | | | | | "IOFWHWAddr" = <00110600003035870a02010000000000> | | | | | "IOMACAddress" = <0011060000303587> | | | | "class-code" = <00040600> | | | | "class-code" = <00040600> | | | | "acpi-reg" = <00600000> | | | | "class-code" = <00040600> | | | | "reg" = <0060000000000000000000000000000000000000> | | | | "class-code" = <00010600> | | | | | | | | | "HIDIdleTime" = 239060004 | | | | "class-code" = <00800600> | | "IOInterruptSpecifiers" = (<0600000000000000>) I'd like to blame it on middle-of-the-night brainfarts. But, I simply pasted the section with the exact match for "060000". And that happened to only be acpi-reg that matched... Does this mean I have no north bridge?
  3. North bridge support!

    Quick question... If there are separate threads for North and South bridges, won't you confuse newbies? And won't info get out of sync? Anyhow, though I can't get my south bridge out of "compatible" mode (see that thread), I seem to not need to modify this Info.plist... | | +-o XVR2@C <class IOPCIDevice, registered, matched, active, busy 0, retain count 9> | | | | { | | | | "device-id" = <e9030000> | | | | "name" = "pci-bridge" | | | | "IOPCIConfigured" = Yes | | | | "#size-cells" = <02000000> | | | | "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/XVR2@c0000" | | | | "IOName" = "pci-bridge" | | | | "vendor-id" = <de100000> | | | | "revision-id" = <a2000000> | | | | "IOPCIResourced" = Yes | | | | "Power Management private data" = "{ this object = 02c8d680, interested driver = 02c8d680, driverDesire = 0, deviceDesire = 0, ourDesiredPowerState = 2, previousRequest = 2 }" | | | | "Power Management protected data" = "{ theNumberOfPowerStates = 3, version 1, power state 0 = { capabilityFlags 00000000, outputPowerCharacter 00000000, inputPowerRequirement 00000000, staticPowe$ | | | | "acpi-reg" = <00600000> | | | | "IOPCIExpressLinkStatus" = 4113 | | | | "IOPCIExpressLinkCapabilities" = 34683921 | | | | "class-code" = <00040600> | | | | "compatible" = <"pci10de,3e9","pciclass,060400"> | | | | "IODTPersist" = <a6e85a2adee85a2a> | | | | "#address-cells" = <03000000> | | | | "reg" = <0060000000000000000000000000000000000000> | | | | "ranges" = <00000082000000000000a0fd00000082000000000000a0fd0000000000001000000000c20000 000000090fd000000c200000000000090fd0000000000001000> | | | | } Or is it possible that I edited the wrong plist (or part of it) earlier? (Again questioning the wisdom of 2 threads…)
  4. South Bridge support

    This sounded like a neat trick, so I added pci10de,3e0 for my nVidia nForce430 board. But, I still get the following: | | | "compatible" = <"pci103c,2a5c","pci10de,3e0","pciclass,060100"> Since you didn't say which of the values should be used, I went with my gut that the 10de value was correct… If my gut's right, we can say that pci10de,3e0 is pointless to add to the plist. (The "name" value backs up my gut…) In case it's useful: | | +-o LEG0@1 <class IOPCIDevice, registered, matched, active, busy 0, retain count 15> | | | { | | | "device-id" = <e0030000> | | | "vendor-id" = <de100000> | | | "IOName" = "pci10de,3e0" | | | "subsystem-vendor-id" = <3c100000> | | | "Power Management protected data" = "{ theNumberOfPowerStates = 3, version 1, power state 0 = { capabilityFlags 00000000, outputPowerCharacter 00000000, inputPowerRequirement 00000000, staticPowe$ | | | "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/LEG0@10000" | | | "acpi-reg" = <00080000> | | | "reg" = <0008000000000000000000000000000000000000> | | | "revision-id" = <a2000000> | | | "IOPCIResourced" = Yes | | | "class-code" = <00010600> | | | "subsystem-id" = <"\*"> | | | "Power Management private data" = "{ this object = 02c46500, interested driver = 02c46500, driverDesire = 0, deviceDesire = 0, ourDesiredPowerState = 2, previousRequest = 2 }" | | | "compatible" = <"pci103c,2a5c","pci10de,3e0","pciclass,060100"> | | | "name" = "pci10de,3e0" | | | }
  5. NForce SATA Controller

    You're seeing similar issues as I reported before... I'm on an nForce 430/MCP 51, so it's doubtful that your MCP 55 is unique here... I ended up simply disabling MeDevil's driver for now. I maybe could live with the SATA being a bit buggy still... But the horrible stability issues on PATA, as well, is sad. Also, I had to physically disconnect power for a few moments, else I'd still get freezes on heavy disk activity. I suspect the driver's setting a bit it ought not be touching, or something similar that doesn't get reset at controller reset (e.g. at POST). *sigh* I wish I had the disposable income for a real Mac...
  6. Ethernet Driver for Marvell 88E1116

    At this moment... "Yes"... None of the nForce networking drivers is yet stable for most people. So, grab yourself an 8139 (or maybe an 8169) and use that. Alternatively, you may have luck using a BCM43xx with the AirPort driver that ships with the OS. (If wireless is your thing, of course!) Keep an eye on these nForce NIC topics, though... There's always a chance that there's something brewing behind the scenes and that we won't know about it till it's time!
  7. NForce SATA Controller

    See, I try hard to not be a dumbass… That's why, for now, I've reverted to AppleVIAATA, until MeDevil wanders back over and can shed some light on this instability. Now that I've tasted what my system's capable of, I want it! So, yeah… My advice? If you're ever experiencing stability issues with a certain kext, and you aren't prepared to deal with disastrous consequences, disable it (and revert to a known-good substitute, if possible) until the maintainer can get a chance to see if they can figure out the problem. It's worse to bork your system trying to "experiment" than to wait for the response of someone who is likely to have an idea as to the cause. And, if anyone ever feels a need to quote that, no need to contact me. Just give some credit.
  8. NForce SATA Controller

    Hm. I can't say I've seen unmounting… The only real problem I'm annoyed with on the SATA side is that my favored DVD burner isn't recognized. (Sometimes I can't even see it in Apple System Profiler. But usually, it's just a matter of the OS not seeing media there… I think…) Hopefully, at some point, MeDevil's going to split the PATA and SATA drivers. As I mentioned when he first mentioned this project in another thread, separate drivers allow "mixing-and-matching" PATA and SATA drivers, so that one can get the "best" performance and stability possible. In this case, I'd love to be able to use whatever my "stock" PATA driver was (or AppleVIAATA, if it'd not be problematic…), and this driver for my SATA drives. For most tasks, I don't care as much about "performance" as long as things aren't heinously slow. Hell, even WinXP runs decently under VMWare Fusion for me (with my crappy video using VESA even!), with AppleVIAATA. However, there's a noted speed difference with MeDevil's driver (on my VMs on an SATA drive, at least). So, I'd love to be able to use it. But, again, I remarked before that though I'm willing to "adopt early", I'll probably have to let others risk data loss. This machine just has too many gigs of data on it. A restore would take ages. So, I'd rather not tempt fate. If anyone has suggestions for how to make the PATA part of this driver "behave", I'd love to test them… MeDevil, what info can I give you to help diagnose this sooner? Thanks.
  9. Linux or *NIX Driver For OSX86

    Well... Unix became "UnixWare" and is at the heart of the famous SCO lawsuit. BSD started off as a variant of Unix, a collection of patches. A "fork", if you will. FreeBSD (and company) derive from the BSD branch of AT&T's UNIX, through 386BSD and 4.4BSD. This makes BSD-based Unix a "hereditary" UNIX. The only widespread "hereditary" UNIX systems in wide use these days would be the various BSDs (including OS X) and Solaris. (Though many others are still used on big boxes!) Linux, on the other hand is a "clone" of UNIX (or more accurately, an implementation of POSIX). Vista's got a fairly complete POSIX subsystem, too, in the Ultimate edition… But the actual heredity of UNIX is irrelevant. The differences between operating systems (from a driver perspective) are in the kernels. It is arguable that you'd get further by taking a device with truly open-source drivers on Windows and FreeBSD and using those as hints for writing an IOKit driver than taking a Linux or Solaris driver and using it. (My understanding, bearing in mind that I'm not a kernel hacker of any repute, is that the NT driver model is somewhat similar to IOKit, in comparison to a Unix or Linux driver model.) But the key is to first learn the development environment, then start worrying how you're going to code the thing. And, in any case, binaries aren't the same across systems (ignoring iBCS and such). So, just as you can't take a Linux binary and run it on your Mac, you can't take a driver (which requires system-level coordination to run) and expect it either.
  10. Ethernet Driver for Marvell 88E1116

    That doesn't help those of us who have a limited number of PCI slots… I have my "Airport" card in one, and my Firewire/USB combo card in the other. And why would I want two perfectly good wired NICs in the same box, anyhow? (Especially when I only have 2 PCI slots! Such a waste of potential!) You'd think I'd be more likely to want to stick one in my old K6-2 box to use as "emergency backup"! This thread is not about Realtek NICs, sorry. Search the forum; there are many threads devoted to your Realtek.
  11. NForce SATA Controller

    Just an update after some more testing... It seems I only get freezes on heavy PATA activity... I can't duplicate it with solely SATA activity. (I have an nForce 430.) And nothing gets logged that I see, making it hard to determine just why it's freezing. Possibly as my logs are on the PATA drive... For now, I've reverted to AppleVIAATA.kext, for stability. But, wow is it slow in comparison! I didn't notice the speed bump (even for PATA) when changing to your driver, MeDevil, but I certainly notice the loss! Again, if there's anything I can do to help debug, please let me know!
  12. Linux or *NIX Driver For OSX86

    Megamixman, BSD isn't "like UNIX", it is UNIX. (Just like OS X, Solaris, AIX, UnixWare, and many others…) Linux is not a UNIX. Some day, it may actually apply for UNIX certification, but there be dragons there! Ecrid, on Windows, the different kernels used require different drivers, as well... For example, you can't stick a Windows 3.1 video driver on Vista. Heck, I don't think even a Windows 2000 driver would work! For Windows, there are 3 major kernel "families": Win 3.x (we'll sweep 1.x and 2.x under the rug for this, since even 3.x is ancient history), 4.x (aka "9x"), and NT (NT 3.1-Vista). It's just the long lifetime of each OS version that keeps the driver writers supporting the appropriate systems indefinitely, and transparently… If you're really thinking of tackling the task of writing a driver, first get comfortable in Xcode. It's different from most other IDEs (unless you developed on a NeXT in the past, maybe…), so if you have issues getting simple stuff working, writing a driver is going to be impossible. After you've gotten the hang of general tasks in Xcode, grab the Darwin source code (OS X is essentially a BSD called "Darwin", plus fancy graphics stuff). Then, sit down with the ADC IOKit docs and the Darwin sources and see how the drivers "tick". Maybe make some simple modifications to add debugging to a driver you use often (maybe USB?). Once you get the hang of that, then you'll probably have an idea of what lies ahead for writing from scratch. And, keep in mind licensing when you write your driver! If your driver's going to be non-GPL licensed, you can't even look at the source to the Linux driver. (This is called "tainted code", when you violate licensing.) However, if you come up with a new and novel driver that may get you fame, fortune, and a place at a major corporation, you may find that something like a BSD license is appropriate, as it allows binaries to be distributed without their sources. And, if you think your code's just hideous, you can always say "here's the .kext, the source is mine"! But just remember to not taint your code. I'd hate for someone to get upset at you and sic their lawyers upon you! (I think the GPL is now considered "legally enforceable"…) I wish you the best of luck in your adventures! And, it seems that some of the prominent members of this community are quite willing to lend a helping hand if you've proven that you're on the right track. So, don't get too discouraged if you make it through modifying a driver, but have issues with writing your own!
  13. Linux or *NIX Driver For OSX86

    (Long post. Short answer at end. Reading it may be edifying, however. Note that there are gross over-simplifications and terrible analogies in this post. It is hoped that these will introduce the concepts without misinforming the reader. This post will not get into licensing issues. ) At first blush, you'd think "UNIX is UNIX". But, that doesn't mean binary compatibility. Not even source code compatibility, really. (Especially in the case of wannabe-UNIX. i.e. Linux.) Though there have been attempts to standardize running applications across different UNIX platforms, this proved difficult enough (technically and politically) that there were never any successful attempts that I know of to try this on a kernel driver level. See also: What is UNIX? If you could simply take your FreeBSD driver and drop it into your OS X box to make it recognize some nifty new piece of hardware, life would be both easier and harder. It'd be easier on everyone as you'd have "write-once-run-anywhere": the Holy Grail of computing. But, it'd be harder on everyone as: 1) Bug hunting would be more difficult; 2) who do you blame when a driver fails on just one UNIX?; 3) there'd have to be a standardized kernel module interface. Points 1 and 2 seem obvious enough, so I'll skip them. 3, however, may require a bit of thought. Newcomers to the land of UNIX are inundated with a battlefield of Holy Wars. The first many come across is KDE vs GNOME (vs CDE vs XFCE vs twm vs olwm vs …), followed by vi vs emacs, C vs C++, Python vs Perl, wxWindows vs QT vs GTK, and so on… (Is lp vs CUPS dead yet? How about NFS vs Samba? I think big-endian vs little-endian's dead for most users now, right?) Luckily, on a Mac, most of these holy wars have been decided for you (but that doesn't stop them from being resurrected; it's more like an imposed cease-fire…). There's another holy war that many people are happily oblivious to, but is at the heart of Linux's history: monolithic kernel vs microkernel. If you're curious as to how such an "obscure" thing is at the heart of Linux (note that I do NOT mean "GNU/Linux" here; read on and you'll see another mention of GNU!), you will want to research the history of Minix and Linux. The subject is also a key piece of Apple's OS history, but that's a lengthy post in itself! First off, what, exactly, is a kernel? Well, at its core, it's the "actual" operating system. Think of it as the coach of a sports team, the successful hands-on CEO of a company, or something similar. It is, essentially, what makes the system boot and work. OK. What's a microkernel then? It sounds small, so it must be the easier one to explain! Well, essentially, a microkernel is a program which (ideally) only provides "interfaces" or "services" to allow other programs ("drivers") to do the heavy lifting. It sits back and allows things to talk to each other and manages memory. Probably reminds you of the stereotypical union job-site foreman: Paid handsomely and doesn't visibly work; but his absence will make everything halt. The microkernel evolved from the natural growth of UNIX and the need for security and easy code management. (Though, most microkernels aren't used for UNIX systems. The most notable currently-used microkernels are probably the ones in OS X, QNX, GNU/Hurd, and Minix. Think of it as "learning from others' mistakes". ) While it's possible to bring down a microkernel, ideally you only lose the offending driver. (Ever had a device just "stop working" on Windows or OS X, which was fixed by a reboot and never happened again? Good chance the driver crashed. On Linux or *BSD, there's a good chance another driver would have been corrupted in that case, and you would have had a crash or, at best, a need to reboot immediately.) So, what's a monolithic kernel? Well, if a microkernel's a jobsite foreman, a monolithic kernel's a schoolyard. It's big, everything can trample all about (though there's usually someone/something trying to keep order!), and if one thing fails, chaos can ensue. (Remember how the whole schoolyard rushed to the scene of a fight, and how the "adults" had a hard time working their way into the crowd to take control? Well, a driver crash can cause a deadlock in a monolithic kernel far more easily than in the average microkernel.) Also, in a monolithic kernel, the drivers "share" their address space. And, again, when kids "share" things, if one's sick, they all can get sick and quickly! However, it's not all bad. Things tend to "just work", and everything just gets along. But the "kernel" in this case comprises the schoolyard and everything on it, as opposed to "just" the foreman of a jobsite. (To keep the analogies straight.) (There are other types of kernels, such as a "hybrid" kernel as utilized by NT, and exokernels, but for the purposes of this post, they're easily swept into the "microkernel" category.) Now that we know WHAT a microkernel and a monolithic kernel are, why do we care? Well, most obviously, they stem from hugely different design ideas. There's no way that one can generally just take the source code from a monolithic kernel and drop it into a microkernel (or vice versa), without heavy modification. Even between microkernels, this can be a challenge, as while they may share design philosophies, the methods used can differ wildly. Certainly, there are many drivers which have been ported between Linux and BSD (BSD is a monolithic kernel, like Linux). But even these ports aren't necessarily "easy". Now, imagine having to do the same across totally different design philosophies. And this is why we care: OS X is a microkernel. In most cases, the best you can do is "crib" what the existing driver is doing, and implement it yourself. Needless to say, in most cases, if you have access to specifications, you can probably implement a driver faster from scratch than trying to take one from a totally foreign operating system. (Even if they're both "UNIX".) Sadly, most devices don't have publicly available specifications. So, driver writers for open-source drivers are forced to use trial-and-error, crib how similar drivers do things (on the same OS and on others), and bang their heads on their desks over and over. A notable example is nForce ethernet. There are currently 2 (that I know of) semi-active attempts to write a "working" driver for this beast. Both attempts are "semi-working" for most users, "fully working" for very few, and don't "work" for quite a number. Both attempts also attempt to re-use existing code (both use "forcedeth", at least its framework). And even with this re-use, there has been much need for original code to be created. Hopefully, one or both will eventually be "done", and then they, ideally, could themselves be used as "frameworks" for other ethernet drivers, speeding up other "ports". So, long answer short: "No, you can't use drivers from other operating systems. Sorry." P.S. I was going to use a schoolbus analogy instead of a schoolyard analogy. But I thought that having the bus drive off a cliff may not go over well...
  14. NForce SATA Controller

    Hm... Due to no confirmation otherwise, I disabled AppleVIAATA... If I'm actually able to continue using both to somehow solve my current issues (SATA DVD burner doesn't burn when recognized by MeDevil's driver; isn't recognized 3 out of 4 boots, it seems. Also, hangs during heavy disk I/O in Q and VMWare Fusion, with VM hosted on HFS or FAT volume [not ballsy enough to try NTFS…]; issue more prevalant with XP than Me or Slackware 12.), I'll be quite happy. I'm half-tempted to move back to AppleVIAATA for now, as it was at least stable (if slow). This system is soooo close to being a good, CHEAP, reliable "poor man's Mac". (This is OT, so if the thread starts migrating, please split it off to its own thread somewhere or something.) Unfortunately, every day I start thinking that I should have purchased a Mac Mini. Anyone tried Boot Camp with a slew of OSes on an external drive? (My GRUB will boot, at this moment: OS X, 2 installs of Vista, QNX, DOS, Linux, Solaris.) Or, is there a "better way" of doing something similar on a real Mac? (There are limits to virtualization…) Feel free to PM.
  15. NForce SATA Controller

    Oooohhh.... MeDevil.... I spoke too soon about things working great! Turns out that extremely heavy disk I/O seems to be locking my box. Nothing's logged, and there's no disk "noise". Seconds don't tick on the clock, and the mouse pointer doesn't move... You're probably wondering what I was doing. Well, I was trying to compile a fairly sizeable project in Visual Studio under Windows XP in VMWare Fusion, while updating some packages under Slackware in Q. If that's not a stress test, I don't know what is. At this point, I'm torn. I can always reboot into Vista (natively) to compile. It's almost faster than the AppleVIAATA.kext performing the compile... Or, I can swap SATA drivers when I need heavy I/O... Or I could ask you if there's a way to make it spew a bit more debugging data (and probably disable any caching, so that everything is write-through, so that hopefully the last messages get seen)... Or I could try to poke at the driver to fix it myself. The last option scares me. While I'm comfortable with Xcode, I'm not comfortable with potentially destroying all my partitions. Rebooting just to compile seems silly, but rebooting to change SATA drivers is equally silly. So, is there a way to disable any caching whatsoever on all drives (I boot off PATA, if it matters), and spew more debugging info? Alternatively, is there a way to post-mortem debug such an issue?