Boomer Beta Refresh

I've posted a refresh of the Boomer beta bits. The location has moved to the more sensible project specific location as well.

This refresh includes SPARC support, and fixes for a couple of bugs that folks ran into from the first beta.

Boomer Beta Available!

Finally!

The first public beta binaries for Boomer are now available! Details are available from the Open Sound Project webpage.

Enjoy!

-- Garrett

(Update: the website update didn't take. OpenSolaris.org is really sick now, any updates seem to cause it to crash now. I've posted binaries here, temporarily. The webrev is in the same location as before.)

HP to Sell Solaris

Its official, HP will start bundling Solaris on their x86 rack servers. Wow.

Boomer webrev posted, screenshots

I've posted a webrev of the Boomer tree against onnv_109. While the review itself is probably daunting, and I'm not actively asking for folks to review it, you are welcome to do so anyway. Please send us your feedback if you have any.

Here's a couple of snapshots of our updated gnome-volume-control running on an Ultra 20, as well. (Note that we've enabled display of all "tracks".)




First the Playback tab, which shows individual slider support for each of the analog controls, as well as a single monophonic "master volume" slider. If we had an older system that didn't have independent volume control, we might have an option at the bottom of the screen to select playback sources. Its not required on this system.





The Recording tab shows some improvements. Instead of having just a single monitor gain control, you can now independently control the monitor gain for each of several input sources. There is only a single "record gain", but that's a hardware limitation. Notice that you have some additional features on this particular device: an optional 20dB microphone boost, and the ability to select from one of two different microphone inputs. These are device specific options.





The Options tab has some other bits. First off, notice the slider that lets you control the keyboard beep volume. This is device specific (it requires the system to be designed to route the PC beeper through the audio codec -- a common choice on laptops), but it can be useful.

On this system, you also have some jack retasking options. You can use the input jacks (mic and line in) as Surround and Center/LFE functions, as I've shown here. With this option, you can achieve 5.1 audio even on the original Sun Ultra 20. The Loopback option is intended to take your recording source and loop the input directly to the DAC output, bypassing the mixer altogether. I doubt it will be often useful, but since the hardware can do it, there is no reason not to offer the choice here. Note that most of these advanced options are not displayed by default in the application, but require you to enable them in the Preferences Dialog.

SDcard Panics, Ricoh Controllers

I figured I better post this publicly. If you have a Ricoh SD controller (pci1180,522) then you don't want to use SDcard in OpenSolaris with it. You'll probably get panics, memory corruption, etc.

There is a known bug -- CR 6797937 that tracks this issue. I've filed an RTI for this issue, and hope to have it pushed later today. You can review the diffs for this on this webrev, if you're so inclined.

This is known to affect Toshiba Tecra M10, IBM T61, and probably a bunch of others besides.

Sorry to those folks affected, we're trying to drive the fix for this out as quickly as possible. It should be in 109.

Update (Feb 5, 8:19pm PST): The fix for this problem was just pushed into ON. It will be in tonight's nightly build.

Boomer Updates

Just a quick note: no Boomer beta release this week. Due to a bug which we fixed in ON, but which we are dependent upon, there won't be any formal beta release until after SXCE b107 ships. And it will depend on SXCE b107. (And likewise, when the OpenSolaris package repos are updated to use b107, you'll be able to use OpenSolaris and Boomer together.)

