Tuesday, August 12, 2008

New audiohd driver posted

We've gotten a lot of good feedback from previous posting of the audiohd driver, and the Beijing engineering team has come up with a new version (Aug 12, 2008.) Note that the latest audiohd driver will always be posted here.

One note: please use the obj32/ or obj64/ versions of the driver unless you are running a debug kernel. There are some binary dependencies where the debug drivers won't work on a production kernel.

Friday, August 8, 2008

SDcard pushed...

Finally, after months of delay, the SDcard bits have been putback^Wpushed.

This was interesting, because the SDcard bits were also some of the first bits to have been pushed into the new Mercurial tree -- and they're already in the clone. Adventurous people can start trying the code out now. Or just wait until b97.

Of course, this also means that this will be a new feature in the OpenSolaris 2008.11 release. Yay!

If you do try the bits out, let me know what works, and what doesn't. There seems to be some evidence from the Linux community that not all SDHCI compliant controllers are created equal, although the code I have works for the few variants that I've had access to.

The bugster category for bugs is solaris/driver/sdcard

Thursday, August 7, 2008

SDcard RTI submitted... webrev posted

Finally got legal approval!

A webrev is available, as well, in case anyone wants to look at it. I hope to have this integrated into b97.

Wednesday, August 6, 2008

SDcard Home Stretch

The SDcard Phase I project is in the home stretch -- the only thing remaining at this point is two signatures. And one of those is my managers! (The other one is the final sign-off from legal, which I expect to happen tomorrow.) I'll file my RTI tomorrow evening, most likely. If folks, I can also post a public webrev at the same time (though that would just be informational, as the actual required code reviews have already taken place.)

Tuesday, August 5, 2008

Classic! Another Work I Don't Care About

Apparently Twitter has been hit by another Trojan, according to the BBC.

What I love is the last paragraph in the article:
Only those using Microsoft Windows are vulnerable to infection from these malicious programs.
Of course, I only run Solaris at home, so I guess I have naught to fear. See, there is an upside to having a tiny market share on the desktop!

Teamware Is Dead

I still recall seeing the mail years ago, when the tools group told us that Teamware was EOL, and would not be supported any longer. I recall thinking, OMG, what are we going to do for ON? At the time, it looked (to me at least), like BitKeeper was a logical replacement.

Now here we are, years later, and with the closure of build 96 last night, we have finally stopped using Teamware for new development at Sun.

Mercurial/Cadmium seems like a powerful and capable replacement, and has the advantage of being open source. This is one of the most significant technical hurdles to fall that has kept external folks from being able to commit directly to Hg. (Opening up RTI, and the bug tracking database are the two remaining big ones. RTI can probably be opened without too much difficulty. The bug tracking problem is a different matter altogether.)

