/dev/dump

Trying to build the latest tree, I ran into the problem that my build machine is downrev (its b74.) So I had to update to 77 to get the latest tree to build. For any other OS, or in past days for Solaris, this would be a major crisis, incurring numerous hours of downtime. (Or I could use bfu.) But I decided to finally try out live upgrade. I had an ISO image of b77 stored on a local zfs filesystem (along with all my critical data). When I had installed this system, I had set it up with a spare empty slice matching the / slice in size, in anticipation of one day trying out live upgrade. Boy am I glad I did. All I had to do was a few commands: # lucreate -n b77 -m /:/dev/dsk/c1t0d0s3:ufs (Wait about 20 minutes.) # lofiadm -a /data/isos/sol-nv-b77-sx86.iso # mount -F hsfs -o ro /dev/lofi/1 /mnt # luupgrade -u -n b77 -s /mnt (Wait another 20-30 minutes.) # luactivate b77 # init 6 (That last step confused me. I tried "reboot" a few times, before I actually read the output fr...

With the putback of this: 6404761 nge driver need to be opensourced The nvidia gigE driver is now open source! Yay!

I just got an e-mail from our contact at Intel, and it looks like the main part of the review required to get iprb approved for release as open source has been done. There are still a few i's to dot and t's to cross, but basically, it looks like we should be good to have this open sourced within the next couple of weeks. Watch this space.

This is hilarious, if not poignant: http://www.youtube.com/watch?v=_y36fG2Oba0

I've posted the webrev for the dnet suspend/resume conversion that I did for the 2007 OpenSolaris Developer Summit. Have a look. An audio recording (MP3, 12M) of the presentation for those who weren't available to attend is available here .

So I recently was informed that Sr. management has directed my team to move some of the engineering work that we have been doing "internally" to the OpenSolaris web site. This is more than just moving internal web pages outside the firewall, though. This is about starting to do the actual engineering work in the open. The first two projects that my group is going to be doing this with are the laptop suspend/resume effort and the SD card stack. (The SD card stack needs to go through some licensing approval first, as the SDA organization doesn't allow for redistribution without a license. The "open" specs are "Evaluation Only" apparently. Anyway, this is a sign that the practices already being done elsewhere in the company (cf. the networking group) are starting to take hold elsewhere, even in demesnes that have historically been strongholds of the NDA. Watch the laptop project page at os.o over the next week or so to see what we put up there... and ...

I recently checked our pool contractor's website, and found my backyard in his gallery. It looks pretty cool on his website. Check it out here .

I just fixed a bunch of dmfe changes... most notably, the driver will now support add-in PCI cards. Look for it in snv76.

So I've been tasked with writing a driver for the SecureDigital controller found on certain laptops. As part of this effort, I'd like to take a straw poll. If you could e-mail or post a comment on this blog, indicating your response, I'd be grateful. Note that this is only for folks with card readers that are *not* USB connected. (USB readers are already covered by USB mass storage.) a) how many SDcard slots do you have? b) do you use older MMC media? c) do you have any SDIO peripherals? (I.e. devices other than memory cards.) d) do you have slots other than SDcard (such as xD or memstick) that are important to you? Which ones? (Again, not for USB connected media readers!) e) I'm interested in prtconf -vp output for different readers. If you're game, send it to me, along with the make and model of your laptop. Thanks!

I've got a dmfe driver working on both SPARC and x86, and it supports some unbundled PCI NICs. (The original driver only worked with onboard dm9102s on certain SPARC hardware.) The Davicom 9102 part is not terribly common, but some low end NICs sold by companies like C/Net and Buffalo use it. Hopefully this will be putback into snv75.

I lied... (not intentionally, I got confused.) The qfe GLDv3 port is in b74, not b73. Sorry!

Solaris Nevada b73, when it comes out, is going to have a lot of good NIC stuff in it. * afe driver (putback yesterday) * mxfe driver * rtls on SPARC (including suspend/resume!) * qfe GLDv3 support Plus, there are a lot of good networking improvements; a lot of stale code was removed (defunct mobile IPv4 support, detangling NAT, etc.) There's a bunch of carryover from snv_70-72 too... I for one, can hardly wait.

FYI, I've submitted earlier today the RTI for mxfe. I expect afe (which will be more popular) will be later this week or early next. (We've fallen behind on some of the testing.) I've also started looking at porting rtls to SPARC, and making it support SUSPEND/RESUME. More on that shortly.

