Crazy Sunday -- ESS Solo-1

I got kind of bored on Sunday afternoon, and decided to do a port from FreeBSD of the driver for the ESS Solo-1 card. (I got one of these cards shipped to me by mistake from a vendor that didn't know the difference between different chips.)

It was getting late on Sunday, but I was almost ready to test. I resolved that when the system panic()'d, I'd call it a night and go get some sleep.

Amazingly, the system never panic()'d. I think this is the first time that I've brought up a new device driver (with a lot of new code!) without crashing the system at least once. (Usually its significantly more than that!) Hence, this may be the only device driver I know of that is both functional, and has never been the cause of a system crash.

Well, I wound up continuing to hack during testing -- never did make it to bed, and now its pretty much done. I'll post test binaries if someone else wants them. I still have to test suspend/resume and quiesce. There is also a bug where the record channels are swapped. This stumped me for several hours until I finally realized that my channel remapping facility in Boomer isn't supported for input channels, only for output (playback). Guess I'll have to go back and add that feature in to Boomer. (Its a small change, and now I've got a need for it.)

The driver is called "audiosolo", and will only be supported for x86 systems (the hardware can't address past the upper 24-bits of memory, so its useless on SPARC). Its only capable of 16-bit stereo record and playback, but these cards are apparently still sold as very low-cost budget add-in boards. (They are also found on some systems.) Look for ES1938 on the chip.

If you want the driver, let me know and I'll ship out some binaries. It will probably go into the next build or so, as I have time to get through the C-Team paperwork. I'm not meant to be working this during the "day job", as I have other priorities at present. But it might be a nice bonus for someone anyway. :-)

NWAM and MII toxicity in build 123

Just a quick note.... we've discovered a problem where NWAM may not function if you have certain devices which use the "mii" module in build 123 of OpenSolaris. Hopefully the fix for this problem will be integrated today into build 124.

The problem is that NWAM won't see your wired "interfaces" as down, and as a result, won't default to using wireless.

Affected devices are afe, iprb, atge, dmfe and the yge beta test. The CR on this is CR 6880492. A webrev of the fix is available for the curious.

audiop16x driver integrated

From the HEADS UP message:

The push of CR 6878663 (PSARC 2009/384) introduces support for audio for certain Creative Sound Blaster Live! devices. If you have such a device, you can now enjoy audio playback and record support using your audio device. This driver includes 5.1 surround sound support.

Devices supported are identifiable by the PCI id pci1102,6, and are Sound Blaster Live! models SB0200 and SB0213. They have a chip labeled "EMU10K1X" (note the "X") on them. These were primarily marketed as Dell OEM versions of the Sound Blaster Live! family.

Enjoy!

audiols integrated

I've integrated the audiols driver into build 124 (actually I think this might have been the first push into snv124 -- thanks to jmcp for approving it so quickly!) From my HEADS UP message:

The push of CR 6875005 introduces support for audio for Creative Audigy LS devices. If you have such a device, you can now enjoy audio playback and record support using your audio device.

Devices supported are identifiable by the PCI id pci1102,7. Known compatible devices include Creative Audigy LS, Creative Audigy SE, Creative Sound Blaster Live! 24-bit, and Creative X-Fi Extreme Audio.

This driver includes 5.1 surround sound support.

Bugs for this driver should be filed in bugster using solaris/audio/driver-audiols.

Assorted audio cards needed

4Front has provided some drivers for me, which are nearly complete, but which need some attention. However, I am lacking hardware for a number of these drivers, and have not had good success finding many of them on eBay. If you have access to spare cards to donate, or even sell, please let me know.

Here's a short list of cards:

1. CS4281 (I tried to purchase one of these, but they shipped me an ESS Solo-1 instead!)
2. CS4280
   