I probably will post an updated code review, and possibly BFU archives, for the folks that want to play with these bits earlier and are willing to deal with BFU. (Hmmm.. does BFU work correctly on OpenSolaris? I've only used it on SXCE.) That posting will probably occur on Monday or Tuesday of next week. Stay tuned.

(Is there any interest in an external Mercurial repo for this stuff? I hadn't been planning on one, but if folks want one and will use it, I'll look into it.)

Boomer Status Update

I've received a number of e-mails inquiring about Boomer, the next generation audio system for Solaris. I thought I'd take moment to snapshot where we're at.

The good news:

• We're very nearly done with Phase I. There are still a couple of bugs to fix but its looking very promising that we'll have a strong public Beta release later this month, with integration into ON in February or March.
• The release will include multichannel surround across a fairly wide range of devices.
• All the existing Sun audio drivers are supported (except Sun Ray)
• All the drivers except usb are "native" Boomer drivers, with greatly reduced complexity and (hopefully) much better reliability
  
• We have much better support for adjusting different device settings, either from the CLI or from a GUI. This includes surround settings, special device features (such as 3D enhancements), and even jack retasking on certain codecs. (You can even use this to have 5.1 audio on an older Sun Ultra 20!)
  
• We also have full support for Solaris features like suspend/resume and quiesce.

The not-so-good news:

• There are some features that will be MIA. SPDIF (digital out) support is very limited, only working with audiohd at present.
• We don't have as many new drivers (yet) as we had hoped.
• Dolby Digital (AC3) support has been pushed out to Phase 2.
• Support for Sun Ray is Phase 2 as well.
• Support for "virtual audio" (where the /dev/audio and /dev/dsp are virtual devices that seamlessly choose the "correct" audio device, and redirect audio in response to hotplug events -- even for running applications) is looking questionable for Phase I, it may be a Phase 2 item as well.
• At the moment, all of our drivers run at 48kHz and use 16-bit audio. We can update (and probably will update) some of them to support codecs that have additional bit width or higher frequency options, but this can be done on an as needed basis. (So far the vast majority of devices out there support only 48 kHz/16-bit audio, anyway.)

Boomer Beta Source Code Posted

Boomer, aka PSARC 2008/318 -- the new audio subsystem for Solaris, and the project I've been working on for the last several months -- has released source code for our work in progress. A status update and link to the webrev is available here.

Floppy drive suspend/resume fixed

Earlier today I just pushed a fix for suspend/resume when the machine has a floppy disk drive. Surprisingly, a lot of modern machines still have floppy disk drives in them, and this fix enables those platforms to participate in the S3 suspend work.

The fix will be in b105.

One such machine is the Dell Precision M390. I imagine there are many other desktop class systems of this nature.

While suspend/resume has been focused largely on laptops (where battery life is a paramount concern), I suspect that enabling suspend-to-RAM for desktop class systems will ultimately have a larger environmental impact, since it is those systems that typically consume the most power. So, perhaps this small change will have a somewhat significant impact.

If you have a platform that this enabled suspend/resume to work on, tell me about it. Include smbios output in your message, too. :-)

SDcard Fixes

I've heard a number of problems with folks trying to use SDcard with Ricoh controllers (such as found on certain newer Toshiba Tecra laptops), as well as lack of quiesce(9e) support, and various other problems.

To address these problems, I've made a bunch of changes, and am looking for code reviewers and testers -- the webrev is an open review.

I've made binaries available to anyone who wants to try these out. To try out the new binaries, just untar the sdcard-20081202.tar.gz file in your / directory. You might need to reboot for them to take effect. (If you know how to modunload the drivers from kernel memory, that will work too, provided that you don't have any SDcard media inserted at the time.)

Please let me know any feedback you might have. Thanks.

locking hints for device drivers

It seems that I often run into the same problems over and over again, and I see many device drivers which often suffer from the same problem. Here are some strategies I use in my own coding -- maybe someone else will find them useful. To my knowledge they have not been documented elsewhere.

1. KISS. Start with as few locks as you need to get the job done. Only add locks when performance analysis shows you need them. I usually start with an assumption that I'll need one lock per device instance, and possibly a single global lock. (If you don't have global state, you can elide the global lock.) For some kinds of drivers (NICs in particular) I introduce a lock for each major traffic direction (so one lock for rx, and one for tx) per instance.
   
2. Global state is evil. Global state requires global locks. Global locks often introduce lock ordering problems, and can also more likely to be contended in systems with lots of devices.
3. Thou shalt not sleep in STREAMs entry put(9E) and srv(9E) entry points. This one I frequently see violated. These can run in interrupt context. Don't call cv_wait(9F) or its friends here.
4. Use mutex(9F)es as your lock primitive of choice. rwlock(9F)s are slightly more expensive (and can be more challenging to get read versus write sorted out properly), and semaphore(9F)s can fall prey to priority inversion.
5. Hold those mutexes for as short as possible. If you can do some work ahead of time, or defer it to later, outside of the time you hold the mutex, you'll greatly reduce opportunities for contention. Uncontended mutexes are good. Contended mutexes are bad. Sometimes small bits of code reordering can have significant performance impact.
   
