well i have to tell you that i have never had as many problems with source based distorbutions as i did with rpm based systems/ i dont care what ibm does i will never ever switch back. they truely suck. including redhat. anway lspci and tell me the sound card. you might not have the module loaded. did you try alsaconf as root?

edong
Alsaconf issued some very fast messages before starting the semi-gui. I captured the stderr to a file, as :
modinfo: snd: no module by that name found
modinfo: snd: no module by that name found
modinfo: snd: no module by that name found

Then the semi-graphic screen comes up and tells me "no supported PnP or PCI card found"

lspci tells me:
02:07.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
Flags: bus master, slow devsel, latency 64, IRQ 16
Memory at fe2ff000 (32-bit, non-prefetchable) [size=4K]
Memory at fe100000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [40] Power Management version 2

And that is indeed my understanding, a cheap CrystalSound Fusion card.

/var/log/messages indicates:
"Jun 12 19:36:14 george kernel: isapnp: Scanning for PnP cards...
Jun 12 19:36:14 george kernel: isapnp: No Plug & Play device found"


The following appears at end of SYSLOG:
Jun 12 19:37:58 george modprobe: modprobe: Can't locate module char-major-10-134
Jun 12 19:38:00 george kernel: keyboard: Timeout - AT keyboard not present?(f4)
Jun 12 19:38:02 george kernel: keyboard: Timeout - AT keyboard not present?(f3)
Jun 12 19:38:02 george kernel: keyboard: Timeout - AT keyboard not present?(f4)
Jun 12 19:38:04 george kernel: keyboard: Timeout - AT keyboard not present?(f4)
Jun 12 19:38:16 george modprobe: modprobe: Can't locate module sound-slot-0
Jun 12 19:38:16 george modprobe: modprobe: Can't locate module sound-service-0-0
Jun 12 19:38:16 george modprobe: modprobe: Can't locate module sound-slot-0

(i am intrigued by the kbd messages...mine is a Logitech connected by USB, and seems to work!)
Thanks for your help!
George

P.S regarding the other issue, IBM's DB2 is my livelihood, and they have chosen RPM-based packaging, so a Linux that uses another native packaging system presents difficulties to the install scripts etc.. I have discussed this in another thread, but changing the scripts - as recommended by IBM didn't seem to work. After much sweat and blood, I had to convert the rpm files using (obscure?) rpm2tgz Slackware command, and then use its pkgtool GUI, or the native commands like upgradepkg etc....It took me quite a while to identify all that, after teaching myhself the ins and outs of rpm, and then realized that SlackWare's implementation of rpm was...imperfect...I kept getting segmentation faults... IBM even has an article on its DeveloperWorks Forum explaining the modifications one needs to make to the scripts (force off dependency checking, etc.)...this was as a a result of encountering issues in a customer's Gentoo MYSQL installation, converting to IBM's DB2 UDB, but they do not work with my Slackware 9.1!
You can read it here:
http://www-128.ibm.com/developerwork...dm-0403wright/
In other words, the fix was limited to a very spefic distro. The method I just mentioned is the only guaranteed one. This then raises the question of does the DB2 install script do more than simply lay down the filesets, and - if so - what is one missing by doing what I ended up doing with Slackware? In the end, I have it all working, but only after going down many nooks and crannies of rpm packaging.
For me, the issue is establishment of a sandbox environment that most closely resembles that in use in Corporate America, regardles of my own personal preferences between distros and packaging strategies, etc....

i understand and i sometimes cant find the package that i need accept in rpm format, so i just rpm -i package and it works fine. sometimes you have to upgrade your rpm package, but works. anyway.

seems that you dont have the sound card built as a module in the kernel. lsmod would help, but before we start playing ping-pong with that. check in /lib/modules/whatever/kernel/sound/probably pci anyway you get the drift see if you can find your sound card module, i think it will be called snd-cs46xx. then try modprobe snd-cs46xx. if that loads it then you are golden. you will then be able to run alsaconf and it will find your pcibus sound card and alls good. but if it doesnt, which i doubt it will cause hotplug wouldve taken care of it, you need to build the module. you would then:
su
password:
cd /usr/src/linux-2.x.xx.xx #or cd /usr/src/linux should work unless you changed the symlink
make menuconfig
#navagate to ( this depends on the kernel 2.4? 2.6? anyway youll figure it out) sound, pci, put (M)
#Cirrus Logic Sound Fusion the one that matches yours---> you can also high light the one you think
#and go to the help thing and itll give you better details.

