In case you ever wondered what it takes to convert a "simple" GLDv2 driver to Nemo, have a look at the webrev I posted earlier today.
I'm hoping that this work will get integrated soon. As an upshot, dmfe with this change "just works" with dladm show-dev.
Wednesday, April 18, 2007
report from the battery team
I'm now a member of the "battery team". I had a very productive con-call with the folks involved, and I think we are going to soon have a better common framework for battery APIs in the kernel so that SPARC systems can also take advantage of the gnome battery applet. Watch this space!
afe integration web rev posted
For the curious, I've posted a webrev containing the changes required to integrate afe into Nevada.
The driver includes changes from the stock AFE driver for Solaris, including some lint fixes, and changes to use the stock Solaris sys/miireg.h.
I'd love to make more changes to this driver, but at the moment I don't want to cause a test reset. Once the driver is integrated, I have a bunch more improvements coming... Nemo, multiple mac address support, VLAN support, link notification support (needed for NWAM), as well as code reduction by using some features that are now part of stock Solaris (like the common MII framework!)
The driver includes changes from the stock AFE driver for Solaris, including some lint fixes, and changes to use the stock Solaris sys/miireg.h.
I'd love to make more changes to this driver, but at the moment I don't want to cause a test reset. Once the driver is integrated, I have a bunch more improvements coming... Nemo, multiple mac address support, VLAN support, link notification support (needed for NWAM), as well as code reduction by using some features that are now part of stock Solaris (like the common MII framework!)
Thursday, April 12, 2007
Tadpole SPARCLE support putback
Core support for SPARCLE was just putback! I'm getting ready to post an initial tadpmu for public review soon, as well. This should make you SPARCLE/Sun Ultra 3 owners out there happy.
Wednesday, April 11, 2007
Not All Broadcom GigE's are Equal
Recently, I posted a blog entry where I described that "Not All GigE Are Equal", strongly advocating the use of Broadcom GigE devices when faced with a choice.
However, after spending time in the code, I've discovered that there is quite a range of differences amongst Broadcom gigE devices.
I had considered listing a full table of them, but it seems that would be a bit onerous. Take a look at usr/src/uts/common/io/bge/bge_chip2.c if you want to find out the gory details. But in the mean time, here are my recommendations:
If you have PCI or PCI-X: Choose a bcm5704 if you can. It has pretty much full feature support, but you need to pick a recent revision (newer than A0.) Look for pci ids of pci14e4,1646, pci14e4,16a8, or pci14e4,1649. These chips alls support PCI-X, multiple rings, full checksum offload, and multiple hardware tx and rx rings.
If you have PCIe: As far as I can tell, all of the PCIe chips that are Solaris supported lack support for multiple hardware tx/rx rings. This is really unfortunate, as it will have a negative impact on Crossbow benefits. But apart from that, it looks like the 5714 and 5714 series are your best bet. They both support jumbo frames, and they both have full checksum offload support. Look for pci ids of pci14e4,1668, pci14e4,1669, pci14e4,1678, or pci14e4,1679.
What this really says, is if you have to choose between a PCI-X card and a PCIe card, surprisingly, choose the PCI-X card (if you can get a 5704). Save your PCIe for framebuffers or HBAs. (Or, better, 10G cards like Neptune.)
However, after spending time in the code, I've discovered that there is quite a range of differences amongst Broadcom gigE devices.
I had considered listing a full table of them, but it seems that would be a bit onerous. Take a look at usr/src/uts/common/io/bge/bge_chip2.c if you want to find out the gory details. But in the mean time, here are my recommendations:
If you have PCI or PCI-X: Choose a bcm5704 if you can. It has pretty much full feature support, but you need to pick a recent revision (newer than A0.) Look for pci ids of pci14e4,1646, pci14e4,16a8, or pci14e4,1649. These chips alls support PCI-X, multiple rings, full checksum offload, and multiple hardware tx and rx rings.
If you have PCIe: As far as I can tell, all of the PCIe chips that are Solaris supported lack support for multiple hardware tx/rx rings. This is really unfortunate, as it will have a negative impact on Crossbow benefits. But apart from that, it looks like the 5714 and 5714 series are your best bet. They both support jumbo frames, and they both have full checksum offload support. Look for pci ids of pci14e4,1668, pci14e4,1669, pci14e4,1678, or pci14e4,1679.
What this really says, is if you have to choose between a PCI-X card and a PCIe card, surprisingly, choose the PCI-X card (if you can get a 5704). Save your PCIe for framebuffers or HBAs. (Or, better, 10G cards like Neptune.)
blogger Atom bugs
As part of setting up the Tadpole project, I tried to use a feed direct from Blogger, but the OpenSolaris tonic infrastructure doesn't like it. Apparently the feed has some problems, which you can see by looking at the output from feedvalidator. Anyway, I was able to work around by using feedburner to convert the blogger Atom feed into a clean RSS feed. Maybe at some point some Blogger staff will look at this and see what the problem is.
hackergotchi... thanks Gman!
Gman (Glynn) made a hackergotchi from a photo I sent him, which is used on planet.opensolaris.org. His gimp-fu is great. Thanks Gman!
Subscribe to:
Posts (Atom)