6. lockstat(1M) is your friend. It can really help you to understand what the hot locks in your driver are.
7. ASSERT(9F) is your friend. You can place assertions up front of functions that have to be called with certain locks held. Its easier to debug assertion failures than it is to debug deadlock or (far far worse) race conditions.
   
8. Be uncompromising about order of lock acquisition. Ensure you always, always acquire mutexes in the same order.
9. Avoid locking side effects. Functions should usually exit with the same locks held that they started with.
10. Leaf locks are easier to understand. If you can reduce a lock to a leaf lock (one that is never held across functions which do any other locking), then you're guaranteed that the lock is safe.
11. Avoid assumptions about locks held in the framework. With very few exceptions (bcopy(9F), strlen(9F), etc.) you can generally assume almost any DDI routine you call will need to acquire a lock. Hopefully most of them are leaf locks.
12. Be very concerned if you think you need to drop a lock only to reacquire it. (Such as dropping a lock to make a call up into the DDI.) This is one of the more frequently encountered problem areas. Locks used to create atomicity are only effective if the atomicity is not broken. (If you drop a lock, you must not assume any of the conditions that held true when it was first acquired remain true when it is reacquired.)
13. Minimize asynchronous activity. Do you really need to fire off a taskq, or use timeout(9F) to perform that operation? More asynchronous threads is more complexity, and violates principle 1 (KISS).

Of course, there are often good reasons to violate one or more of the principles above. I find that if I try to to adhere to the above principles though, I run into fewer ugly problems in debugging kernel software. So I always do a double take if I think I need to violate one of the principles -- probably about 70-80 percent of the time, that double take leads to a simpler or better approach that doesn't violate the principles, and ultimately saves me lots of pain later.

BMC on concurrency

Bryan Cantrill has just posted one of the more excellent blog posts I've seen this year -- he manages to put to words some of my heretofore unvoiced doubts about transactional memory. I'm a big fan of KISS, and both TM and multilevel threading seem to fail on that front.

fdc suspend/resume support

In another update, I've updated fdc (the floppy disk controller) so that it supports suspend/resume even if a floppy drive is present. There is one caveat though -- namely that the drive must be empty. Still, its far easier to pull a disk out of a drive (if you even have one -- most floppy drives these days probably see very little, if any, use), than to disconnect the drive entirely.

You can download the file from the device drivers download page (look for a file named fdc-2008-11-01.tar.gz). A webrev of the changes is also posted.

For the curious, the reason for the above caveat is best stated by the following explanation extracted from a comment in the code:

