Hey,

Before I start, I've read multiple threads on this forum (and also Google'd many pages), most of which suggest CHMOD'ing /dev/dsp and so forth, which I've tried myself many times now. None of the solution suggested in other threads seemed to correct the problems that I'm getting... so here goes:

Background specs on my system (laptop):
Model: HP Compaq NX9005
Onboard sound: ALI 5451

I upgraded from the 2.4.22 default kernel in Slack 9.1 to the current 2.6.5 kernel, the configuration process went fine. I selected ALSA and all its options as modules (since I thought that everything was modular in 2.4.22), and selected my sound card (the ALI 545, very top of the PCI sound cards list in menuconfig), then built the kernel and modules.

Upon restarting, I find that I have no sound. I tried playing some songs with amp, but it gave a 'broken pipe' message. I didn't think that was very helpful so I tried madplay, which revealed that permission to /dev/dsp was denied. Here's where I did what all the other threads have been suggesting

chmod 755 /dev/dsp

also tried 666 660 a+rx and other variants (yeah I know what the numbers/letters mean)

This rectified the problem to a point, where I could now play songs and such. If I restart the system, and try again, I get the same permission denied to /dev/dsp, but if I look at the flags... ls -l /dev/dsp they're exactly what they were the last time I changed them! If I do a chmod again, the problem is rectified, even if I haven't changed any of the permissions at all!

I've also tried chmodding /dev/sound/dsp which is where /dev/dsp points to, but this always seems to get reset to crw------- when I restart (don't know what changes it, is it automatic?)

Now here's another problem. In gnome 2.6, using kernel 2.4.22, the mixer applet and sound properties were working fine. If I've chmod'd /dev/dsp, I can use the volume control to change the volume without a problem, but if I use the mixer applet (set to change PCM volume) I can see the volume dragbar slowly edging its way back down to 0. I don't know whats causing that, at first I thought it was a stuck key or somthing (but can't see that happening, since multimedia keys change the volume differently).

So basically I'm left with having to chmod /dev/dsp (even though when I chmod it, I'm just setting exactly the same permissions it already has, to get it working) at boot, and no working mixer applet.

Oh, btw, I've tried getting the latest alsalib and alsautils packages, and yes, I've run alsaconf, alsamixer and alsactl store/restore. The problem seems to reside with the /dev/dsp permissions at some point, and I have no idea what to do about the mixer applet.

Any suggestions? Thx

well, on my Slack 9.1 box, /dev/dsp is a symlink to /dev/dsp0 and
/dev/mixer points to /dev/mixer0
Now, on your box why is "dsp" in its' own directory?? AFAIK Slackware does not "screw up" the file structure like this............
unlike redhat and mandrake!!

On my Slack the dsp* and mixer* block devices are at /dev/snd or /dev/sound.
Aoh, you should perhaps look at your fstab if there is a /dev line. If yes, add a correct umask in the mounting options it could help.

Oh of course! I guess that could explain the chmod permissions constantly changing on /dev/sound/dsp -- devfs acts in a similar way to /proc ? But also there are actual physical files in /dev?

Maybe part of this problem stems to the /dev file system, I did enable support for it in the new kernel, but I notice devfsd running on my system...

ps ax | grep dev
/sbin/devfsd /dev

edit:
I don't have a /dev line in my /etc/fstab...

chmod 666 /dev/mixer*
chmod 666 /dev/dsp*
chmod 666 /dev/snd/pcm*

If you are running devfs you are going to have sound problems with alsa until you properly configure devfs...
I tried devfs but it was very problematic even when properly configured. When running devfs if you have not configured it to restore settings you make like chmod on a dev they will be lost when you reboot or open and close gnome. devfs mounts over the /dev which is still there but accessed through devfs.
Configure files are located in the /etc directory. devfsd.conf and modules.devfs
If you wish to use devfs you should check these out as well as the HOWTOs and website
http://www.atnf.csiro.au/people/rgoo...ocs/devfs.html

I ended up dumping devfs and had to make several repairs on the devices and /dev interfacing something the docs an devfs stated it would not effect. I would error to caution on using devfs as it is rumored to being phased out of the kernel.

Hmm, thanks Nichole_knc, I guess devfs is active because of the kernel selection? I haven't gone out of my way to run the devfsd daemon, so I guess that'd make sense.

Linux.tar.gz, if you read my original post, you'd know that I already tried it. I would have used dsp* but I've already checked and there isn't any dsp0 dsp1 etc, just /dev/dsp. Thanks anyway.

I'll try a recompile without the (depreciated) /dev support, hopefully that'll sort it.