then cp .config /boot/config-2.x.xx.xx-snd
make mrproper
cp /boot/config-2.x.xx.xx-snd .config
make menuconfig #again to save the config file
#exit and save
#2.4.x would say
make dep && make bzImage modules modules_install
#2,6,x would say
make && make modules_install
#wait
# when done
cp arch/i386/boot/bzImage /boot/something-2.x.xx-snd
cp System.map /boot/System.map-2.x.xx-snd
#as you guess the x's are just for whatever your kernel version is, and also you can name the
#bzImage whatever you want
#use your fav text editor to edit /etc/lilo.conf so you can boot the kernel
#run
lilo
reboot

then hotplug should take care of it, but if not
modprobe snd-cs46xx


hope it helps at all. let me know what happens.

edong
Mnay thanks for the special effort.
What I did was run depmod -a (per Documenation "modules.txt"), and then modprobe cs36xx, as U suggested; it reported on loading both the cs46xx and a codec (ac97-codec). "Modules.txt" talks about some modules "piggybacking on others', so if you loaded umsdos, then msdos would also be loaded. I guess that is what happened here.

I have sound, and an audio CD plays, but the volume is extremely low. To tell you the truth, this is not a major issue for me, since this is a sandbox machine for DBMS software.

The only other glitch I observe is than when booting - I think at the end of rc.S, at the exact time that rc.modules is invoked, I get a series of warnings about each of the 5 or so entries which are not commented out (network card, printer, agpgart). As best I know, these are built into kernel, or demand loadable. In any case, I have the correct functionality, despite these warnings of modprobe failures. Inexplicably these messages do not appear in syslog or messages (or dmesg). Again, its not vital. I just feel that grasping why I get these modules would better my understanding. I guess I don't understand exactly when "demand loadable" modules are - in fact - loaded, and the relationship of that process to the rc.modules file.
Thanks
George

the errors are cause the modules arent there cause you have them built into the kernel. so when the file trys to modprobe them it looks in /lib/modules/blablabla and there is no this or that and it cant load it, but you still have functionality cause they are built in. make sence? anyway try running alsamixer, as user, and set the mixer levels, then run alsactl store to save the settings. see if that fixes the volume. i could be wrong on the alsamixer as user, but i think you can. if not try as root. you get my drift.