3. FM-801 (ideally a 6-channel variant)
4. CMI 8768
5. CMI 8738 (6-channel, or even 8-channel varient)
6. CMI 8788 (these are high end cards, they can be purchased, but right now I'd have to fund this myself if I want to work on the driver -- its not a priority. This is typically the Asus Xonar card.)

There are probably other interesting audio cards as well.

It should be said that the recent work on some of these cards is occurring on my own time, since I have higher priorities (not soundcard related) during my day job, which is why its hard for me to ask Sun to provide funding for these things. (In the case of cs4281 and fm-801 cards, I've found them hard to even locate. Witness my failed attempt to purchase a CS4281. Taiwanese vendors consider these interchangeable parts. :-(

audiols works nicely on sparc

Just for giggles, I went ahead and tested it:

audiols/fortyfive> pfexec audiotest -5 /dev/dsp1
Sound subsystem and version: SunOS Audio 4.0 (0x00040003)
Platform: SunOS 5.11 snv_119 sun4u

*** Scanning sound adapter #2 ***
/dev/sound/audiols:0dsp (audio engine 1): audiols#0
  - Performing audio playback test...
    <left> ................OK
    <right> ...............OK
    <stereo> ..............OK
    <left rear> ...........OK
    <right rear> ..........OK
    <center> ..............OK
    <lfe> .................SKIPPED
    <5.0 surround> ........OK
    <measured sample rate 47952.00 Hz (-0.10%)>

*** All tests completed OK ***
audiols/fortyfive> uname -a
SunOS fortyfive 5.11 snv_119 sun4u sparc SUNW,A70

I'll go ahead and include SPARC support after all. Maybe someone with an Ultra 45 or 25 will like this.

AudigyLS Boomer Driver Posted

I've posted test binaries for the AudigyLS driver for Boomer systems. There is also a webrev posted. These are test binaries only! Use at your OWN RISK!

If you do use them, please let me know how it goes.

Thanks!

Surround Sound on SPARC?

I'm about ready to integrate the Audigy LS audio driver, which is a PCI add-in card that is capable of 5.1 surround sound. (I've been working on it in the "off" hours, as I currently have other higher priority projects that I'm working on while doing work on Sun's nickel; this explains why it has taken so long.)

I have one quick question: does anyone really want to have this work on SPARC systems? The only tangible advantages I could see for this are:

• If your internal audio device is busted, there is another alternative.
• If you have some compelling reason to want surround sound support on your SPARC system.

Right now because the effort to qualify and integrate takes a while, and because I hate the idea of integrating bloatware that nobody is going to use, I am not planning on integrating SPARC support for this driver. However, if at least one or two people speak up and tell me that this is something that they want, then I'm much more likely to take the time to do the work. (The driver should Just Work on SPARC, its mostly a matter of running the tests, which take a few hours.)

So, if this is something you want, let me know!

Community Contributions

I've recently (in the past week) integrated a small improvement from Roland ( so kernel code can use C99 booleans (supposedly there are performance gains for using this relative to boolean_t), and a major overhaul and conversion to GLDv3 for the legacy "dnet" driver from Steve Stallion.

I would like to thank both contributors for their patience. Neither of these was a particularly trivial integration. Steve in particular worked on this integration for quite a long time, due largely to the high cost of getting such a crufty driver to pass through NICDRV.

Fun With Rocketry

Well, today I finally got a model rocket set ... been wanting one since I was about 8 years old. Now that my son is that old, I finally can justify it. :-) The kids and I went to a park and set up 4 launches (well really 3, more on that later) of a single stage Estes rocket (A3-4T engines, IIRC ... basically about the smallest engines typically sold.) Total cost was about $30.

The kids really enjoyed it, and I can tell by the questions Timothy is asking that he's thinking about implementation -- he's definitely got the budding mind of an engineer. (How does the ejection charge work? What's the purpose of the recovery streamer? How do multistage rockets work? Etc.)

We did have one minor mishap, on our first launch attempt. Turns out that the rocket had wedged against the small plastic keeper, creating just enough friction to turn our launch into a static test. The engine burned a small hole, about 50 mm in diameter, right through the aluminum guard plate on the launcher; an amazing testament to the power of even these relatively tiny rocket engines. Needless to say, it definitely helped demonstrate the importance of all the safety measures I was stressing. :-)

The next three flights went off without a hitch. The product documentation says "up to 350 feet", but I think the peak heights looked higher than that.

For his 9th birthday in November, I'll probably invest in some other more sophisticated models. Its cool to be a kid again, but its even more cool to see your kid's eyes light up; who knew learning could be such fun!

Test Marvell Yukon 2 Ethernet Driver

I've posted a test version of my "yge" driver (Marvell Yukon Gigabit Ethernet, but it also supports some 100Mbps devices) up on OpenSolaris.org. Get it here -- get the file called yge-test.tar.gz.

