All these nics...

So I need to JumpStart a new system today... no problem, I'll just stick in a NIC and boot it with my etherboot PXE CDROM. No problem, right?

Well, lets see, first I need a NIC that supports Solaris. Inventorying what I have in my spare hardware today:
  • Netgear GA311, rev A1 (RealTek 8169S-32, unsupported variant of rge)
  • Netgear FA311, rev C1 (Nat-Semi DP83815D, unsupported)
  • Netgear FA310TX, rev-D2 (Lite-On LC82C169, unsupported, see below)
  • 3Com 3CR990 TX-97 (unsupported)
  • D-Link 530TX rev A-1 (dmfe, no x86 support)
  • Zyxel gigE (Via GbE chip, uncertain)
  • Linksys LNE100TX v4.1 (unsupported, yet, see below)
  • Linksys NC100 (unsupported, yet, see below)
  • Macronix MX98715AEC (unsupported, yet, see below)
  • Unbranded RTL8139B (supported, rtls, nevada only)
  • 3Com 3C900-TX (supported, elxl, for now)
Well, at least I was able to find something. Of my 8 spare NICs, two of them have marginal support. (This is only the wired ethernet NICs. I have some WLAN devices as well.)

I guess I have a habit of collecting NICs.

Now, the Linksys boards are going to soon be supported by afe, if Alan ever gets his putback of my driver done. The Macronix board will be supported by mxfe later this week, once I get it reviewed and putback.

At one point I had a driver (pnic) sort of working for the LC82C169 (Lite-On PNIC), but I abandoned it because the PNIC was such a piece of crap, that I figured anyone with one of these was better off throwing it away and replacing it with another NIC (as long as it wasn't a Realtek 8139!) Maybe I'll revive that project one day. Probably not, since Lite-On didn't sell too many of them, I think. (The PNIC has some horrible hardware bugs, and the two major revisions, the 82C169 and 82C168, have quite different methods of handling 802.3u autonegotiation.)

I also started a driver for the Nat-Semi chip (nsfe), but abandoned it. I think this chip is also found in motherboards, where it is called an SiS part. I think Muryama also has a driver available for it.

I'd really like to see support for the others expanded upon. Maybe I need to look at dmfe, some more, because there really shouldn't be any reason it couldn't support x86 platforms. (D-Link sold a lot of DFE-530TX boads, IIRC.)

This also suggests that the elxl driver, which has been slated for EOF, really shouldn't be. One of the reasons I've kept that old NIC around was just because it was one of the few that was supported by Solaris 8 and earlier. I suspect I'm not the only one to have done this. I think the problem is that this driver is not open source. But open source variants exist... maybe someone should look at replacing elxl in Solaris Nevada with a FOSS replacment.

Some of these Muryama has already written drivers for. I would dearly like to see his vel in Solaris Nevada, along with conversion to GLDv3.

Comments

Christopher Frost said…
Sounds a lot like my old "thing" with video cards.. I took a look one day and ended up throwing out a dozen or so. Of course the GPU timeline is chugging along a lot faster then the NIC parade..
Who knows, maybe someday you will have a few minutes that you don't know what to do with, and convert them all to GLDv3. :p
May 25, 2007 at 12:03 PM
Anonymous said…
I agree with you wholeheartedly. I still see a lot of comments from people claiming that Solaris/x86 has bad hardware support. I'm not convinced that it does -- it's just that the necessary drivers aren't part of the base install (or that /etc/driver_aliases is missing pci ids, but that's a seperate issue).

I was very glad to see that Sun is going to merge the afe and dmfe drivers. And, yes, Sun shouldn't EOL the elxl driver. There are a ton of old 3Com 3C905's out there!
May 25, 2007 at 12:28 PM
Unknown said…
I hope elxl is not EOF'd anytime soon.

Sun is not 'merging' dmfe and afe. Rather, afe is going to get included in Solaris. It will still be a separate driver from dmfe.

Additionally, my own mxfe driver has been approved by PSARC. I still have to get past the other teams, but I don't see any stoppers for it. I'll post a codereview shortly.
May 25, 2007 at 1:32 PM
Anonymous said…
By "merge" I meant include them in ON. Sorry for the confusion.
May 27, 2007 at 6:13 AM
Post a Comment

Popular posts from this blog

An important milestone

Yesterday, with very little fanfare, illumos passed an important milestone. This milestone was the integration of  195 Need replacement for nfs/lockd+klm This is work that I originally tasked Gordon Ross and Dan Kruchinin to work while we were colleagues at  Nexenta .  Gordon started the work, picking up bits from FreeBSD as a starting point and gluing it to the illumos entry points.  Dan continued with it, and fleshed out a lot of the skeleton that Gordon had started.  It was subsequently picked up by the engineers at Delphix , and -- after some important bug fixing work was completed -- was integrated into their product quite some time ago -- reportedly its been stable since December in their product. The reason this is such an important milestone, is two fold: First, this represents a substantial collaborative effort, involving contributions from parties across several organizational boundaries.  The level of collaboration achieved here is a w...
Read more

GNU grep - A Cautionary Tale About GPLv3

My company, DEY Storage Systems , is in the process of creating a new product around the illumos operating system.  As you might imagine, this product includes a variety of open and proprietary source code.  The product itself is not delivered as a separate executable, but as a complete product.  We don't permit our customers to crack it open, both from the sense of protecting our IP, but also to protect our support and release engineering organizations -- our software releases consist only of a single file and we don't supply tools or source for other parties to modify that file. One of the pieces that we wanted to integrate into the tree is an excellent little piece of software called Zookeeper , produced by the Apache organization.  Like illumos, Zookeeper has a nice non-viral copyleft license, which makes it nice for integration into our product. However, I discovered that as part of our integration, one of my engineers had decided to integrate GNU grep. ...
Read more

The Hand May Be Forced

Well, as you may have read , Oracle has decided that at some point very soon, we're going to lose normal regular access to the source code for OS/Net. (I.e. the Solaris kernel and supporting programs.) While I would have vastly preferred for Illumos to have a cooperative and collaborative relationship with Oracle , it appears that Oracle doesn't value this. In fact, the exact words were from the management at Oracle were as follows: Solaris is not something we outsource to others, it is not the assembly of someone else’s technology, and it is not a sustaining-only product. While I understand the need to own the technology, there are few things that could be stated that show a stronger NIH attitude than this. Its unlikely that there will ever be a way for Oracle and the greater community to have a collaborative relationship. This is a dark day for OpenSolaris -- its effectively dead now. (Its parent, Solaris, lives on however.) How unfortunate. For Oracle that is. Because...
Read more