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.

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