There is a webrev posted too, if you want to beat your head against the wall.

If you do test this, be aware that many possible PCI ids are not in the installer file. If you want to test more, please do so (at your own risk). If you find that other devices either do work, or do not, please let me know -- send mail to garrett.damore at sun dot com.

Thanks, and enjoy! (I'm hoping to get this driver integrated into SNV 123.)

A Push A Long Time In Coming

I just pushed the changes associated with PSARC 2005/425, which is basically the removal of the script wrappers /usr/ucb/cc, /usr/ucb/lint, and /usr/ucb/ld. The fix will be in b122 of ON.

This is a good thing for people who build free software bits on OpenSolaris. For a long time, there have been complaints that /usr/ucb on your PATH was particularly toxic (some would say it was toxic anyway, but that's a different matter) -- autoconf scripts were frequently confounded by /usr/ucb/cc, which has done nothing more than generate a useless error message for most people.

So, /usr/ucb/ on your path, while not recommended, is at least no longer particularly toxic.

audiovia97 not as rare as I thought

So I was cleaning out my office.... (no jokes from the peanut gallery please!)

I was completely surprised to find that out of 5 old machines I was about to retire to the recycler, no fewer than three of them -- from totally different manufacturers -- one of them was Compaq Presario -- had integrated Via82c686 audio (which is supported by audiovia97.)

So if you've still got old Celeron's or PIII class systems around, there's a pretty good chance that you can get audio in OpenSolaris on them now.

Another way you know you're getting old...

When someone on facebook is confused and mixes up your H.S. graduation date with their birthday.

People born back when I was graduating high school are now graduates themselves.

Getting old sucks. But its better than the alternative.

ohloh.net

I found an interesting site; it tracks commits by developer, and potentially ranks them, using a "kudos" system. There's also a way to give and to receive "kudos". It also has some source code analysis for projects, though I don't necessarily agree with all that it does. (A project that is 50% comments is not inherently better than a project that is 10% lines... you can't judge code quality or readability or structure based on comments.)

Anyway, I just joined and made it aware of who I am... I have a "kudo" rank of 7. If anyone else here is using this service, I'd be curious to know about it. My account information is here.

Fast Reboot & Panic

I noticed that Sherry Moore just posted a blog entry about Fast Reboot.

I wanted to take a few moments to mention a few things, that I think folks should understand.

First off, the feature (fast reboot) is really useful -- for manually initiated reboots to perform administration (such as to reboot after installing new kernel bits or a critical patch), its wonderful to skip past the various hardware related initialization, and can really help with downtime costs associated with administrative maintenance tasks like patching.

This is especially true for systems with lots of peripheral buses (SCSI, Infiniband, etc.) that take a long time for low-level BIOS to probe and test. In such situations, BIOS initialization can consume several minutes. Reducing this to a few seconds is a compelling idea.

However, there are some gotchas that in my opinion people should be aware of when using the variant of this that gets used on panic().

• During a panic situation, all bets are off about kernel or hardware state. (This is why the code in the kernel called panic() after all -- it has deemed it unsafe to proceed.)
• So, the nice safe quiesce(9e) entry points are not guaranteed to be called. Hopefully they will be, but not necessarily.
• Some drivers may panic when they find hardware in a state that is beyond their ability to recover. So quiesce(9e) may be functionally unable to put the system back into a sane state.
• Some hardware simply can't restore properly without a low level PCI reset, which the current fast reboot code skips.
• If hardware is not quiesce(9e)'d properly, on the reboot, the new kernel can wind up in a situation where a device might be randomly scribbling (via DMA) to physical memory (this can lead to arbitrary data corruption of either kernel or user pages of memory), or might wind up with a stuck interrupt (which may exhibit as a hard hang of the machine).

Note that the above situations are not theoretical. I have hit these problems, involving various different bits of hardware ... certain framebuffers that require low level initialization, certain Ethernet parts that don't have a functional software reset mechanism, and a certain WiFi controller that can leave interrupts stuck.

However, all the situations described above are also quite unlikely to occur. They probably occur in fewer than 1% of all potential panic scenarios.

The upshot of this is that I would most definitely not use fast reboot on any machine that is in production or which has critical data. Do you want to Its a wonderful feature for kernel developers who trash their systems all the time and are accustomed to taking risks -- for such uses the shortened reboot time on a panic is a net win compared to the potential risks (which is virtually nil -- if a system I'm testing hard hangs or crashes a second time I can always just power cycle it), but in a production environment the expectations are different.

In such an environment, you really don't expect to see panic() occur (if it does, you're already on the path of a bug!), but when it does, you want to be 100% certain that you confine the potential damage and get back to a known safe (and good) state. This is why we panic() and reboot, after all. Eliding those time consuming steps of low-level initialization might at first sound like an attractive way to get to higher uptimes, but if you analyze the situation carefully, its a potentially riskier proposition that could (admittedly unlikely) cause much greater downtime.

Now that you know the concerns, you are of course free to make your own assessment.

If you do want to turn off fast reboot on panic (and I do recommend that you leave regular fast reboot on, as far as I can see there is no downside to making an administratively requested reboot go faster), then you can just use the following commands (which are taken from Sherry's blog posting):

        
    # svccfg -s "system/boot-config:default" \
               setprop config/fastreboot_onpanic=false
    # svcadm refresh svc:/system/boot-config:default

(Note that fast reboot on panic is enabled by default on OpenSolaris since build 112. However, since nobody should have deployed a system with this on in production -- we've had only development releases since then -- there is probably no urgency to go and immediately change your systems. Of course, that situation might be different if you're reading this blog post at some point in the future.)

Archived KCA 2009 Boomer Talk

As some people know, the KCA 2009 was streamed live. The video of my talk on Boomer was archived (as well as other talks) and is available on line.

You can watch it here.

Note that I highly recommend advancing to about 6:30 in the stream, because the first 6+ minutes was me struggling with laptop/projector incompatibilities. (Would be nice if the folks that posted the video could crop that meaningless bit out.)

Other thoughts I had from looking back and reviewing this (which I did for the first time yesterday):

• A live demo would make it more interesting.
• Test the equipment compatibility first when presenting.
• Turn off screen savers.
• Rehearse the talk before hand.
• Some points were repeated, which was unfortunate since I had to rush or skip other points.
• Practice talking more.. especially at the beginning it seems like I didn't know what to do with my hands.
• Don't be afraid to get out from behind the podium.
• The podium itself was poorly situated ... the exit sign above my head was particularly apropros framing.

I'd be happy to hear other constructive criticisms, whether on Boomer, the paper, slides, or my presentation style. I don't get the chance to speak in public often, so when I do I'd like to be better at it then I think I managed this time.

audiovia97 pushed

I've pushed the audiovia97 device driver. Those of you with Via 82C686 south bridges will be able to make use of your on-board audio in OpenSolaris builds 121 and beyond. Enjoy.

Boomer Paper at KCA

I presented a paper covering Boomer at Kernel Conference Australia 2009. I've made the paper and slides available for your enjoyment.

Off to Brisbane, Austrialia

I'm headed to Brisbane for the week -- I'm presenting at Kernel Conference Australia 2009. I hope to meet other like minded UNIX kernel nerds there. Maybe do some snorkeling as well, although its the off-season there. (But it can hardly be colder than the water in California...)

STREAMS and non-STREAMS in the same driver

Some of you kernel hackers may be interested to know about my case (PSARC 2009/380) that eliminates one of the ancient limitations of Solaris -- having STREAMS and non-STREAMS entry points in the same device driver. I've also implemented it and am waiting for the case to time out before I submit the RTI.

As part of this, I also implemented a set of changes to the audio stack -- the austr(7D) "speecial" node and driver goes away, and the Sun audio personality sheds about 1,000 lines of complexity. I'll be pushing those changes later, once I've gotten code review feedback. (If you review the changes, please let me know!)

mii related fallout

So there was some fallout from my mii push. Elxl devices had a nasty panic, which I fixed in time for build 119. Some older i82557 (iprb) devices had problems as well. The push for this fix went into build 120. To everyone affected, please accept my apologies. Build 120 should be stable for these devices.

Common MII/GMII layer integrated

Folks working with 802.3 (Ethernet) hardware (10/100/1000) can rejoice, as I've now integrated PSARC 2009/319, which provides a common MII and GMII layer for Ethernet device drivers. The first batch of drivers (iprb, dmfe, and afe) have been converted. This brings support for SunVTS netlbtest, dladm based link management, and even (for some devices) 802.3 flow control (aka Pause Frames) to these drivers.

I'll encourage folks working with other drivers to update their drivers to support the new framework. On average it cuts about 1500 lines from most drivers, and generally improves device functionality.

And yes, it works with Ethernet, even 1000Base-X should work (although only 1000Base-T has been tested.)

Any device that supports Clause 22 of 802.3 should work. Clause 45 (typically 10Gb) is not supported, however.

audiovia97 webrev posted

I've posted the webrev for audiovia97. This was covered by PSARC 2009/321. This is a driver for older Via 82C686 south bridges, used with 32-bit Via C3 and Pentium-III class processors.

The driver was written by 4Front (apparently building upon other Boomer work I've done). All I've done for this is simple packaging, cstyle fixes, and integration.

Let me know if you want early access to binaries! (You'll need Boomer or build 115 or later installed to use it.)

audiocmi integrated

I just pushed the audiocmi driver. Users with C-Media 8738, 8768, and 8338 devices can now enjoy Boomer using 16-bit stereo audio on these devices.

Note that while some of these devices can support multichannel surround, the Solaris driver for them does not support this kind of usage at present. If someone in the open source community would like to contribute support for this, please let me know.

proposal to change policy of SPARC deliverables

Historically, subsystems (drivers, etc.) were supposed to deliver on both SPARC and x86 platforms (and now amd64 as well) unless a really good argument was supplied. While I've long been a supporter of this philosophy, I think a time is coming to consider making a specific policy exception.

The problem I'm running into is with legacy PCI devices. Some of these legacy PCI devices can work SPARC. But devices that don't support 66 MHz frequently (but not always) have problems on SPARC workstations. The biggest problem is that many SPARC workstations have 32-bit 33 MHz slots that don't supply 3.3V. This affects quite a number of cards that require 3.3V power to operate. Some devices will operate with only 5V, but only marginally. I've seen a number of failures that I think can be traced to this problem, and now I don't recommend using PCI devices not specifically qualified for these platforms with SPARC systems. (Sun makes that same recommendation, btw.)

Furthermore, identifying suitable SPARC hardware can be a challenge. SPARC systems these days are slower than their x86 counterparts, yet for the most part remain more expensive, and there are few inexpensive options available for open source developers. And, SPARC desktop systems are effectively off the market -- Sun doesn't have any current SPARC desktop models for sale, and that's not likely to change anytime soon.

So what I'd like to propose is a policy change that recommends authors working on drivers for legacy PCI cards be given a blanket waiver for SPARC delivery. (Examples are recent NIC drivers such as "vr", "sfe", and "bfe", and audio hardware such as "audiopci", "audiocmi", and perhaps in the future drivers for Creative Audigy cards.)

I still believe that developers working with modern PCIe devices should deliver both SPARC and x86 binaries though. PCIe is available on last generation SPARC desktop (Ultra 25/45) hardware as well as current generation server products.

driver private headers

Some may have noticed in a few of my changes lately that I'm moving some header files around. This post explains the change (and encourages others to do the same).

Header files that are only useful to one subsystem (a kernel module, or driver, for example) should, IMO, only be located in the subsystem for which they are used. For example, do we really need to ship a header file in /usr/include/sys/ that has all the register definitions for the DEC tulip ethernet (dnet.h)? Wouldn't it be sufficient to have those definitions just where they belong, alongside the source for the dnet driver itself?

Locating the files for such subsystems in their own directory instead of a common directory (e.g. common/io/dnet/dnet.h instead of common/sys/dnet.h) has several positive ramifications:

1. It makes it readily apparent that the header file has no content needed outside of the kernel or subsystem. So changes can be more freely made (no userland dependencies, for example.)
   
2. The header file is not delivered to customers (except as part of the entire source code), shrinking the amount of disk space consumed on development workstations.
   
3. No exceptions entry is required to suppress the file from delivery - so the file is referenced in fewer places. (Fewer places to change if the file needs to move, be removed, etc.)
4. The header file is easier for humans to locate with the source.
5. The header file is faster for the compiler to locate -- it will be in the first directory searched - slightly faster build times. (If enough subsystems do this, it might start to make a noticeable improvement.)
   
6. The common include directory becomes slightly more manageable with each such change. (Big directories with hundreds of files are awkward.)
   
7. The file can't be used/abused by other subsystems (at least not without making such abuse obvious), because it really is in a private directory.

The upshot of all this is that a bunch of driver-private header files have been slowly moving out of uts/common/sys/ and into better locations. Hopefully other driver developers will consider doing the same.

driver.conf files considered evil

Just a quick note on driver.conf files that some device drivers deliver.

I believe that driver.conf files, and the tunables that are usually put in them, are for the most part, a byproduct of inadequate architecture The average driver should use no tunables in driver.conf properties.

As a result, I've started going out of my way to remove driver.conf files from device drivers for which I'm responsible. I think that even the "advanced" tunables (such as the interrupt rate used for audio drivers) falls outside the scope of what users should normally tune, and that delivering a configuration file is actively harmful.

One of Solaris' great strengths historically has been the approach to "self-tuning", so that lots of configuration is not necessary. I'd like to see that continue. The next time you think about adding a driver.conf property, consider carefully if there might not be a better solution. (Either self tuning, providing a default that works for everyone or nearly everyone, or using another system like Brussels to provide configuration overrides.)

(PCI devices in particular are very painful to configure with driver.conf... see the pci man page to find out why!)

audiocmi webrev posted

I've posted a webrev for the audiocmi driver. This driver supports CMI 8738 and similar parts. This is for Boomer, and I hope to get it integrated into build 117. If you want to test a binary, drop me an e-mail!

spwr opensource and GLDv3?

If you'd like the spwr driver to be open sourced and GLDv3 compliant (with VLAN support, link notification, dladm and ndd support, and the rest of the goodies), and have a few spare cards that you can give me, please feel free to contact me. I'm willing to do the work as a side project.

I'm also interested in obtaining 100Base-X fiber cards, and fiber cables (VF45 format), especially if someone also has access to the 3M VOL-N100VF+TX card (which is theoretically supported by "afe", but which I'm not entirely convinced works properly because I've never actually had a card on hand that I could test!) I need cards and cable... at the moment I have neither.

Note that this is not Sun commissioned work, but an interesting side project that caught my interest. If nobody replies with hardware, then its unlikely that I'll do any of the work.

Going to CommunityOne After All

Well, it appears that I'll be at CommunityOne (Monday only) after all! This is going to be a fairly big event -- the big event for OpenSolaris this year, I think. I'm looking forward to the chance to meet a bunch of folks that I didn't get the chance to meet previously. Hope to see you there!

hme for x86 RTI submitted

I've just submitted the RTI for hme. If the RTI advocate approves it in time, it will be in build 115, otherwise in build 116. This will allow you to use your old PCI qfe boards with OpenSolaris on x86 systems.

It also represents a significant simplifications of the code. Thanks to the folks who've helped with testing!

audio1575 driver for x86

This driver, with surround sound (5.1) support is pushed into Build 115. Stay tuned.

iprb suspend/resume and quiesce support in b115

I've just pushed an updated iprb with suspend/resume and quiesce support. Its still in the closed tree, but even so this improvement should help out folks who are stuck with one of these on their system board. Enjoy.

on the evils of auto-bounce/discard mailing lists

Some of you have already seen this rant from me. But I think its important enough to bring to the greater attention of the community.

Some mailing lists in OpenSolaris are configured to automatically bounce or discard messages sent from a mailing list that is not subscribed to that list. This is, IMO, a fairly toxic configuration.

At first glance, the idea seems good -- if your list only accepts member submissions, then you'll not have to deal with all the spam, and you don't have to moderate. The list can basically run from that point completely unadministered. Sounds good, doesn't it.

The problem is that this configuration is toxic to many discussions and to some users. As an example, I tend to get involved in many cross discipline conversations -- partly as a result of my membership on ARC.

And yet, my replies, often to important discussions about cases that might be interesting to certain communities, are often bounced back, because I simply am not subscribed to those lists. I don't want to subscribe to every list -- and I shouldn't have to in order to be an effective ARC member. A lot of times I just give up -- so communities are missing out on relevant conversation because of these configurations. This is a serious impediment to collaboration.

But it goes beyond that -- I'm also known by at least four different e-mail address -- one personal address, one @opensolaris.org, one first.last@sun.com, and one nickname@sun.com. People know me by all of those addresses -- so I'll be CC'd on conversations using any one of those addresses. When I reply, unless I am careful to remember to use the address I've subscribed to the list as, it will bounce on certain lists. Now its been pointed out that I can fix this by subscribing all of my addresses to the mailing lists I'm member of -- but who wants to subscribe to every list they're on 4 times? This is a serious impediment to collaboration.

The other situation is when someone has some new bit of information that they would like to bring to attention to a group of individuals, or ask a question, without having to be a member of the group. If I think I've found a bug in the TCP stack, should I have to be a member of networking-discuss@ in order to ask the group about it, or post the information? I suspect many such newbies hit the auto-bounce barrier for some of these groups, and just give up. The threshold for participation is simply too great. This is a serious impediment to collaboration.

So, all of these issues seem like they are negatively impacting collaboration. What is the solution?

Easy: moderate your lists properly. For heavily trafficked lists, it might take a few minutes a day to do this, but configure the lists to hold posts from non-members for moderation. If you identify a couple of volunteers to share the list password with, you can spread the chore, so that it is not too onerous for any one individual.

Those of you list owners with auto-discard/bounce set, please consider changing to a regular moderated list format. As attractive as the idea of a configuration where you don't have to do any work is, such configurations are actually hurting the group.

I'm done ranting about this for now. Thank you.

giving up on iprb

Due to snafus with the various legal departments involved, we seem to have hit another roadblock getting iprb open sourced. (Why is it that whenever lawyers get involved, everything seems to take five times longer than it otherwise would? Do corporate lawyers bill by the hour just like their normal "free-agent" counterparts?)

Rather than continue to wait for this to get resolved, I've decided to move forward and get some of the important fixes into iprb even though it is still closed source. Most notably, my changes allow iprb to support suspend-to-ram, and fast reboot.

I've submitted the RTI for these changes, so hopefully this will be in either build 115 or (more likely) build 116. As far as opening the actual source up -- even though there is nothing in the source that is not already made public by Intel -- I'm not holding my breath.

audio1575 driver for x86

I'm getting ready to submit an RTI to add M1575 (Acer/Uli) support to OpenSolaris. As part of the work, I've taken the M1575 driver from OpenSolaris (which was used for the SPARC Ultra 25, and 45 workstations) and added quiesce() and multichannel surround support. I'm told it works nicely with 5.1 channel surround. If you have this chip (e.g. an ATI SB200 motherboard), let me know and I'll see if I can get a binary to you. (You'll need to have Boomer RC3 or build 115 installed, though.)

7zip saves the day

I recently received a document that was LHA archived. I was struggling to find a suitable decompressor, since Gnome archive-manager complained that the format was unsupported.

Nicely, though, 7zip had no trouble uncompressing the file. And, 7zip is stock on all recent builds of OpenSolaris. Very cool. :-)

hme/qfe x86 and SPARC binaries

hme (and by extension qfe) cards can be used on x86 systems if you download the test driver that I've supplied. Just download, extract, and follow the directions in the README file.

I'm also interested in verification that the driver performs properly on SPARC; binaries are in the same archive. The code was significantly simplified, and I need to know it works properly.

Finally, I'm seriously in need of code reviewers. I can't integrate the changes without a proper review. If you can volunteer to help, check out the webrev that I have posted.

Thanks!

(Note: on x86 qfe cards will show up as "hme" devices... this is normal and expected. The "qfe" name is an artifact only found on SPARC systems for historical reasons... the actual qfe card consists of 4 hme devices behind a PCI bridge.)

Via Rhine driver integrated

Joost Mulders last night integrated his Via Rhine "vr" driver. While I don't personally have this hardware, I know it is very common. I did code review his driver, which I found to represent very tight and well-written code. Congratulations Joost!

Saurabh Misra is working on a home-grown "bfe" (Broadcom Fast Ethernet) driver as well, which also looks very good and should be integrating soon.

ALI 5451 southbridge AC'97 audio integrated

I just integrated support for the ALi Southbridge AC'97 controller found on certain x86 motherboards The necessary driver (audiots from the SPARC world, actually) is available on x86 platforms starting with build 115. For the moment this driver only supports stereo, but if someone has a multichannel configuration that they want to have supported, they should contact me and I'll work with them to get the testing necessary to enable this done.

Enjoy.

kaBOOM!

Boomer has integrated! Yay... this was a long road, and a lot of code -- one of the biggest projects I've worked on (and the hg push was far and away the single biggest push or putback I've ever done.)

Anyway, we were the first integration into build 115 of ON. See the flag day message for more details. Enjoy!

-- Garrett

preliminary audio driver for cmi8738

I've got a preliminary driver working for the CMedia 8738, 8768, and 8338 series of devices. This driver works with Boomer (you'll need RC3 installed, or -- hopefully -- Nevada build 115 when it comes out, and it seems to be working except for some issues with the record gain being a bit faint. (Hopefully I'll resolve those soon.)

The driver lacks support for advanced features like surround sound or jack retasking, mostly because I can't easily test them -- I have only an ancient 8738 -033 (stereo only) part available to me. (Also, it seems that CMedia has had some rather unusual changes with each revision of the chip, making proper support of advanced features such as SPDIF or surround sound a bit troublesome.)

So, that said, I'd like to hear from folks who have this part and can use a driver for it. If you want to test, drop me a line. Thanks.

Going to KCA 2009

It looks like I'll be in Brisbane, Australia for the Kernel Conference Australia 2009. The primary mission is to talk about Boomer -- the exact details aren't locked in yet. But I've been asked to chat about GLDv3 and driver porting in general as well.

Anyway, for those of you down under, I look forward to the chance to meet you. This will be my first trip south of the equator, and I'm looking forward to it. Hopefully my wife will be able to join me there as well!

boomer rc3, audio driver for ali5451

I've posted Boomer RC3 yesterday. It will be the last separate binary release of Boomer Phase I -- we're on track for integration into Nevada B115 -- C-Team Commitment review is on Monday.

That said, we've found one problem, which is of a P3 nature, which affects the ability of certain applications (audacity is the only one found so far) to record -- the record process doesn't start properly when triggered. I've got a fix for this, and can offer a binary to anyone who needs it for RC3. We've still not yet figured out whether this problem will be fixed in Boomer Phase I prior to integration, or just after integration -- but in either case it will be build 115 as well.

The other thing is that I've got a binary driver built for the audio controller found on the ALi 5451 southbridge. This is a somewhat older part, but folks might have them on certain motherboards. If you've got one, and you want a binary driver, let me know -- I'll be happy to supply one -- but you'll need to run Boomer RC3 or an OpenSolaris build that has Boomer integrated (i.e. build 115). We'll be handling this one as an RFE after Boomer Phase I integration -- probably also in Build 115. (Note that Dev at 4Front has already tested this binary for me, so I know its good to go -- it is just a recompilation on x86 of the audiots SPARC driver that is in Boomer.)

Anyway, keep your fingers crossed for our integration into build 115.

rtls open sourced!

I just pushed

6822752 rtls should be open source

It will be in build 113. There are some possible projects contributors could do involving that code (such as conversion to Brussels). Contact me if you're interested.

I've Arrived

Today something cool happened. Casper Dik asked me to review some changes he had to fix the Cardbus support in the pci nexus code.

What's so cool about that? Well, its the first time I've ever reviewed anything from Casper.

Casper, from back in the mid-90's, was kind of a folk hero of mine (and not just me, I think) back when I was doing system administration in my prior life at Qualcomm. I'd never have believed some 15 years ago that Casper would be asking me for code review.

Cool. :-)

Another Boomer Release Candidate Posted

I've posted an updated release candidate 1b for Boomer today, and you can download it from the files area.

The only remaining known P1-P3 issues in this release are a problem that affects users of TX (Trusted Extensions) and lack of BFU support. Obviously we're feeling pretty good about this release, and we're on track for integration in b115.

As usual issues should be reported using the Bugster category development/audio-ng/software. Alternatively, you can send mail to opensound-discuss@sun.com.

Boomer Release Candidate 1a Available

I've posted a release candidate for Boomer today, and you can download it from the files area. This release candidate includes USB support, and fixes for some critical bugs, so if you installed the beta, please upgrade.

There are still some known issues, but we believe we're quickly closing to being ready to integrate in Build 115.

Bugs should be reported using the Bugster category development/audio-ng/software. Alternatively, you can send mail to opensound-discuss@sun.com.

Enjoy!

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.