Shortest Audio Driver?

Using my new framework changes (which have not integrated yet), along with changes in the framework designed to simplify drivers by providing certain ordering guarantees, I've been able to shrink a lot of the audio drivers (and in the process have also found a number of small bugs that I think ultimately were responsible for jitter and corruption). Ths simplest driver so far -- audiovia97, which is about as simple an AC'97 driver that can be, is only 686 lines. Several others are now less than 800 lines, and no longer need any locking primitives. As far as device drivers go, this is minuscule. In fact, I challenge anyone to identify a driver that fully services any "real" piece of hardware, fully supporting said hardware, in fewer lines of space.

(And in case you are wondering, a significant fraction of those 686 lines of audiovia97 is still comments and whitespace and even the 30+ lines of boilerplate -- the driver is written to be as readable as reasonably possible, at least to other device driver or kernel engineers.)

The forthcoming audio DDI will be about the easiest DDI for any kind of device driver in Solaris. Contrast that with the pre-Boomer SADA framework, which one could argue had the most cumbersome and painful DDI for non-nexus devices.

Hopefully the simpler framework will make it easier for others to provide new drivers, and result in far fewer "bugs" in the drivers. (And of course, the smaller drivers will result in more efficient use of kernel memory as well, although you are unlikely to notice that particular difference.)

(However, the complexity of the audiohd driver remains a serious thorn in our side -- and unfortunately the problem is made worse by a far-too-complex specification for the Intel HD audio system That said, the complexity in audiohd stems largely from offering too many codec configuration choices, and not from the part of the driver responsible for actually transporting audio data.)

Do you use IDN? (E10K inter-domain networking)

I was looking, and one of the legacy device drivers we still support is the Enterprise 10000 Inter-Domain Network. This is a memory based interconnect network that emulates an ethernet.