And now rtls is GLDv3. Not open source (yet), and no SPARC support, but hopefully those will both get fixed soon. Have fun!

As my first gift to the community since becoming a Sun employee, I've putback the conversion of QFE to the new hme common GLDv3 code. Now you can use your old QFE boards with IP instances, VLANs, whatever. Go wild. Hopefully the rtls conversion will get putback tonight as well... still waiting for my RTI advocate to approve it.

I've recently hacked up the Realtek driver (rtls) to support GLDv3. Its part of usr/closed right now (though I hope we can open source it!), so I can only share binaries. Anyway, if you're stuck with this driver on your x86 system (because its on your motherboard, usually), and you want to try running a GLDv3 version of the driver, let me know. The GLDv3 brings link aggregation support, VLAN support, and virtualization (IP instances) with it. Of course the hardware is still somewhat crummy, so I wouldn't expect to get much performance out of it. But again, if you're stuck with it (as many people probably are) this may be helpful.

For those not in the know, its now official. I'll be (re-)joining Sun as a regular full time employee starting August 20th. That means that I get to drop the "C" in front of my employee ID. I'll be reporting to Neal Pollack, initially working on various Intel related Solaris projects.

(This blog is as much for the benefit for other FOSS developers as it is for OpenSolaris.) Please have a look at 6587116, which points out a hardware limitation in the hme chipset. I've found that at least NetBSD, and probably also Linux, suffer in that they expect the chip to support hardware checksum offload. However, if the packet is less than 64-bytes (not including FCS), the hardware IP checksum engine will fail. This means all packets that get padded, and even some that are otherwise legal (not needing padding) will not be checksummed properly. For these packets, software checksum must be used.

As a result of investigation of a fix for 6587116 (a bug in HME, more later), we have found a gaping bug in the implementation of UDP checksums on Solaris. Most particularly, it appears that UDP hardware checksum offload is broken for the cases where the checksum calculation will result in a 16-bit value of 0. Most protocols (TCP, ICMP, etc.) specify that the value 0 be used for the checksum in this case. UDP, however, specifies that the value 0xffff be substituted for 0. Why ? Because 0 is given special meaning. In IPv4 networks, it means that transmitter did not bother to include a checksum. In IPv6, the checksum is mandatory, and RFC 2460 says that when the receiver sees a packet with a zero checksum it should be discarded. The problem is, the hardware commonly in use on Sun SPARC systems (hme, eri, ge, and probably also ce and nxge) does not have support for this particular semantic. Furthermore, we have no way to know, in the current spec, if this semantic should be applied ...