As a nice side effect, external folks can now have their changesets integrated directly, without requiring sponsors to do conversion work, and without requiring sponsors to place a "contributed by" credit. (Because the changeset will already have the contributor's e-mail.) This should significantly reduce the amount of effort required for sponsors, and consequently make it easier for more people to contribute.

Big thanks to the SCM team!

Monday, August 4, 2008

Why You Don't Want to Force Link Modes

So, I got a message today, not uncommon, indicating that some poor guy is dealing with an IT organization that still requires link parameters to be forced to 100 Full.

It hardly seems reasonable that in today's day and age, folks wouldn't be using auto-negotiated link parameters, yet, there it is!

This blog entry is dedicated to those IT organizations stuck in the early 90's, still requiring their users to force link mode.

1. Back Story

Once upon a time, 100 Mbps full duplex 100Base-T was new. And in the early days, there was not universal adoption of a standard (in the very early days there wasn't a standard at all!) for autonegotiation of link speed and mode.

The IEEE 802.3 group (the folks that oversee the Ethernet standards) rectified this with a standard called "IEEE 802.3u", which provided the rules for auto-negotiation.

Most of the world, and pretty much all of the equipment manufacturers, adopted this standard in short order, and there was much joy and happiness.

2. Except....

That some IT organizations had older equipment, and had compatibility concerns. So, they insisted that that their users "force" the link parameters. This allowed everyone to take advantage of full-duplex operation in those organizations.

3. The Conflict

The problem with this situation is that disabling auto-negotiation on the switches in the machine room meant that the default auto-negotiation which all hardware shipped with enabled by default didn't work properly. With the back-end not doing 802.3u, the front end can't decide, and defaults to a "safe" mode of 100 Mbps half.

Of course, this safe mode causes all kinds of problems on its own, if the back-end is presuming full duplex is OK. (This will manifest as errors and collisions on the link, in bad cases it can make the link entirely unusable.)

4. IEEE Steps In

So, for the next round of standards for ethernet, the Gigabit standards, the IEEE required the use of auto-negotiation to select link speed and duplex. Its possible to control what is advertised/supported by a partner, but you must not disable auto-negotiation itself. The upshot of this is gigabit equipment is going to have difficulty with those backwards IT organizations that still require forced modes.

5. The Problem Today

The problem today is that some IT organizations have carried this practice on for years, leading to excessive support headaches, etc. They have avoided the one-time cost of transitioning to auto-negotiation, but they do so at the continued cost of support headaches resulting from this decision.

Added up over time, I expect that the support costs for dealing with problems from mismatched duplex settings due to one end having auto-negotiation administratively disabled probably totals in the millions of dollars. I'll leave the math to the bean counters, but its not trivial. (One of the problems is that each time a new OS or a new piece of equipment is added, someone has to figure out how to change the defaults. I've probably spent over a dozen hours helping people with this problem myself over the years -- which is silly because IMO nobody should have this problem, at least not outside of possible testing scenarios.

As another example of what can happen ... recognize that it is not always possible for end equipment to support full-duplex. All hubs, by definition, cannot support full duplex operation. So, what happens in your organization when some bloke wants to add a hub to get an extra Ethernet port? Does everyone in your IT department know about this limitation? (How many hours have been spent tracking down this particular problem, I wonder?) If auto-negotiation is used, it won't matter.. everything Just Works, regardless of whether the end user inserts a hub or a switch.

(Hubs are also extremely useful for performing network debugging, because it provides a point at which bits can be examined on the wire using tcpdump or snoop or similar tools. Obviously, this mode of debug is not available when organizations force the switch to use full-duplex operation.)

6. What You Can Do

If you're in an IT organization that boycotts 802.3u, consider strongly whether this practice is worth continuing. (I'd argue it isn't, at least if your organization ever grows.) New ports should be allocated without this requirement, old ports should be converted as they are able to be, if the organization can't convert them all at once.

In the era of 1G and 10G (notably 10G not only requires auto-negotiation, but also does away with half-duplex operation!), its past time that IT organizations caught up into the current millenium with their management strategies.

Feel free to repost this where your IT head of department will see it.

Sunday, August 3, 2008

OpenSolaris as a boot server

I recently upgraded to the "latest" OpenSolaris on my desktop. This is also my primary NIS and NFS server and boot server.

I was rather dismayed at first by some of the bits that were missing. NIS, DHCP, and more. I finally got it all working, and I thought I'd document it here for posterity.

First install NIS. "pkg install SUNWyp"

(Configuration of NIS left as an "exercise" for the reader.)

Second, DHCP was missing, so we install it as well:

"pkg install SUNWdhcs SUNWdhcsb SUNWdhcm"

(Configuration of DHCP left as an exercise...)

Then, it turns out that there was no manifest for TFTPD, not even a commented out entry in /etc/services. I copied the line from /etc/inetd.conf on another system:

tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot

Then run "inetconv".

My question to the OpenSolaris/Indiana folks -- why wasn't this listed in the stock inetd.conf -- even as a commented out entry? What I'd have preferred is to see a default service installed, but not enabled by this for default. It took some man page reading and investigation to figure out where tftp was in the "new" world.

Anyway, its all working now... I'm booting a b95 image over the network as I type this...

Friday, August 1, 2008

Another SDcard Status Update

Some of you may have been wondering about the work I've done for SDcard. Well, it looks like we have basic agreement at this point, and I am only waiting for the lawyers to draft the final text granting the approval, and then I'll be able to supply the bits publicly, as well as integrate them into OpenSolaris. I'm expecting that this could happen as soon as build 97. Stay tuned, and sorry for the delay.

(Internal folks can access bfu archives for Intel based system at /net/zcube.west/export/ws/sdcard/hg-x86/archives or for Tadpole SPARCLE /net/zcube.west/export/ws/sdcard/hg-sparc/archives. There's an internal webrev up as well at http://jurassic.sfbay/~gd78059/sdcard/ -- enjoy!)

Lint cleanups in kernel

A few weeks ago, I committed changes to start the clean up of a bunch of lint overrides in the kernel, and provided text explaining how to continue the work (along with admonishments to do so.)

I am very happy to report that it seems that some folks took what I said to heart, and over the past couple of weeks there have been a continual stream of lint related fixes, such as this one.

Thanks to everyone who's helping out!