Bad, bad, bad things will happen if someone changes the disk in the drive while it is mounted and the system is suspended. We have no way to detect that. (Undetected filesystem corruption. Its akin to changing the boot disk while the system is suspended. Don't do it!)

So we refuse to suspend if there is media present in the drive. This limits some of the usability of suspend/resume, but it certainly avoids this potential filesytem corruption from pilot error. Given the decreasing popularity of floppy media, we don't see this as much of a limitation.

Anyway, I suspect these changes may have little value to laptops, but may help a lot of desktops. It certainly addresses the problem of SUSPEND for my Dell Precision M390.

Update: Thanks to Jürgen Keil's testing, we have found a bug, which I've fixed. The webrev and the binaries have been updated accordingly. Look for the 11-04 release instead.

iprb updated with suspend/resume & quiesce

I've updated iprb (Intel Pro/100 Ethernet driver) to support suspend/resume and quiesce (fast reboot). I've also made some other changes, such as updating to the latest microcode from Intel, fixing some potential races, and improving the internal implementation of the statistics routine.

I'd like folks to try it out on their Intel or AMD platforms. The tarball can be downloaded from here (look for iprb-2008-11-01.tar.gz).

I still want to get this open sourced, but I haven't got approval from the lawyers yet. But here are the binary bits in case anyone is waiting for them.

(I'm not planning on porting this driver to SPARC. There are too many places in the code that would have to be changed to use endian-safe calls to ddi_get, and I think there is probably very little demand for a SPARC version of the driver. If you are one of the people who do want SPARC support for iprb, please let me know.

Enjoy!

Boomer: Next Generation Audio for Solaris

I've posted draft inception materials for our PSARC case, 2008/318, for Boomer. Boomer is the code name for the effort to integrate a modern OSS-compatible API, and additional drivers, into Solaris.

PSARC inception review for this case is scheduled for November 5, 2008. Please check the ARC web page for call in details (any engineer in the community may dial in.) Be advised that the meeting is an engineering meeting, though. (PSARC provides engineering architectural review for projects.)

We have a working prototype for most of the bits we are ARC'ing at this point, and I expect to be opening up the source code tree, and binary test bits, in the coming weeks. Perhaps by Thanksgiving.

Sun position available in Austin

A new position in Austin, TX has opened in my group (onsite only). This is for a junior or mid-level administrator or QA type person -- great for someone who loves playing with new hardware, software, etc. No specific programming skills beyond every day scripting required (though perl and C would probably be useful.) Send replies back to me. (Full disclosure: I get a referral bonus for anyone I refer.)

Microsoft & NetBSD

Some folks might be interested in this. I used to hack on NetBSD at my previous job. I recently had an inquiry from a recruiter at Microsoft (don't worry Neal, I'm not going anywhere! :-) which I thought I'd share here.

Location: Redmond, WA
Client: Microsoft.
Job Description:

Seeking a talented NetBSD software developer interested in helping Danger (a subsidiary of Microsoft) ship the next generation of Danger’s Sidekick platform. Specifically, we’re looking for NetBSD developers interested in commercializing the NetBSD platform for an embedded mobile computing device, focusing on performance and optimization, bug fixing, and integration with Danger’s higher-level platform code, with an emphasis on kernel and driver support.

Qualifications:

- 8+ years of software development experience

- 8+ years experience with C

- Strong understanding of OS concepts (particularly with NetBSD) such as multi-threaded program design and synchronization, processes & memory protection, etc.

- Strong communication skills

- Strong understanding of the NetBSD/GNU software development process and embedded development & debugging techniques

- Deep understanding of NetBSD, including timers, RPC, TCP/IP, etc.

- Experience with ARM processors highly desirable

So, not Windows CE or some other Windows platform. Cool. Wonder when they'll start posting job offers for Solaris engineers? (Probably as soon as Solaris is useful for small embedded devices -- i.e. I wouldn't hold my breath. :-)

New Stuff in OpenSolaris 2008.11

OpenSolaris 2008.11 is coming soon. Build 101 is the stabilization build before it, and as usual, new features are excluded from this build. So we can say pretty certainly what features are in, and what are out.

While there are a lot of new features coming in this release, there are some in particular that I've been more involved with.

1. SDcard support. Numerous laptops can now use SDcard and MultiMediaCard media directly. A good way to know if you're laptop is one of them is to search for pciclass,0805 in the output of prtconf -vp. While it isn't completely conclusive (in particular some models from Texas Instruments are schizophrenic here), if you see this, there's an excellent chance it will work. I'd always like to hear feedback about this feature -- if your unit works, or doesn't work, let me know. (Also, of course, the Tadpole SPARCLE models are supported. )
2. AudioHD improvements. Notably, many more laptops will now have working audio. The audiohd driver is also updated to support Suspend/Resume.
3. Fast Reboot. I participated as a consultant. I'll also be updating (post OpenSolaris 2008.11) additional drivers to support this feature. The upshot of this project is that a healthy system can reboot much more quickly now.
4. Brussels (NIC Administration). I've participated in converting several drivers to Brussels, and in generally improving Brussels (I'm also the ARC sponsor for this work.) The upshot of this project is greatly improved manageability for network interfaces.
5. Suspend (S3) Support. I helped review the conversions of several drivers, and provided fixes for several NIC devices.
6. Bug Fixes. I've worked on a number of them, and of course, there are huge numbers of bugs that have been fixed in this release.

All said, I think OpenSolaris 2008.11 is going to be great -- I confess that I was skeptical about the earlier releases, but this release is shaping up to be really awesome.

Ancient History Exhumed

Okay, maybe not so ancient (circa 2000), but I recently got an e-mail from the Sun IT group notifying me about changes that impacted web pages I set up for Alternate Pathing, which was the very first project I did that involved work within the Solaris kernel. Apparently they didn't notice that I'd left the company and returned.