You may or may not be aware of project Sitara . One of the goals of project Sitara is to fix the handling of small packets. I have achieved a milestone... using a hacked version of the nxge driver (diffs available on request), I've been able to get UDP forwarding rates as high as 1.3M packets per sec (unidirectional) across a single pair of nxge ports, using Sun's next sun4v processor. (That's number of packets forwarded...) This is very close to line rate for a 1G line. I'm hoping that future enhancements will get us to significantly more than that... maybe as much as 2-3 Mpps per port . Taken as an aggregate, I expect this class of hardware to be able to forward up to 8Mpps. (Some Sun internal numbers using a microkernel are much higher than that... but then you'd lose all the nice features that the Solaris TCP/IP stack has.) By the way, its likely that these results are directly applicable to applications like Asterisk (VoIP), where small UDP packets are he...

FYI, NetBSD has just got support for the LSI SAS controllers, such as that found on the Sun X4200. My patch to fix this was committed last night. (The work was a side project funded by TELES AG.) Of course we'd much rather everyone ran Solaris on these machines, but if you need NetBSD for some reason, it works now. Pullups to NetBSD 3 and 3.1 should be forthcoming.

So, the NICs group recently told me I should have started with qfe instead of hme, because qfe has some performance fixes. (Such as hardware checksum, which I added to hme!) To find out out if this holds water, I ran some tests, on my 360 MHz UltraSPARC-IIi system, using a PCI qfe card. (You can make hme bind to the qfe ports by doing # rem_drv qfe # update-drv -a -i '"SUNW,qfe"' hme (This by the way is a nice hack to use GLDv3 features with your qfe cards today if you cannot wait for an official GLDv3 qfe port.) Anyway, here's what I found out, using my hacked ttcp utility. Note that the times reported are "sys" times. QFE/DLPI MTU = 100, -n 2048 Tx: 18.3 Mbps, 7.0s (98%) Rx: 5.7 Mbps, 2.4s (10%) MTU = 1500, -n = 20480 Tx (v4): 92.1 Mbps, 1.1s (8%) Rx (v4): 92.2 Mbps, 1.6s (12%) Tx (v6): 91.2 Mbps, 1.1s (8%) Rx (v6): 90.9 Mbps,...

For those of you that care, I think we're in the home stretch for integration of afe and mxfe into Nevada. I spent the weekend going through the code, and reworking large portions of it to make use of zero-copy DMA wherever it was rational to do so (loan up for receive, direct binding for transmit). The NICDRV test suite has also identified a number of issues with edge cases that didn't come up often, but which I'm glad to know about and have fixed in the version of the code getting putback. They're only 100 Mbps nics, but the version of the code going into Nevada will make them run at pretty much the same speed as any other 100 Mbps NIC without IP checksum offload. And, they are still 100% DDI compliant. :-) Thankfully the DDI has been extended for OpenSolaris since the last time I worried about such things (back in Solaris 8 days). Anyway, looking forward to putback in b70 or b71. (Depending on whether I can get reviewers in time for b70 putback. If you can help me...

In case anyone ever wondered what a putback message looked like: ********* This mail is automatically generated ******* Your putback for the following fix(es) is complete: PSARC 2007/319 HME GLDv3 conversion 4891284 RFE to add debug kstat counter for promiscuous mode to hme driver 6345963 panic in hme 6554790 Race betweeen hmedetach and hmestat_kstat_update 6568532 hme should support GLDv3 6578294 hme does not support hardware checksum These fixes will be in release: snv_70 The gate's automated scripts will mark these bugs "8-Fix Available" momentarily, and the gatekeeper will mark them "10-Fix Delivered" as soon as the gate has been delivered to the WOS. You should not need to update the bug status. Your Friendly Gatekeepers Btw, the case to make this work for qfe (PSARC 2007/ 404) was approved yesterday as well. There are some internal resourcing questions yet to be answered, but at least architectecturally , the approach ...

So I've been trying to run my GLDv3 port of hme through a very rigorous battery of tests called "nicdrv" (the test suite used for recent NIC drivers by Sun QE... hopefully soon to be open sourced, but that's another topic.) Anyway, the test system I've been using is a poor little 360MHz US-II Tadpole system. (A Darwin-workalike, in shoe-box formfactor.) Unfortunately, the test times out while trying to do the UDP RX tests. Which really shouldn't be surprising... the test was designed for gigabit network gear, with gigahertz system processors (or better.) Well, it turns out that the hme driver can be faster. Considerably faster. Because the hardware supports IP checksum offload. But it was never enabled. (Note that this is true for the quad-port qfe boards as well, which are basically the same controller behind a bridge chip.) So, I've decided to have another go at getting a fully successful test result with this hardware. By modifying the driver to ...

I just putback the GLDv3 conversion of iprb. It will be in the next SXDE/SXCE. (b69 and later). It is still closed source, but I think that may change soon, too. (All the technical information in the code is reproduced on a public open-source developers guide downloadable at Intel, with the exception of the binary microcode, which is in the FreeBSD tree under an Intel-owned BSD license.) Anyway, I'm told Sun is having a meeting with Intel, and one of the agenda items is opening the source to iprb. Meanwhile, enjoy the GLDv3 goodness.

I've converted "afe" to GLDv3 in anticipation of it getting putback. I've also greatly simplified the buffering logic in it, because I was trying to be "too clever" and I think we were seeing failures during the extreme testing that Sun QA likes to perform. Anyway, this means that when afe gets putback (its on a schedule for snv68, but that may or may not happen), it will be GLDv3. Yay. Here's something to whet your appetite: garrett@doc{44}> pfexec dladm show-link eri0 type: non-vlan mtu: 1500 device: eri0 afe0 type: non-vlan mtu: 1500 device: afe0 This was done on a Sun Blade 100. No more legacy nics! This is also helpful for laptop owners, because afe is one of the more common cardbus devices. So, your cardbus 10/100 NIC will work with NWAM. If folks running snv_66 or newer want test binaries, let me know. I can offer them up in exchange for beer.

I'm also looking for folks to review my mxfe driver. It is posted at http://cr.opensolaris.org/~gdamore/mxfe Thanks!

I need to get code review coverage over the hme GLDv3 conversion. This is also a good chance to learn what it takes to convert a legacy DLPI driver to GLDv3. If you can help out, please look at the code at http://cr.opensolaris.org/~gdamore/nemo-hme/ The sooner I can get quality code review and test coverage, the sooner we can put this back! :-)

Now that OpenSolaris is supposed to be "Open", the community needs a way to perform quality assurance tests so that community contributions do not block on Sun QA. Currently, putback of changes to code to Solaris requires QA validation. For example, in order to putback my updated iprb and hme drivers (or my new mxfe driver), I have to get QA coverage. This means that I also have to get the time of someone from Sun, which can be challenging. In order to free the community from Sun's grip, we have to have alternatives, so that community members can perform testing; giving the necessary quality assurance needed for (Open)Solaris, without blocking progress. Hopefully someday soon the efforts of the folks who own the test suites to open them up will address this problem. For now, we just have to wait...

Well, maybe not so much the Universe, as our own galaxy.... I recently came across a statement that there was an estimated 100 billion stars in our galaxy. I started to wonder, about the odds of us encountering sentient life in the galaxy, so I started running some rough calculations, just to estimate. Astronomers estimate that approximately three out of four stars may harbor planets. (Basically, any unary system, plus any binary system where the companions orbit at least as far from one another as Pluto orbits our own star.) Again, these are rough estimates. So, maybe 75 billion planetary systems exist in our own galaxy! For the moment, lets call the probability of a planetary system harboring a planet capable of supporting life is p . Lets call the probability of life developing on such a planet l. Lets call the probably of sentient life developing from more primitive forms (at any point, without regard to the time it takes) s. Further, lets assume that the average age of a...

In build 67, you'll find that eri(7D) is now a Nemo driver, with full support for IP instances, VLANs, trunking, etc. As a consequence, you may have to fix scripts that do ndd /dev/eri since they now need to use /dev/eri0. Nemo driver developers: you no longer need to syslog link status changes. In fact, please don't, because Nemo does it for you now. Next up, hme, and (surprise!) iprb. (iprb was done last night on a bet.. Steve owes me a beer.)

That very question, specifically with regard to hme and qfe, but also some others, has come up lately. I'm of one mind (I think my position is clear by the very fact that I've invested effort here), but not everyone shares my opinion. In order to have an on-line concrete resource I can point internal Sun naysayers at, I'm asking you to voice your thoughts here, by posting a follow up to this blog. (Sorry, no anonymous posts, but that means your posts will carry all that much more weight.) Do you still use hme/qfe in systems? What about Sun Trunking with qfe? Would you upgrade to Nevada if there was GLDv3 support for these NICs? Would Nemo features in qfe/hme help you? Would a port of hme/qfe to x86 be useful to you? Please post a follow up on my blog here, with your opinions!

I just completed my codereviews of eri, and got approval from the owners of the code to commit the changes. I expect that as a result the eri conversion to GLDv3 (plus major cleanups in the code) will be putback next week ... probably on Wednesday afternoon. Why Wednesday? Well, I also need to commit PSARC 2007/298 and 2007/296, which the eri driver depends on. 2007/298 was the source of much debate lately, but I think a consensus has been achieved, and the changes should go in once I get the final blessing from PSARC (which at this point is pretty much a foregone conclusion.) Code reviews and testing have already been done. I've also sent an mxfe card to Alan DuBoff, so he can run it through the NICDRV battery of tests. Hopefully as a result mxfe will be integrated soon. I'm anxious for Alan to commit afe (he has asked that I not take this over from him), so that I can quickly convert it to GLDv3 as well. For some of the other legacy NICs (iprb, rtls, etc.) I've been...

I was recently asked to provide some notes about GLDv2 to GLDv3 conversion for NIC drivers. Here's a rough draft of them. (This is cut-n-paste from mail I sent to an intern at Sun... I'm posting them here so the knowledge isn't lost.) It is really helpful if you don't try to implement 100% of the features of GLDv3 in the first pass. (Some of the existing GLDv3 drivers, such as rge, nge, have incorrectly provided stubs for some functions, so don't use those as references.) Specifically I would not attempt to implement mac_resource allocation (MC_RESOURCES, etc.) or multiaddress support. You really do need to implement VLAN full frame sizes for MTU if your hardware can do it. Almost all NICs can do this. Sometimes the code to do it isn't in any Solaris driver. My preferred reference for alternate code sources is the NetBSD tree, which has an OpenGrok server for their code at http://opengrok.netbsd.org/ Ask me if you have any question about V...

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 ...

I recently decided that I wanted to create a zone with an exclusive IP instance, so that I could run IPsec (and specifically "punchin") in it. I have lots of NICs floating around, so I thought it would be trivial. Turns out that all my NICs were GLDv2, and that IP instances requires GLDv3. My solution? Conversion of mxfe (which were the cards I have in my system) to GLDv3. I figured it would be easier/faster than going out and buying a new Realtek card. And it would have been if not for one really annoying problem in mcopymsg() (see my previous post for that rant.) Anyway, mxfe is humming away nicely now as a GLDv3 NIC on my system. I even got VLANs working with full MTU frames. Yay. I filed PSARC 2007/291 today, if you're interested in it. I'll post the driver sources up somewhere shortly. (On another note, mxfe and afe are "suboptimal" drivers... they just blindly bcopy data, do nothing to reduce tx interrupts, and basically violate all the normal...

This entry could just as easily been titled "Why Bad Documentation is Worse Than No Documentation". I noticed that some functions from strsun.h are now part of the DDI. Great, I thought, I'll update my driver to use them as part of the general GLDv3 cleanup. One major surprise, which I spent about 5-6 hours figuring out tonight. mcopymsg(9f) has a side effect that isn't documented! Specifically, it does freemsg() on the buffer passed in. Don't believe me? Check the source ! The manual page says nothing about this. And reading logically from the name, you'd not think it would do this. The side effect should never have been designed in, in the first place. But if the man page referenced this side effect, I might , just might have caught this problem a couple of hours ago. In my particular case, it was causing hard hangs most of the time. Until I finally got a panic that pointed me into the root of the problem. (Yes, I probably should have set kmem_flags...

So this weekend I had to do a system reinstall. Thankfully I had all my data on a pair of sata drives in a ZFS raidz. But I had to totally reinstall my system with a new motherboard, new SATA controller, etc. I had to redo a bunch of things manually... NIS, passed, DHCP, etc. The one thing that I didn't have to worry about: ZFS. I just plugged my SATA drives in, and did "zpool import -f data" (my dataset was called "data", which I could have figured out by just doing "zfs import" without options.) That was it. One command only, and my raidz mirror was back in business, mounted in the right place, and even the right ZFS fileystems were NFS exported with the right options. Thank-you ZFS! ZFS developers, I owe you a round, or three. Let me know if you want want to collect. :-)

A few things that I love about OpenSolaris, but that Solaris 10 lacks: * Xorg default support for Intel GMA 950 * SATA ATAPI device support * WPA (coming in build 64) * NWAM (network auto-magic) * DMFE is GLDv3 I'm not sure which of these will be coming to a Solaris 10 update in the future, but I can tell you I was immensely pleased with my upgrade from Solaris 10 update 4 (on a Intel mobo, with a Core 2 Duo cpu) to Solaris Nevada b62. As part of the deal, I switched to a SATA DVD drive; my system is now entirely SATA (no legacy PATA ribbon cables in the box!) I'm sure there are lots of other useful features too, but at this point, I've put Nevada into "production" use at home, and I'm not looking back. (And yes, I realize b62 isn't the latest, but I didn't have a copy of snv_63, and the machine I was "reinstalling" ... thanks to an unexpected mobo replacement, was my network server.)

Some of you may recall my recent putback of the removal of in.tnamed. Well, there has been some nasty fallout, thanks to SMF and the upgrade process. snv64 (which will have to be respun as a result of this nastiness) was hanging during upgrade, thanks to chicken and egg dependencies in the upgrade script. I fixed the hang, but there is a warning message coming from inetd that I can't seem to locate. Along the way, I've found references to the network/tname service in a few surprising places. The things I've had to edit, thanks to SMF: usr/src/tools/scripts/bfu.sh usr/src/pkgdefs/SUNWcsr/postinstall usr/src/cmd/svc/profile/generic_net_limited.xml usr/src/cmd/svc/prophist/prophist.SUNWcsr usr/src/cmd/cmd-inet/usr.sbin/tname.xml (removed) And *still* we see a warning from inetd. See 6556092 in bugster for more info. Anyway, I'm waiting for folks to decide whether to allow the warning to stay, or to backout the change to remove in.tnamed. If the later is taken, I will r...

David Gwynne (dlg on #opensolaris) has created a very nice driver for LSI MegaRaid SAS controllers. You can find it here . I have not got any hardware, so I've not tested it, but this driver is the model of simplicity and elegance for an HBA, from what I can tell, weighing in at only 1500 lines. A great deal of that is no doubt thanks to the simple model of the hardware, but the simplicity and elegance in the driver should be credited to David as well. I'd like to sponsor this myself for integration into Nevada, but I haven't got any hardware. If you have hardware to loan for qualification testing, give me a shout, because this looks like a prime candidate for a Nevada integration.

The conversion of hme to gldv3 looks like it is a success. The driver "Just Worked" from the first time I loaded it. Yay. Still to be tested are the main areas of risk: VLANs, SUSPEND/RESUME, and DDI detach. Stay tuned for more on that front. I'm going to have to preserve qfe as a seperate driver, I think, because renaming/renumbering devices is just going to cause too much grief in the field. But, what I'm going to do is make hme.c and qfe.c very small (say ~50 lines each), and have them use a common misc module to provide the entire functionality. I have now received several qfe boards as well, so I'll be testing on x86 soon, as well. Watch this space for the code review to be posted. For the curious, some size comparisions: gd78059@sr1-umpk-52{8}> wc pcic/usr/src/uts/sun/io/hme.c{,.orig} 6498 19423 171291 pcic/usr/src/uts/sun/io/hme.c 8889 26403 232421 pcic/usr/src/uts/sun/io/hme.c.orig 15387 45826 403712 total size in the kernel ...

Subject says it all. This is the eri conversion to nemo. There is more testing yet to be done, but note that this means that eri will inherit VLAN and link aggregation support. Neat, huh?

I'm up in MPK this week. (Wed, Thur, and leaving Friday night.) If any fellow Solaris geeks up here are up for a pub outing, e-mail me.

I just committed a change to move 7 previously closed drivers in Nevada to the open source tree under usr/src. This change involved nothing more than Makefile and copyright block editing, so it was pretty much a no-brainer. (Though the heavy lifting of the legal review had already been done.) The drivers moved were: bscv, bscbus, i2bsc, gptwo_cpu, gptwocfg, todstarcat, and todm5819p_rmc. Admittedly, none of these are likely to exist on your hardware, but it does help to have more bits open. Hopefully someday /usr/closed will either cease to exist or become its own consolidation separate from Nevada.

Hmm... it looks like I never posted the webrev... well here it is, the webrev for the eri(7d) conversion to Nemo . Now, the second bit of good news here is that the PSARC case for this as been submitted as PSARC 2007/243 . Note that the case isn't published publicly at the time of writing, but it should be soon.

FYI, the afe and dmfe cases I had at PSARC (2007/229 and 2007/221 respectively) were approved. I've already put back the dmfe code. The afe code will be committed by Alan DuBoff. I've got pre-approval to do a follow-up putback to convert afe to GLDv3 afterwards. Note that as a result of Crossbow, there are some changes coming in GLDv3, so it is still inappropriate to use GLDv3 for unbundled drivers. (The biggest of these changes is support for "polling", where the network stack can disable interrupts on the NIC and run a separate thread to poll the device for inbound packets. On extremely high traffic systems, this can have a big impact on overall system throughput by avoiding the extra context switches.)

The PSARC fasttrack to integrate afe into Nevada was assigned case number PSARC 2007/229 . Notably, this case was not submitted by me (I'm not even on the interest list!), and is being done as a result of the BSD license terms for afe. It will probably be reviewed at next week's PSARC meeting.

Finally, over 20 years since the late Jon Postel said Death To IEN-116 , we have finally removed it from OpenSolaris. Who says changes in Solaris take too long?

As predicted, the area of biggest risk in my conversion of eri to GLDv3 was in fact the kstat handling. However, I appear to have that all worked out now, and the binary is working flawlessly on my SunBlade 100. Even suspend/resume works fine. However, I've not yet integrated this code properly into a workspace to generate a webrev, but I will do so soon. (Probably tomorrow... I'd like to get my two other RTIs put back first.) One of the biggest concerns about this effort was the added risk that doing this conversion might bring to the "stable" eri driver. So, I'm asking the community for help. If you want to help out with testing, especially if you have higher end systems or want to do some benchmark comparisons, please let me know. (I don't have specific test suites to give out that this time... its of more value frankly to have people using their own tests right now, that way we get broader test coverage than perhaps we might with a single test suite....

I've just finished (still testing!) my port of eri to GLDv3. Between that and eri, and looking at existing GLDv3 drivers (bge, rge, e1000g), I think I have gathered some operational experience that I hope we can use to improve Nemo. (So, anyone who says my time spent on converting eri was wasted is wrong... because if nothing else it gained some more operational experience with GLDv3.) Executive summary of the takeaways I have gotten so far, that I think are worth noting: There is still a lot of code duplicated across even GLDv3 drivers (more below) Lock management is so much simplified GLDv3 kstats need "work" we really, really need Brussels ... it can't come soon enough. some drivers can probably be changed internally to work even better with GLDv3 than a naive port So here's the detailed stuff. code duplication The duplicated code falls into three major areas. ioctls (mostly ndd (1M) and loopback handling for SunVTS), kstats, and MII. For now I want to f...

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.

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!

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!)

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.

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 ...

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.

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!

The Tadpole project is now live!

The first review for Tadpole platform support is online now. Please let me know your thoughts, after reading it. There will be more good stuff coming soon, I hope. (Also, if you have a Tadpole platform other than a SPARCLE or UltraBook IIi , and are willing to test, please let me know!) Thanks!

I just received two e-mails (identical to each other) stating this: Dear DAmore Garrett, The Heritage Registry of Who's Who is recognizing you for possible inclusion in the upcoming 2007-08 Edition. Please go to http://theheritageregistryofwhoswho.com and click on the invitation button. Thank You, Chris Jespersen I'm not entirely convinced this is a worthwhile thing... but I'm willing to play along until they ask me for money. Anyone else out there received these before?

FYI, I recently proposed a new project to track improvements to support for Tadpole platforms in OpenSolaris. It looks like it got the seconds needed, so I'm just waiting for the infrastructure to be created.

I just made my first putback to ON (6487387 pcic driver contains obsolete & private Tadpole code that should be removed). While this is nothing earth shattering, hopefully I'll be making a lot more commits soon.

I've been wondering how many other OpenSolaris users there are out there in the Inland Empire. I recently met one close to me, which surprised me quite a bit. I figured I was the only one within at least a 30 mile radius. If there are others of you out there, please drop me a line. I'd like to inquire as to whether it makes sense to consider starting a User's Group for the area. Possibly we could join up with any other User Groups for Southern California. For the record I live in southwest Riverside county, not far from Temecula and Murrieta. (For those of you not familiar with the west coast, the Inland Empire refers to a large region of southern California that is separated from the coastal areas of Orange and Los Angeles counties by a range of coastal mountains. I often have joked that I'm about 65 miles from any natural technology center, but now I'm not so sure. And I think a lot of people who commute to places like San Diego and LA live out here.)

Funny note. When I came back to Sun (two weeks ago), I discovered that an ancient PSARC case (2002/356) for the removal of the Trivial Name Server (in.tnamed) had never been completed. So for 5-odd years since we've continued to ship this long-since-obsolete protocol. I'm going to go ahead and drive forward with the actual removal... at the time I did it as a case study in how much process was involved with even a simple EOF. Lets see how long this one takes. (For the record, the IEN-116 protocol was obsolete as far back as 1986, when J. Postel first requested vendors ditch it.)

Those of you using afe (and also mxfe) will be pleased to note that the time is fast approaching when afe will hopefully be integrated into Solaris Nevada. There is a PSARC fasttrack scheduled for it next week if I understand correctly. (I don't have the case number yet.) There are a few ramifications of this. One of the most immediate is that I'm going to be winding down support for versions of Solaris earlier than 10. In fact, I no longer have any personal installations running anything less than S10u3, and most everything is running Nevada. The other reason for me to do this is so that I can immediately start taking advantage of some features that are present in Solaris 10 and Nevada. For example, I want to add support for DLPI link notification, and ultimately (in Nevada) port to GLDv3 . The GLDv3 has some compelling features, and as a result afe and mxfe will gain support for features like vlans, jumbo frames, and interrupt blanking. And, they'll also benefit fr...

As a consequence of work I've been doing lately since I joined Sun, I've learned some things that folks who care a great deal about performance might like to know. The most important of these is that not all gigabit cards are created equal. And even among those that are, some of them get preferential treatment at Sun. One surprise: the gigE device that gets the most preferential treatment is not a Sun branded NIC. In fact, its a device that you can readily find at your local computer retailer. I speak of bge. The bge (Broadcom) NIC has some very, very sophisticated logic on it, that Crossbow is going to be able to take advantage of to get you some very nice performance acceleration, plus some greatly added support for QoS and stack virtualization. If you're thinking about a NIC, my first choice would be a Broadcom NIC. The Cassini (Sun Gigaswift) has many of the same features, but costs more, and is harder to find. And, the Cassini isn't supported by some of the cr...

Its official! The OpenSolaris Constitution has been ratified . Yay! Congratulations to the new OGB as well. I'm generally very pleased with the election results, despite not getting elected myself. A few interesting tid bits: 1) Rich Teer is the only non-Sun OGB member. (And apparently he has done some work for Sun.) 2) The entire OGB seems to be made up of engineers. 3) Neither female member was elected. 4) There are two ARC members sitting. (James Carlson and Alan Coopersmith.) 5) There seems to be good geographical representation... i.e. MPK (and SFBay in general) don't seem to be overweighted. 6) Several members have sat on other FOSS boards (at least Glynn and Alan) I would have liked to see someone with more marketing and program management elected. In future years, I'd like to see the process for Core Contributor grants revised. I think only folks who are active in the community should have this role ... I think a lot of people got grants just because they commi...

I just cast my ballot for the OGB and ratification of the constitution. I will not tell you who I voted for, but I will say two things. First off, the decision was hard . There are some excellent candidates running. I'm pretty confident that we are going to have a great OGB, made of up reasonable individuals who are passionate about OpenSolaris. (Yes, I did vote for myself, but I also voted for quite a few other people... there are 7 seats, after all.) Second, I did vote to ratify the Draft Consitution. I hope you did, too. The window of time to cast your ballot is quickly drawing to a close. Polls close on Monday, so be sure to cast your ballot before then. Unlike some others, I waited a bit, primarily because I wanted to hear what some of the other candidates had to say. So even if you have not voted yet, please do so today . Even if you abstain from voting on the candidates, at least make a statement on the ratification of the constitution. I believe it is important to...

Apparently, I am not the only one who started here at Sun yesterday. Auspicious? Wait and see... Meantime, I spent yesterday meeting the group, and getting to know what I'll be working on. There's some exciting stuff going on, and while I can't really talk about it now, the good news is that eventually the good stuff will make into OpenSolaris.

Simon Phipps (aka webmink) interviewed me yesterday as part of the series of interviews he is giving to the OGB candidates. This is an excellent way to get some idea of each of the candidates; if you're a Core Contributor, I recommend checking his blog out.

As you probably know, I'm running for a seat on the OpenSolaris Governing Board (OGB). I've answered a number of questions already, but I really like how Keith Wesolows has set up a position statement, so much so that I'm going to do the same. Much of my layout and presentation follows his, but rest assured that there are real meaty differences here. :-) Before I do that, after reviewing a lot of the material that has been submitted by nominees, I do think there is a really good group of candidates who are as passionate and level-headed as I am running... its likely that I'll be happy with the board that is elected regardless of whether I'm on it or not. Now, on to the details... I'll start with my positions on things, along with a short bio at the end. The Constitution YES. The document isn't perfect, but it is an excellent start, and we can address issues with it as we move along. Without it, the OGB cannot exist, and the project will not be able t...

This is my new blog, replacing the short-lived Celestial Bodies, Amphibians, and Reptiles blog I set up while an employee at General Dynamics (formerly Tadpole Computer.) There will be more here in short bit, particularly an update on my position for the OpenSolaris Governing Board (OGB).