Edong23
Thanks again. Yes, these modules are probably built in to kernel (it's hard to check, no, except perhaps by looking at .config?), and so modrprobe tries to load when they are alread complieled in kernel? In which case perhaps I should comment them in rc.modules???
Is the reverse true? That if they are NOT builtin, that is defined as modules, then they MUST be uncommented and loaded at boot as directed from rc.modules? Perhaps the make process does this himself? I would presume so....
I will purse the sound recommendations (I forgot to add that alsaconf still fails, but I will try the others suggestions, alsamixer alsactrl. As I said, the sound thing is not vital, but nice to have...).
George

Yes, you can take a look at .config and see if they have a Y (built-in) or a M as module.
You can comment them or simply left them there, I don't comment those lines because I still have the original kernel, and in case I want to boot it, I should leave those lines.
The reason why the make process don't comment it, is because the kernel is not dependant on distribution, and the init files may vary from one to another.

Nice to see you've made this so far.

i agree with gbonvehi. there is no need it only takes about a gazillionth of a second for the system to notice there is no module then it posts it to you and that is it. since it is not causeing any problems, i would leave it alone.

Thanks guys. And in the interests of ever onwards and upwards, I aks again if I can (without pain) upgrade from 9.1 to 10.1, and remain with the hip crowd....I appreciate that the "party line" may be to go to V10.0 first, but it seems to me that these are relatively minor upgrades, kind of like "FixPaks", and that one can skip one. I ask as I have d/loaded the 10.1 CD's (bing the now "current" release), and would rather do it once, instead of twice. Less is best..
I realize that Patrick V's Upgrade Notes go from 10. to 10.1....
George

well honestly i bet you can do it. just get all the packages from the slackware site, and use pkgtool to install them all. but you ahve to go in order to get the a and d package sets right. you have to do gcc first, i think, then like make, i think, then something else. you know you ahve to get a then d first i think. it would just be better if you backed up your files and formatted and installed from the 10.1 disk. but how bout this. i never ever had a problem with slackware from install, til 10.1. lots of issues actually. not in slack itself but the upgrades to the packages. caused my intel sound card to sound garbled with esound. i tried everything in my power to fix it, and probably couldve if i downgraded alsa-driver and esound themselves, but there were more issues than that so, i just install old faithful 10. for now. 11 looks to be promising.....

edong -thanks. Some time ago I d/loaded 10.1, but didn't see any (endorsed) roadmap for this migration (form Patrick), so I am now in process of d/loading to two ISO CD's for 10.0. I do have his UPGRADE.TXT, and yes, there is a prescribed sequence (glibc, pkgtools, etc...).
I'm just a little paranoid about the changes to /etc, even with a backup being taken..he provides a script to install .new config files in /etc, and local changes then need to be added to those. Does this mean every chane one has made hasd to be identified and re-inserted into the .new files, (which presubaly then have to be renamed? I can't belive this. I am really not sure that this means.....I come from a tradition of backward compatibility...what used to work will still work, with upgraded software, unless specifically directed to make designated changes....
George

edong - just one other question.
I'll take your advice and just try and go to 10.0, given the problems you have observed with 10.1

But recently, I have independently upgraded a couple of suites, outside of SW package management system, specifically, I did removepkg PERL, and installed the most recent ActivePERL. Second, I got the most current X (this was part of a long saga of upgrading to the current kde, which failed, and required X, which still failed, so I backed out the kde and re-installed from 9.1), leaving X in place, working fine.

My concern is that an total upgrade of 10.0 will clobber the more recent X (the most current, 4.5.0), perhaps rendering the entire windowing system unusable (which has happened to me), and is a thought I don't relish. This is clearly an issue when one installs software "outside" of the endorsed mechanism. BUt clearly it can be done, and may well be desirable. In any case, I guess, I need to take some kind of preventative action.....I am reluctant to removepkg X (all of them) without kniwing if this will remove the entire X system ; alternatively one could simply not upgradepkg the X packages, which kind of complicates Patrick's recommended command:
upgradepkg --install-new /root/slackware/*/*.tgz (assuming the lot has been copied to that directory) pr his "UPGRADE.TXT'
Hmmmmmmmmmmmmm
George

4.5.0?!?!?! i am using xorg version 6.8.2 so what is 4.5.0? same thing though. just upgrade to 10 then build the newest xorg from source. dont use the slackware packages.

Edong
The current XFree86 release is version 4.5.0 which was released on 16 March 2005. All of its documentation (man pages, release notes, etc.) can be found here.
http://www.xfree86.org/releases/rel450.html

Edong - further to earlier reply, these are the packages in the "X" directory of slackware of the 10.0 download:
x11-6.7.0-i486-4.tgz x11-fonts-misc-6.7.0-noarch-1.tgz
x11-devel-6.7.0-i486-4.tgz x11-fonts-scale-6.7.0-noarch-1.tgz
x11-docs-6.7.0-noarch-1.tgz x11-xnest-6.7.0-i486-1.tgz
x11-docs-html-6.7.0-noarch-1.tgz x11-xprt-6.7.0-i486-1.tgz
x11-fonts-100dpi-6.7.0-noarch-1.tgz x11-xvfb-6.7.0-i486-1.tgz
x11-fonts-cyrillic-6.7.0-noarch-1.tgz

So clearly, there is a different naming convention in place, between the SW package (tarballs) and the XFree86 software (now at 4.5.0 as of March 2005).

I'm just not skilled enough in the ins and outs of the vagaries of Linux software packaging to know how to do it best. If I knew how, I could uninstall what I have from X itself - but I have no procedure to do so: the X tarballs came with an Xinstall.sh script (which was quite nice, actually, the XFRee86 4.5.0 installer), but not a corresponding uninstall.

Alternatively I could install all the SW software EXCEPT the X directory (and hope I am not missing something that might be needed): this also means running the upgradepkg ---new-install ...../*.tgz one by one, so to speak, and omitting the "X" directory, from that sequence.

Finally, I could forget all about it, worry less, and just install the lot, and hope that conflicts would be resolved! (As in: "What, me worry"?)

****Separately, I am intrigued by Patrick's item 6 of his UPGRADE.TXT HOWTO file, when he refers to changes which "might" need to be made to config files, and the .new incoming config files, and the copying of existing files to *.bak. I am afraid I cannot make head or tail of his meaning. And his English is pretty good, and so is mine, and I am not a moron. In fact, I have been a Systems Pgmmer on and off, since 1980 on the largest computers in the world (Honeywell, IBM), and I just cant grasp what it is that the user must do with his existing configuation files.
George