Of course Alternate Pathing was canceled a long time ago, although someone may still be using it on older E10K Solaris 8 systems.

Here's the Sun internal URL to which the e-mail referred. The bug tracking pages are broken, since the scripts behind them were developed (by me) to talk to the BugTraq+ Sybase server, which Sun hasn't used in ~forever.

IOMMU comes to Solaris x86

This weekend, the code for the IOMMU for Solaris on Intel (PSARC 2008/560) was pushed. This has potentially profound ramifications for folks working on Solaris device drivers, and I thought I'd take some time to talk about them.

First off, it needs to be noted that we've had an IOMMU on Solaris SPARC pretty much for as long as we've had Solaris on SPARC. (In fact, most SPARC platforms have to use an IOMMU -- they have no choice.) But on x86 this technology is new.

The benefits that IOMMU brings are many fold.

1. It virtually guarantees that all DMA requests can be set up with a single DMA cookie, reducing complexity and eliminating the use of bounce buffers by the DMA framework -- even for old devices with unfortunate restrictions (such as an inability to perform dual address cycles on PCI -- i.e. no 64-bit support.) Such restrictions are actually fairly common place.
2. It allows for strong isolation to be given for devices that can be accessed via other virtual machines or domains. This can prevent one misbehaving xVM domain from crashing others by misprogramming the DMA engine on a physical device.
3. It allows for isolation of faulty devices, so that they cannot scribble into arbitrary PCI spaces, preventing a misbehaving device from accessing regions which it should not. This has major benefits for fault resilience, as well as diagnosability. (To be fair, I'm not 100% sure the code is in place yet to leverage all of this benefit, or integrate it with FMA.)
4. It facilitates debugging of faulty device drivers. To give a concrete example, when I was working on an audio driver recently it took me a long time to figure why the device was emitting white noise. It turns out that I had not initialized the DMA address register properly. With IOMMU, instead of the device just getting random data, I'd have gotten a bus fault that would have contained information that I could have used to see that the device was trying to access some weird place memory to which it had no right.

Now, these features don't come without some cost.

1. Setup and tear-down of DMA operations is potentially significantly more expensive than with the simple translation layer previously used. Device drivers that assume such operations are inherently cheap may be in for a surprise.
2. Drivers still have to retain the ability to operate in an environment without an IOMMU. Effectively, this means that they need to be prepared to see more than one DMA cookie or window per DMA region. Generally speaking, well written drivers should make no assumptions about the number of cookies used beyond the limits expressed in the DDI DMA attributes. (Namely, the framework is free to use any number of ddi_dma_cookie(9s) >= 1 and <= dma_attr_sgllen.)
3. Drivers that require physical rather than virtual memory be used (i.e. that need to bypass the IOMMU) can request mappings using DDI_DMA_FORCE_PHYSICAL in the ddi_dma_attributes(9s) dma_attr_flags field, but such requests are not guaranteed succeed. A portable driver must retry such a request without the flag set, if the first attempt with it set fails.
4. Generally, correctly written drivers will Just Work with the integration, without any changes to them. I would discourage driver authors from disabling the use of DDI_DMA_FORCE_PHYSICAL unless they have specific performance requirements. (And, normally, there are better solutions such as reuse of mappings, so that DDI_DMA_FORCE_PHYSICAL remains unnecessary.)
5. The IOMMU imposes (or should impose) a new test requirement -- namely that device drivers are tested on systems both with and without an IOMMU. While code that works on systems without an IOMMU is unlikely to notice the introduction of the IOMMU, the reverse is not true. If drivers were developed in the presence of an IOMMU, it is not unusual for them to fail on systems without an IOMMU, as the lack of an IOMMU often requires mappings to be made with multiple DMA cookies, especially for resources that page boundaries.
   

I've not had a chance to play with the new framework myself yet, but I look forward to doing so. Also, be aware that same feature set is coming soon for AMD platforms, see PSARC 2008/561.

audiohd pushed

The latest & greatest audiohd driver, which includes vastly improved support for a large number of codecs, suspend/resume support, and a generic "codec parser" has now been "pushed" into build 98 of ON. Many thanks to the Beijing audio team, who worked long and hard to bring this project to fruition.

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.

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

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.

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

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!

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.