It occurs to me that we could update this driver to use the GLDv3, which would potentially have a significant performance boost for it. (Really, a better solution would be to create a new low level MAC type for it Nemo, but clearly that's probably too much pain for a product that is no longer shipping).

Anyway, I'd be interested to hear of any sites which use IDN on E10K class systems, and would like to see this (already high performance) network get another boost.

The other legacy SPARC drivers which are not GLDv3 compliant are:

• cassini (ce) (probably never going to be GLDv3, but that's another matter)
• gem (ge) -- this one could be easily converted *if* I had fiber cards to test it with, although there are political concerns as well. (It uses the same MAC controller as "eri", which I converted a while back.)
• scman -- This is used for the Starcat (E15K/25K) connection between the SC and domains. It is also based on the eri driver, but has some special hacks. I'm a bit paranoid about touching this one, but if someone really wants it to be GLDv3, please let me know. (This isn't supposed to be a high performance network!)

I'm not aware of any other non-GLDv3 device drivers remaining for SPARC, but if you know of any, please let me know!

New audioctl coming soon

I integrated a replacement for mixerctl (and also removed mixerctl) back in build 130. Well, build 130 is coming out really soon (I believe it is available internally in SXCE form now.)

I think therefore that it is time to provide more detail here about the new audioctl syntax:

NAME
   audioctl -    audio mixer control command line application

SYNOPSIS

   audioctl list-devices

   audioctl show-device [-v] [-d device ]

   audioctl show-control [-v] [-d device] [control ...]

   audioctl set-control [-v] [-d device] control value

   audioctl save-controls [-d device] [-f] file

   audioctl load-controls [-d device] file

DESCRIPTION
   The audioctl command is used to control various features  of
   the audio mixer and to get    information about the audio mixer
   and the audio device.

   The audioctl command operates on the following data types:

  device
      An audio device, such as "audiohd#0".   The subcommands
      that accept this do so as an argument to an option -d.
      If not supplied, then the default audio device is assumed.
      Any device node associated with an audio device will work
      as well, such as /dev/sound/0, /dev/dsp1, or /dev/audio.

  control
      A mixer control name, such as "volume".

  value
      The value of a control.  The specific format depends on
      the type of control.  Monophonic values usually use a single
      whole number between 0 and 100, inclusive.  Stereo values
      use a pair of such numbers (representing right and left
      channels.)  Boolean values indicate either "on" or "off".
      Enumerations take a single value of one or more names.

  file
      An ASCII text file of control settings.

Options:
   Each subcommand has its own set of options that it takes.
   However, some subcommands support the special flag -v, which
   indicates a request for more verbose output.

SUBCOMMANDS
   The following subcommands are supported:

   audioctl list-devices

  List all the audio devices on the system.

   audioctl show-device [-v] [-d device]

  Display general information about a device.

   audioctl show-control [-v] [-d device] [control ...]

  Display the control setting values for the device.  The named
  controls are displayed.  If no control names are provided, then
  all control values are displayed.

   audioctl set-control [-v] [-d device] control value

  Changes the value of a control to the supplied value.

   audioctl save-controls [-f] [-d device] file

  Saves the current state of all mixer control values to the named
  file.  The command will abort safely if the file already exists,
  unless -f is supplied.

   audioctl load-controls [-d device] file

  Restores previously saved state in the named file for all mixer
  controls.


ENVIRONMENT VARIABLES
   AUDIODEV     If the    -d and -a options are not specified,  the
       AUDIODEV  environment    variable is consulted. If
       set, AUDIODEV contains    the full path name of the
       user's     default  audio    device.

I expect there may be some questions or concerns about the new syntax. If they are not answered by the manual page above, please don't hesitate to ask me.

quick system identification

I am frequently needing to know "which system am I using". (I have trouble keeping track of which ones are which) -- i.e. is this the laptop, the Ultra 20, the whitebox, etc.

I had been using smbios a lot, but that's a bit awkward and non-portable to SPARC or systems that don't support smbios. Here's a quick script that can quickly tell me what model I'm working on. It works on SPARC and x86 alike. I have it stored in ~/bin/system -- it only works on Solaris of course. Feel free to borrow, reuse, whatever -- I hereby donate it to the public domain:

#!/usr/bin/ksh

sysconf=`/usr/sbin/prtdiag | head -1`
biosconf=`/usr/sbin/prtdiag | head -2 | tail -1`

sysconf=${sysconf#*:}
biosconf=${biosconf#*:}
sysconf=`echo ${sysconf} | /usr/bin/sed -e 's/^ //g'`
biosconf=`echo ${biosconf} | /usr/bin/sed -e 's/^ //g'`
if [ -z "$sysconf" ]
then
printf "BIOS: %s\n" "$biosconf"
else
printf "%s\n" "$sysconf"
fi

Sample outputs from a Toshiba laptop, a Sun V890, and a non-name Intel whitebox system:

TOSHIBA TECRA M9
Sun Microsystems sun4u Sun Fire V890
BIOS: Intel Corp. BX97520J.86A.2777.2007.0805.1747 08/05/2007

While the format isn't terribly parseable, its great for giving a quick assessment about what type of machine I'm on.

new aquarium lights

Some of you may know that I keep a salt water reef aquarium (210 gallon). Well, one of the challenges with such aquariums is lighting -- most corals need a large amount of high quality light to grow.

Most systems use metal halide lighting, which is extremely bright, and extremely hot. On my aquarium I've used three 250 watt MH lights, supplemented by a pair of 150 watt MH lights. (The 150s have been out for a while due to a bad ballast.) Yes, that's over a kilowatt in lighting. And MH lights have historically been considered some of the most efficient lighting -- i.e. most lumens or PAR per watt.

One alternative that has been up and coming has been LED based lighting. High power LED systems offer a lot of potential capabilities (although due to a patent problem that has put at least one company out of business and probably set the industry back at least five years, software based control of LEDs is only available on extremely expensive lighting systems -- systems costing thousands of dollars.

And until recently, inexpensive LED lighting simply did not exist.

I recently had cause to investigate this, as the bulbs in two of my 250s have died recently -- and I'm particularly unhappy with 250 watt MH lighting for several reasons: heat, problems with bulb fit (whoever designed the mechanical interface used for 250 and 400 watt double-ended MH lighting needs to quit mechanical engineering -- I've had numerous problems getting the bulbs to stay put in their "friction" based holding interface, and broken a couple of bulbs trying to increase tension so that they wouldn't fall out of the fixture), and power consumption (power in California is very expensive.)

Anyway, I'm happy to report that I found a good alternative. LED Wholesalers.com offers a 120 watt LED fixture intended for this application for just over $300. (They have an eBay store where the fixture can be purchased for under that, but with shipping and our ridiculous 9.25% CA sales tax, you'll still be over $300.) Compared to other options, this price is ridiculously low.

I put it on my aquarium yesterday, and comparing side by side with the remaining 250 watt MH fixture, I think the fixture "appears" to be about equivalent to a 250 watt MH. I've not measured it precisely, but the light appears about as bright as the 250 MH (the wife says brighter, but I'm not sure), although the spectrum is a bit bluer. If I had to guess I'd guess the spectrum to be somewhere around 18000K.

Anyway, I thought I'd post this here, since I think I'm one of the very early adopters of this. I'm going to monitor the health of my corals, and if it goes the way I hope it will, I'll be purchasing two more of these units to get full coverage over the entire aquarium. I might even purchase one for my 56 gallon tank. (I might supplement with another 100 - 200 watts of compact fluorescent at ~6500K though. That's still only about half as much power as my system previously consumed.)

I'll return to this post in the coming months to report my results as I get more experience with these lights.

Bad sound in Virtual Box in recent builds

Its been pointed out to me that if you use Virtual Box and Solaris guests with recent builds (say newer than 124), that you might get a bad sound in the Solaris guest.

Turns out that the problem is that the Boomer stack has increased its timing accuracy to a higher limit, beyond what Virtual Box can provide.

We're going to fix this properly soon... but in the meantime, you can just edit /kernel/drv/audio810.conf and change the play-interrupts to 30 in the guest.

This is CR 6901849 in case anyone is tracking it closely.

Jack of all trades, master of none

While I probably say this about other things (C++, perl), I think I've found something else it applies to -- the OpenSolaris Live CD.

The Live CD attempts to offer both a "Live Use" environment, and a "full" (for some value of full) installable copy of OpenSolaris.

The problem with this is that we have way, way too many things duplicated on the Live CD. For example, two copies of Mozilla, two copies of Evolution, and two copies of Thunderbird. (One copy each to run in the live environment, and one copy in packaged form for installation.)

This is crazy.

People who want to play around with an operating system don't need two different mailer packages. In fact, one could argue that if I'm going to use a Live environment, the CD is not going to be my method of choice. I'm going to want eithe a DVD, or (more likely) USB media where I can get faster performance and have more options. Trying to keep a live demonstration environment in the confines of a CD (or rather the space left on the CD after the installable portions), makes no sense at all. As a Live environment, I am going to want all the bells and whistles, and compilers too! (And -- perhaps most importantly -- office applications like Open Office, which don't fit in the CD right now.)

Conversely, there are those who just want to install the bits. The live media is just a vehicle to install from. Oh, there are potentially useful applications that can be present too, but they are always in support of installation. Having a web browser so that I can access my router's configuration, for example, or search for updated information about my hardware, is likely to be useful. But do I really need or want two different mailers? And klotski? PDA synchronization? Etc. This is crazy.

And its worse; because of the size of the Live "CD", we already have a situation where it does not fit on the CD. We have also sacrificed other things that, in my opinion, we should not have, in the name of "space". I'm a strong tcsh advocate, and its absence from the installation media is sorely felt, especially when installing to systems that don't have a Internet connectivity. I'm sure there are other similar things that could be the installation media if only there were space.

Well, there is space. Easily. We just need to be smarter about it.

Its time to separate the jobs into separate tasks.

• Live Media. (Live DVD, and probably also USB.) Give up on trying to do it in 700MB for a CD though. This should be sized for a single DVD, and have all the goodies, including OpenOffice. It should continue to offer installable bits as well.
• Install media. This should not have the Live environment, but have only those tools which are deemed supportive to installation. (Do include a web browser, but don't include games or a music player, for example.) It should fit easily within 700MB. I suspect that the installation media could even be merged into the AI media, to support a single disk that can do either network installation, or local CD-ROM based installation.
  

Eventually the 700MB limitation is going to be a problem even with a change like the above. I believe that we can go a lot longer with what we've got, if we don't try to force the jack-of-all-trades to fit into a shoebox, though.

sar graphical output - do you use sag?

In the process of trying to "clean house", one of the hiccups we've run into is "sag", which is used to generate graphical output from "sar" data. (If you don't use "sar" or "sag", you can stop reading now.)

sag generates Tek 4014 mode output, which can (through some contortions) be viewed either in xterm, or converted (using "posttek") to PostScript. The results are actually fairly unpleasant to work with, and rather ugly, as the results are generated through some rather ugly abuse of "graph" and "plot".

I'd like to eliminate sag altogether, because I believe far superior alternatives exist. One example is kSar, which is a Java application which generates a variety of graphs and has both interactive and scripted operation. (It can also process sar output from the Sysstat package used on Linux, or AIX which is a plus.) It can generate output in a variety of useful formats as well, making it useful in generation of web-based reports, etc.

If you use sag, and would be impacted by its absence, I would really like to know. I am operating on the belief that there are very few, if any, of you out there -- tell me otherwise if this case, please!

Specifically, are you using sag in programs or scripts? What does sag offer for you that kSar lacks? (Or would the transition to kSar otherwise be painful for some reason?)

Note that for the purposes of this discussion we can assume that I'd be making kSar available as an IPS package via the SFW consolidation, and that it can process sar data from any version of Solaris going all the way back to at least Solaris 2.6 (and likely all the way back to Solaris 2.0 or 2.1.)

nice ZIL device....

Working together with James McPherson, I've been able to get a driver for a really nifty device from DDRdrive -- see here -- working with OpenSolaris.



The device itself has interesting applications -- but I suspect the real killer application for it is in use as a "Logzilla" (ZIL) to accelerate synchronous write loads with ZFS. The only limitation on performance is the software and the single PCIe lane. (We're really right up against the PCIe single lane limit.)

From the driver perspective, its really interesting because it works with only modest changes to blk2scsa (which I'll be integrating into Nevada soon). The driver itself is tiny -- only about 950 lines of code. Its proven to be a great validation of the concept of blk2scsa -- while I never intended blk2scsa for use with high performance devices, I'm ecstatic that its as performant as it is. (Sorry, I can't post performance numbers here -- at least not yet.)

If you already have one of these devices, and want to test it in a non-production environment running OpenSolaris (no Solaris 10 yet!), please drop me a line. I'm willing to work with a few people to get some more testing done.

audioemu10k driver pushed

I just pushed the audioemu10k driver into Solaris -- it will be in builds 128 and higher. Here's what the flag day message said:

The push of CR 6539690 introduces support for audio for Creative Sound Blaster Live! and Audigy devices based on the EMU 10K1 and 10K2 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 ids pci1102,2, pci1102,4, and pci1102,8. This should be the full set of Sound Blaster Live! and Audigy PCI devices not already supported by the audiols or audiop16x drivers. It does not include support for any X-Fi devices.

This driver includes 5.1 and 7.1 surround sound support, and SPDIF support, for devices that are capable of it. It also includes support for the various break out boxes (Live! Drive and Platinum products), although it does not include support for MIDI or the infrared remote control found on such boxes.

I still would enjoy receiving test feedback, especially for folks who want to use it with unusual configurations or for more than just plain stereo output.

Taking myself off of laptop discuss

I'm tired of seeing bounce messages each time I reply to some thread on laptop-discuss@. The draconian list management policy is set such that when I reply to a message delivered to me, it always results in a bounce. This happens a couple of times a week when I try to reply to a message where I think I might have helpful information. (The bounces might have been due to a bogus attempt on my part to use a vanity opensolaris.org address in my subscription, I don't know. To be honest, I don't really care -- it should not matter. This has become a matter of principle to me.)

I think there is a way I can cobble my list subscription address to work, and there are solutions where I can subscribe multiple times to the list, but I refuse to go to ridiculous contortions because the list manager for this list still refuses to actually moderate the list.

(Mailman has both support for manual moderation of addresses that are not subscribed to it and the moderator can also whitelist addresses that he knows are from reasonable posters. This is the procedure I use for managing the several lists I maintain.)

Btw, this problem is probably going to impact nearly every Sun employee post Oracle acquisition, by the way, particularly if Oracle does header rewriting to rewrite outbound From: headers to be some @oracle.com address.

If you want my participation on laptop-discuss (and this will probably also happen to driver-discuss), then ask the list moderator to change his way of doing business. (Or perhaps, to actually start doing the real duty of moderating posts instead of setting a draconian policy and then ignoring it.)

SDcards and ZFS

I've gotten this question a few times. "Would SDcards make a good ZIL device?" "Would SDcards make good ZFS devices?" The answer to both is resoundingly no.

The reason for this is simple, and is the same reason you should never reformat SDcard media using your computer.

It boils down to the fact that you need to do some very "SDcard" specific optimizations when you layout your filesystems in order to get good performance. (The details for this are only available after signing an NDA with the SDcard trade association, btw.) Of course, general purpose computers use general purpose filesystem code, which is targetted for hard disks. So the optimizations, if there are any, are all wrong for SDcard media. (Note that this only matters when doing the initial filesystem layout .... i.e. when you are formatting the media.)

You can reclaim at least some of the performance you might have lost if you've made this mistake, by reformatting the media in your camera. But unless you have a much fancier camera than I do, your camera probably doesn't speak ZFS.

hacking perl to help my kids at school

So I have three kids, and they are all in elementary school. And right now all three of them are still trying to memorize their multiplication tables. Apparently the schools these days teach the kids to start by "counting up" (3, 6, 9, 12 ... etc for 3's) rather than going straight towards memorization as I recall we were taught.

So now they're still counting up, and have not memorized these basic facts.

So I had the idea that we need to give them sheets with practice problems, like the timed ones they do in school. I figure if they have to do this a lot, then eventually the facts will just "sink in".

This is when the wife pipes up: "hey can you write a program to do that?" (If only I had a nickel for every time the wife asked "can you write a program to do that?"...)

Well, this one was easy, took me about 20 minutes in perl. I wrote a script, "problems.pl" that dumps text file of some 144 problems suitable for sending to the printer. Here's sample output:

gdamore@pepper{18}> perl ~/problems.pl -r
    Practice: (# 650)
    Times tables from 1 to 12.
    All mixed up!


 4 x  7 =     5 x  7 =     1 x 10 =     2 x  9 =    10 x  9 =     6 x  7 =    

12 x 10 =     1 x  4 =     2 x  5 =     6 x  3 =     5 x 12 =    11 x  8 =    

 2 x 12 =     1 x  1 =     7 x  4 =     3 x 10 =     9 x 10 =     6 x 11 =    

Command line switches: "-r" to randomize the problems a bit (although every problem is given), "-s " to set the numbers to start from, and "-e " to set the ending problem (note that the second values are constrained from 1..12, because that's what the kids in school need), "-S " to set a seed (so can regenerate a previous sheet) and "-a" for an "answers sheet" (which is really only useful if you want the child to use it to check her own work. Because you should know all these facts so cold that you can check without an answer key, right? Right?)

Here's the code. Feel free to pass it around, give it away, modify it, whatever. It can be adapted to other kinds of problems pretty easily, I expect. Maybe you know a teacher or parent who could use this dumb little script. Maybe you just need to practice your multiplication tables on your own? I won't tell!

#!/usr/bin/perl

use Getopt::Std;

my $start = 1;
my $end = 12;

my @problems;

sub usage() {
        print STDERR basename($0), ": usage\n";
        print STDERR "problems: [ -r ] [ -a ] [ -s  ] [ -e  ]\n";
        exit(2);
}

srand();
$seed = int(rand(1000));

my $s, $e, $i, $j;
getopts('rs:e:aS:', \%opt) || usage;
$dorand = exists($opt{'r'});
$doans = exists($opt{'a'});
$start = $opt{'s'} if exists($opt{'s'});
$end = $opt{'e'} if exists($opt{'e'});
$seed = $opt{'S'} if exists($opt{'S'});

srand($seed);

$i = 0;
$s = $start;
$idx = 0;
foreach $i (1..12) {
        foreach $j (1..12) {
                $problems[$idx]->{'problem'} =
                        sprintf("%2d x %2d =    ", $s, $j);
                $problems[$idx]->{'answer'} =
                        sprintf("%2d x %2d =%3d " , $s, $j, $s * $j);
                $problems[$idx]->{'defined'} = 1;
                $idx = $idx + 1;
        }
        $s = $s + 1;
        if ($s > $end) {
                $s = $start;
        }
}

@new = ();
if ($dorand) {
        for( @problems ){
                my $r = rand @new+1;
                push(@new,$new[$r]);
                $new[$r] = $_;
        }
} else {
        @new = @problems;
}

if ($doans) {
        printf("\tAnswers: %s\n", $dorand ? "(# $seed)" : "");
} else {
        printf("\tPractice: %s\n", $dorand ? "(# $seed)" : "");
}

printf("\tTimes tables from $start to $end.\n");
if ($dorand) {
        printf("\tAll mixed up!\n");
}
printf("\n\n");
foreach $x (0 .. 1) {
        $idx = $x * (72);
        for $y ( 1 ..12) {
                if ($doans) {
                        printf("%s%s%s%s%s%s\n",
                                $new[$idx]->{'answer'},
                                $new[$idx + 12]->{'answer'},
                                $new[$idx + 24]->{'answer'},
                                $new[$idx + 36]->{'answer'},
                                $new[$idx + 48]->{'answer'},
                                $new[$idx + 60]->{'answer'},
                                $new[$idx + 72]->{'answer'});
                        printf("\n");
                } else {
                        printf("%s%s%s%s%s%s\n",
                                $new[$idx]->{'problem'},
                                $new[$idx + 12]->{'problem'},
                                $new[$idx + 24]->{'problem'},
                                $new[$idx + 36]->{'problem'},
                                $new[$idx + 48]->{'problem'},
                                $new[$idx + 60]->{'problem'},
                                $new[$idx + 72]->{'problem'});
                        printf("\n");
                }
                $idx = $idx + 1;
        }
}

Feeling Marginalized by OpenSolaris

The OpenSolaris project team has elected to leave my favorite shell (/bin/tcsh) out of the default installation media. There is "bug" on this, but I don't think it is getting any traction.

I'm feeling marginalized... it means that when folks first upgrade a system on SWAN to OpenSolaris, I won't be able to login unless they also remember to "pkg install SUNWtcsh". (This also creates a PITA for me on my network, but I've added a secondary user account ... "gdamoreb" with bash as its login shell to my NIS passwd file just so I can work around this.)

Anyway, compared to other decisions that this team has made, I definitely feel "marginalized". Look at some other stuff on the LiveCD:

• Not one, but two different e-mail packages (T-bird and Evolution)
• A number of "gnome" games that simply don't work at all.
• Two different versions of "vi" (/usr/bin/vi != /usr/xpg4/bin/vi)
• Unuseful "esd" (enlightenment sound daemon, not used by default)
• A number of not terribly useful device drivers ("pcelx", "pcram", etc.?) I'm going to work on EOF'ing some of these ancient device drivers.

I definitely feel like a 2nd class citizen, as a tcsh user in OpenSolaris. (zsh users, feel free to have the same opinion.)

If you feel the same way, please go ahead and put a comment in the bug report.

Call for testers: audioemu10K

I've just posted another update to the audioemu10k package. This update completely redesigned the underlying timing and interrupt support, and as a result it should work better with Suspend/Resume (without getting engine underruns.)

I've posted a webrev as well, and would really appreciate help with codereview.

Additionally, I've fixed the mixer a bit, to the point that I'm confident that a number of devices work perfectly. But some don't. Here's my test results so far:

• CT4670 -- (Sound Blaster Live!) verified 100% functional, including 4.0 surround.
• SB0100 -- (Sound Blaster Live! 5.1) SPDIF works, 4.0 surround works, no center/lfe output in 5.1 mode. Can't figure out why. (Would love to hear advice on this one.)
• SB0400 (Audigy 2 Value) -- works perfectly. Including full 5.1 surround, SPDIF output. I've not tested the side 7.1 channels because I don't have the necessary cable to do so.
• SB0350 (Audigy 2 ZS Platinum) -- surround sound on rear jacks works fine in 5.1 (can't test 7.1). My expansion box appears to be kaput though (doesn't work in Linux either), so I need help testing this from someone else who has a working one.

Those are the only devices I have on hand to test, but the driver can in theory support many many more. If you can expand the supported test, please let me know.

Thanks!

test audioemu10k driver posted

I've posted a test package containing the "audioemu10k" driver. (x86/amd64 platforms only).

There is also a webrev with the code.

This driver supports (in theory) a large number of cards from Creative. (Devices identified in prtconf -vp as "pci1102,2", "pci1102,4", and "pci1102,8".) I've not tested many of them though -- only the SB0100, CT4670, SB0310, and SB0360 have been tested, and I've been unable to verify SPDIF or expansion box functionality, but it should work.

To test, you'll need Boomer, which means build 115 of OpenSolaris or newer. I've only tested with build 124, and I recommend using 124 or newer if possible.

If you test it, I'd like to see the output from "cat /dev/sndstat", and as much testing of inputs and outputs (try different mixer controls, as well!) as you can. I'm hoping to integrate this code into Nevada in the next week or so.

hme shrinks by about 40%

I just removed about 40% of the code from "hme", by converting it to use the common MII layer. It also makes it use Brussels, and fixes an old bug relating to 10 Mbps functionality. Another net negative lines of code integration for me. I wonder if this confuses ohloh.net's accounting?

OpenSolaris on snv_124 Impressions

I've bitten the bullet, and finally installed "OpenSolaris" over my SXCE install, upgrading from build 105 to build 124 in the process. I thought I'd share some things I've noticed:

• Gnome's volume control Just Works, and doesn't show the legacy Sun device anymore. (Yay!)
• There is a 12 MB Core file on the CD ... er... too big... DVD ... image. (Oops!) Maybe someone was hoping the community would jointly debug the program that generated the core file. (gtk-update-icon).
• Still no /bin/tcsh installed by default. Fortunately easy to get off the network for this machine. (For other systems, not so easy. This really ought to be fixed.)
• AudioHD has a really, really annoying beep on this system. The beep volume control doesn't take effect until you lower it to 33%. (And then it gets really quiet.) This is a bug that I'll have to investigate further, there's probably some codec tweaking needed.
  
• Regular SunOS vi has been replaced with vim, which has an incredibly obnoxious bug. It doesn't scroll down properly, redrawing on the last line in the terminal window instead of the whole screen. This is IMO at least a P2 bug against the editor. The old editor in SXCE, while maybe lacking some neat colorization features and not being open source, at least worked properly.
  
• Trying to install CUPS using the package manager GUI fails with a horrible stack back trace. While the request is is made to report the problem with the stack back trace, there is no provision to save it or e-mail it. So alas, I don't have it anymore to post. It should be easily reproducible. (It looked like a problem relating to the SMF configuration.)

I have a lot more to do... so many things are at the moment still missing. But I think I'll be able to muddle on at this point. (The vim bug is going to really, really bug me though, because there isn't an easy workaround -- apart from just copying over the old vi from SXCE.)

Update: Turns out /usr/xpg4/bin/vi (which is what I had in my path anyway) doesn't have this problem. And its installed by default. Yay. But someone really needs to fix vim, because that bug is horrible.

Update 2: When I logged in using my old home dir, the Gnome panel which I had configured for auto_hide did hide itself. But unfortunately would not unhide itself with any mouse actions. The only way I could get it to unhide was to disable the auto_hide property using gconftool2. Unfortunately, it took a while to figure out how to use this.

Giving up on laptop-discuss@

Here's a message I sent to laptop-discuss-owner at opensolaris.org:

Okay, I've tried *three* different addresses to post to laptop-discuss@... each time the message bounces.

The addresses I tried:

gdamore@sun.com
garrett.damore@sun.com
garrett@damore.org

I give up. The list is *unusable* to community members, because of a draconian list policy that instead of just moderating reasonable attempts to post to the list just *bounces* them. This community (laptop-discuss@) will no longer be able to receive mail from me, despite the fact that I'm probably one of the more active contributors to the software that makes up core laptop platform support.

If you think your membership ought to be able to hear from me, then please make it easier for me (and for other people) who have a legitimate need to post to the list. Simple moderation with white and blacklisting can be used to achieve this.

- Garrett

For the record, the message I tried to post was:

I'm considering a case to remove/EOF the partial (incomplete) support we have for certain Tadpole laptops in Nevada.

I'd like feedback on this. Is anyone out there still using a Tadpole SPARCLE with OpenSolaris or Solaris Nevada?

The reason for this is the intention to remove support for graphics (its already not present in OpenSolaris). I never got enough cycles to finish the work to integrate power management or other mobility features for this platform (SPARCLE), and now it seems to be quite obsolete. We're talking about UltraSPARC-II (up to 650 MHz max cpu speed) systems here.

Would anyone here strongly object to just removing the support?

- Garrett

The bounce messages I received look like this:

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
laptop-discuss-owner@opensolaris.org.

The problem is that draconian list membership/posting rules make posting updates incredibly painful. If you think my contributions to the forum are or would be useful, please ask the list moderator to start actually moderating the list instead of just setting it on auto-reject. (At this point, I don't remember which vanity address I subscribed to the list using... at the moment, I'm just about to the point of not caring. I've already reached this point with driver-discuss@ - on more than one occasion I've simply decided not to keep trying to send a message to that alias because of the same stupid draconian policy.

why we might never support Dolby Digital

SPDIF (and AC3) are the (now legacy) ways that home theater systems are supposed to use to transfer high end surround sound to the receiver for amplification and distribution to individual speakers.

Many audio cards on the market can transport AC3 (aka Dolby Digital) or DTS compressed audio data over a digital cable (SPDIF). They can also transport 16-bit stereo PCM (uncompressed) to SPDIF.

Boomer can't decode or encode, or transcode, any compressed audio at the moment. While it might be nice if we could do this, there are significant and non-trivial hurdles to making that happen. Some are technical (such as computational costs and lack of hardware offload), and others are more legal (such as trademark, licensing, and patent considerations.)

So, Boomer could transport uncompressed 16-bit stereo over SPDIF. (That's all SPDIF has bandwidth for!) Which we support today in audiohd. And in the future we might extend this to other devices.

However some operating systems also support a pass-thru for compressed audio data, where data is taken from a source (such as a DVD application) and routed directly to the receiver without any changes. This works reasonably well, except that it adds a lot of complexity to make it work right, and you completely lose any control over gains or the ability to mix other audio sounds with the stream. (Want to get a notification of an incoming VoIP call while you are watching your movie? Too bad... you can't do that with AC3 passthru.) This mode is of such limited use that we're inclined not to support it at all -- its really only useful for media center PCs used in conjunction with home theater systems to watch DVDs. (And we already know about the various problems with watching commercial DVDs right? I won't talk about those legal problems here.)

The best feature for SPDIF is the ability to transfer 6 streams of data in a single cable -- using a lossy compression. The reduction in cables to tie this into your home theater system is really a good thing. But of course, we don't have an encoder, so we can't do that except in the pass-thru case we already said we weren't going to do. (So no 5.1 gaming via SPDIF for you... Dolby calls this Dolby Digital and all audio cards that support it do so in software only, which requires expensive licenses from Dolby.)

Fortunately, there are better options on the horizon, and this is where we want to spend our time.

One option is ADAT ("lightpipe") -- which can support 8 channels of uncompressed audio at 48 kHz. Its available on some motherboards even now. Supporting it would probably be fairly easy, although using ADAT might require some very high end audio equipment (ADAT is used in professional audio situations.)

A second, and far more accessible option, is the use of HDMI's audio channel. New motherboards (and some cards, such as the Asus Xonar HDAV) can support HDMI audio. HDMI supports 8 channels of uncompressed audio at up to 192 kHz. This is plenty for even the most demanding audiophile. And if you want more channels, you can always use a second HDMI cable! HDMI offers us the best audio capabilities without any compromises. (We can use it with mixing, volume controls, or use it in a bit-perfect fashion. We get full quality. And we don't have to deal with any of the licensing, technical, or legal headaches that accompany trying to get a real-time AC3 or DTS encoder working. ) So at this point, any investment spent in AC3 instead of HDMI on our part just looks kind of silly.

I expect that sometime later this year (or more likely next year), we will be looking hard at getting HDMI audio working with Boomer. (Note that I have no control over funding or project priorities -- so this is just a prediction, not a promise.)

audio driver enhancements

Okay, I've got some audio drivers that are basically ready to go, but which I'm trying to decide whether to integrate or not. Part of the problem is that integration of new drivers is a somewhat expensive process, and if there is no demand for some some of these, then I'd rather go do other things.

So, another straw poll. If you have one of these devices and you want a driver to test with, please let me know.

1. Cirrus-Logic/Crystal CS 4281 -- driver is ready to go, stereo only
2. FM-801 -- I think the driver will work, but don't have hardware at the moment to prove it.
3. C-Media 8738/8768 surround sound support (stereo already supported in OpenSolaris) -- this will probably be integrated at some point, but I can share binaries now if someone wants them.

Other drivers I can supply with just a modicum of effort, if there is demand:

1. Yamaha YMF-7 series -- driver not yet ready, but now I have hardware to work on it, if there is demand
2. C-Media 8788 - driver mostly ready, but no hardware, and its expensive hardware to purchase.

Note that I will be doing the driver for the oft-requested EMU10K (Audigy/SB Live!) devices very very soon. Don't bother asking me again about it; its pretty high on my priority list. Likewise, X-Fi is very very desired, but will probably be quite a while longer in coming due to lack of specs. Various VIA chips (Envy24HT, etc.) are in the pipe as well.

And of course, Sun Ray audio is very high priority. Stay tuned for more on that.

ohloh.net statistics

I notice that OpenSolaris has very few "users" listed on ohloh.net. Lets bump it up. If you use OpenSolaris, why not go ahead and create an account on ohloh.net, and indicate "I use this" for OpenSolaris.

While you're there, if you're grateful, you could grant kudos to your favorite developers. And if you have any contributions of your own (pushes to ON), go ahead and claim those to (search for your name or login in the "people")... it bumps your rank, and makes your "kudos" worth more when you deign to give them out.

ESS Solo-1 (audiosolo) integrated

I just integrated audiosolo -- it should be in build 125. :-) I think this driver might have set a new record for integration into ON. I started work on it Sunday afternoon, and integrated into ON on Tuesday evening. Proof that not all integrations into ON have to take forever. (Granted if this were NetBSD it probably would have integrated on Monday morning instead of tonight...)

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.