SuSE 8.2 Linux Distribution and Soundblaster 16

From Chris Gianakopoulos

Answered By: Benjamin A. Okopnik, Chris Gianakopoulos, Kapil, Jason Creighton, Les Baron

Hello Gang,

[Ben] Hey, Chris!

Here is my final observation with the lates SuSE 8.2 Linux distribution. I have a Creative Labs Soundblaster 16 (not a clone but the real thing), and the YAST2 configuration tool does not properly set the hardware up properly (or it does and the chosen driver does not interoperate properly with my card). The user will be led to believe that the card is set up but, no sound will be heard from the speaker. Yes, I even played with the volume control (via the mixers).

When I did a cat on /dev/sndstat, there was an the DSP and some other thing that I cannot remember were not activated. Rather than wrestle with things, I created the following script to activate the sound stuff.

#!/bin/bash
/sbin/modprobe sb io=0x220 irq=7 dma=1 dma16=5 mpu_io=0x330

[Ben] You could also do this by simply entering the module name and parameters into "/etc/modules". Everything in there gets auto-loaded (at least under Debian - SuSE might be a bit different) by "/etc/init.d/modutils" on startup. In fact, IIRC, I had this exact entry - params and all - on my old laptop.

echo "sb io=0x220 irq=7 dma=1 dma16=5 mpu_io=0x330" > /etc/modutils

No need for a separate script.

Note that I am using the module sb.o rather than the other one (I think that it was sb_16.o) that YAST2 chose. Normally irq=5 is the common setting; I chose irq=7. The other parameters are fairly standard for a soundblaster.

This information is also available in

/usr/src/linux/Documentation/sound/Soundblaster

That's all!

[Chris Gianakopoulos] Thanks Ben! I tried that too. I was toiling whether or not to just put the entry into /etc/modules.conf. That's how my previous distribution (SuSE 6.4) did it, and that way worked also. The new distribution did not have all of the sound card entries in /etc/modules.conf, so I was scared to put my stuff in. <also grinning>I keep my old distribution manuals because they still have lots of good info (especially pertaining to modprobe).

I'm gonna try your (and standard) way of doing it!

[Ben]

Well now... "modules.conf" is a different animal altogether. I've tweaked it a couple of times via all the crud under "/etc/modutils" and running "update-modules", but I can't say that I like it much or even trust the damn thing. It's too apt to bite.

Oh, I don't know that it's the standard way - although it may be - but it's what I've been using for a number of years now, and it works. Other than the modules.conf mechanism, I don't see the whole module-loading thing as being all that complex.

Ahhh yes. We'll give it a test and see what happens. I've had pretty good luck in the previous distribution (SuSE 6.4).

You're right. The module-loading is cool. The more that I learn the less black magic things appear to be. It gets simpler and simpler as I use Linux more and more. Of course, Linux is not black magic. It's a work of art!

[Kapil] The recent kmod/ptrace bug seems to indicate that the "coolness" of autoloading kernel modules (a la /etc/modules.conf) comes with a price. It is probably safer to load modules at boot time using "/etc/modules" and then turn off modprobing with using kernel capabilities or some other mechanism.

Of course, you can continue autoloading if (a) you apply the relevant patch to Linux 2.4.20 or (b) if your machine is not in danger of attack from local users or (c) security is not an issue

[Ben] Sorry to hear that you got bitten. Someone on Bugtraq suggested what seems like a really good solution to the whole ptrace() problem when it originally came up - add a single line to the kernel that fails out of the call if the user is not part of group "ptrace". This seems like it would be trivial to implement, and would be transparent to the average casual user.

[Jason] Interesting, but how would the kernel know what uid is in the "ptrace" group? Something in the /proc filesystem?

[Chris]

I think that SuSE fixed the ptrace problem in their 8.2 distribution. The source of that info is at

https://linuxtoday.com/security/2003032502126SCKNSS

It will be interesting to look at the kernel source to see if the fix is really there.

[Ben] Nope - via the standard permissions mechanism. It's all easily accessible; take a look at "Reading the Persona of a Process" in "libc.info".

Some folks thought that only UID0 should have access to "ptrace", but I thought this method gave a lot more flexibility while maintaining a good level of security. It still takes root to add a user to a group.

[Jason] But user group names are purely userspace, right? So the kernel has no idea that the name of group X is. So, we either force "ptrace" to be a certain group ID (Not a very good plan) or somehow have it configurable, probably via the /proc filesystem.

[Ben] I don't think it would be all that difficult to do a lookup in "/etc/groups" - not that I remember it being proposed that way. I don't remember the exact code snippet that the guy showed, but it was only two or three lines long. If I had faster access, I'd go dig around on securityfocus.com and pull it up for you. You might want to give that a shot yourself; shouldn't be too difficult.

[Jason] That not the point! An easy way to win any argument is to claim "that's not the point" over and over again, even when it is the point.

Seriously, it would be ugly to introduct a lookup like that into the kernel: AFAIK, the kernel does not currently depend on anything like that in userspace, save for a few things, which are configurable. (Like the path to the modprobe binary.)

[Les Baron]

Hi SuSE generally uses alsa, have you tried alsaconf on the commandline??

[ChrisG]

I don't think that I did on my desktop. I think that the only thing that I tried was Yast2. I'm pretty sure that Yast2 uses alsaconfig to detect my sound card which I know that could not be achieved automatically. I will give alsaconfig a try.

[Les Baron]

Typing alsaconf in a terminal will bring up a dialogue ad ask you about your card it is seperate to Yast2 and is included in the alsa package, there have been times when I have upgraded alsa (not in an rpm format) and yast2 no longer recognizes my SoundBlaster live however alsaconf sets it up.

[ChrisG]

I tried alsaconfig about a half an hour ago. It recognized my legacy card configured /etc/modules.conf, and even started its sound stuff. I was able to use wavplay and listen to different wave files. Cool! Then, when I rebooted the system, the sound did not work! Darn! I have to investigate the difference between the startup via alsaconf and the way things happen when booting the system.

The modules do load when using wavplay with .wav files (I know - I can just cat the file to /dev/dsp, I think), but no sound occurs. One might ask which modules get loaded? Do all of the ones that I need get loaded? I will investigate and figure out answers to those questions. I could just use my existing sb.o stuff, but I do have a challenge to conquer!

[Les Baron]

The sound card is muted when you first configure alsa you will need to start a mixer and adjust the volume. You can also stop and start alsa by typing rcalsound stop or start.

Meet the Gang   1   2   3   4   5   6