> perhaps this means the severity should be lowered I can't speak to that. I'm not a member of the Debian kernel team. I'm just an ordinary end user who happened to notice a reference to the same kind of sound chip that I have and thought I might be able to help.
The problem, as I see it, is two-fold. First, there is apparently a bug in the snd-cs4232 driver that causes a kernel oops. That bug has apparently been fixed in 2.6.27. But in your situation (and mine), that driver shouldn't have been loaded in the first place. There is another problem that requires a design change to fix, and I don't know how it's going to be addressed. The idea behind the hot plug system is that kernel modules would be given aliases corresponding to the device ids that they are to be drivers for. These device ids can be listed by lspnp (in the pnputils package), lspci, lspcmcia, etc. If the hot plug system finds a kernel module with an alias which matches a device id that it has been able to detect, it loads that kernel module. That works most of the time. Unfortunately, Crystal Semiconductor used the same device id, CSC0000, for too many dissimilar devices. There are therefore three different drivers that have this alias: snd-cs4232, snd-cs4236, and snd-wavefront. In any given situation, only one of them should be loaded. The question is, which one? It is currently the design of the hot plug system to load all drivers that have an alias matching the device id. That means it tries to load all three of them. Either some additional smarts must be added to the hot plug system to figure out which one is the right driver in this situation and load only that one, or else the drivers themselves need to be smarter, so that they won't touch a sound chip that another driver should be used for. And that's not a bug: that's a design change. In the meantime, the work-around is to blacklist the drivers that you don't want. This is not too bad when you're INSTALLING Linux, provided that you understand what's going on and how to work around it. A smarter installer could solve that problem. But how would Debian Live systems, which must figure out everything on the fly, know which driver to load? The kernel people need to take a look at this. In a perfect world, it would be nice if Linux knew how to configure ISA PnP devices on older IBM ThinkPads too, such as the 600. It is apparently done in some kind of non-standard way. But I'm not holding my breath. Anyway, I believe that you can get full functionality out of your CS4237B sound chip, even under the standard Lenny kernel, if you read my web site carefully. It won't happen automatically. But with the right configuration steps, it can be done. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org