Once you do remove the devfs from the kernel you will have to redo alsa
I suggest getting the new alsa sources and compiling them local..
http://www.alsa-project.org/
I am running v 1.0.3

Maybe you can elaborate more?

I just did some quite foolish things (which I just resolved)

After removing /dev support from kernel, I noticed that /sbin/devfsd was still being loaded... by /etc/rc.d/rc.S no less. Looking at it, a simple chmod -x /sbin/devfsd would do the job. I restarted (just to make sure), and because devfsd wasn't being loaded (and thus not activating things in /dev), /dev/hda1 seemed not to mount properly and I was thrust into maintenance mode where I couldn't change it back, since I only had read-only permissions. I booted up from the slack CD and tried re-installing the devs package (containing all the /dev devices), this didn't solve the problem, I had to chmod +x /sbin/devfsd again before I could boot properly.

So I'm back in the same position again, but this time with no /dev/dsp and devfsd still running. If I install the devs package again, they all get removed at reboot.

Do I need to keep /dev support in kernel but remove devfsd?

edit: I tried making the latest alsa drivers too, they didn't do anything at all really... (noticable anyway)

devfs works in 2 modes new and old nameing schemes refering to /dev of your machine.
When you build it into the kernel you must also pass a commandline command to the kernel for devfs.

devfs must be removed from the kernel both devfs and its related run at boot select (n) for both.
Before rebooting to a new kernel you MUST remove, rename or other wise get rid of initctl located in the /dev directory.
Then check your /etc/fstab to insure that the original /dev are there i.e. /dev/hda. If you see /dev/hd/host0/bus0/target0/lun1 or something there about then devfs rewote to the devfs naming scheme and you must rebuild your /etc/fstab and a few devices.
Once you have done this you will still have some problems as devfs screws up the sym links in the /dev directory.
As stated above you will have to re-install alsa and doing so from the slack disk will not work because it is missing a ./.sh file that will fix the sound devices that have been changed by devfs. Otherwise if you do not use this ./.sh script the devfs premissions that it sets remain when the new install of alsa is done. OR you can be bold and delete or hand edit many /dev devices and rebuild by hand alone.
For alsa you will need:
alsa-driver
alsa-lib
alsa-oss
alsa-utils

Make and install in that order. The ./snddevices will be located in the alsa-driver directory and it is ran after you make install the drivers.

You may also find that you cd will not work and you will have to mknod a new sym link in the /dev for it or use a raw /dev/hd# in the fstab for it.

Now this is the quick version. If you step blindly into the night you can expect to bump your head.

And I am also assuming you are just a 'newbie' to slack and that you know your way around the GNU OS and linux kernel. Why? Because fixing your system after devfs ran in new naming scheme set-up is not for the faint-hearted. It requires alot of reconfiguing and if you are not sure of what you are doing you can make a worse mess of things. IF you are new to linux/unix and this is a new install that has not been completely configured then you should skip everything and do a re-install.
You should also READ the HOWTOs and the suggested references in the kernel configure BEFORE you do something.
One of the main beauties of linux/unix is the level of configurability. Linux/unix OSs are not PnP and if people expect that they should stick to Windors.
I use linux/unix on older boxes that people discard. These boxes run as fast as 1ghz counterparts running Windors and these boxes run faster on the net than any of my Windors boxes. Do note that the Win boxes are also tweaked for the fastest possible speeds. (yes you can hack the win OS)
I wish you luck in your endeavor to repair your system... If it is a small box you may be just fine but if like a monster of mine with 4 harddrives, 2 each vid and sound card, 3 network cards and highly customized you have your work cutout for ya. Do the Dew and schedule the next 2 days on your box...

Thanks for that reply

I kinda wish I'd read it before now, I was up til past 5am trying to resolve the problem (at which point I literally fell asleep waiting for the kernel to compile again). I don't really know what happened, but (exactly as before) I disabled devfs in the kernel, removed the executable flag from devfsd, restarted (went into slack boot CD again), installed the devs package again, rebooted into the new kernel and it was fine. I did have to remake the drivers though, I had some crazy unresolved symbol error.

Either way now it works again, I was able to modprobe in the snd_ali5451 module and even after rebooting again, and the /dev/dsp permissions remain and the Gnome mixer applet retains/shows the correct settings. I would run the snddevices file in the ali drivers folder, but I think as it stands, since it's working again, it's probably best not to push my luck and potentially cause a cascading situation for myself. Don't fix it if it's not broken, right?

The only thing I can think is that I originally didn't copy the new kernel to /boot (though I'm sure I did)... I shall bear in mind your suggestions, paticularly the initctl one, just incase.

Many thanks

U R welcome...
I went through it myself....