snd-hda-intel-1.0.6p-8dkms not working for me

[Gary Gatling]

Greetings,

I did 10 re-installs of RHEL 4 update 4 on a test Precision 380 
workstation in my office. Of the 10 installs I did 6 failed (no sound) and 
4 worked. (Sound only works after a reboot but thats cool I guess)

I am using the 32 bit version of RHEL 4 because "opnet" doesn't work with 
a 64 bit install.

I did diffs on the actual modules that worked and the modules that didn't 
(snd-hda-codec.ko snd-hda-intel.ko) and found no difference at all. On all 
machines where sound did not work I did see LOTS and LOTS of messages in 
/var/log/messages like:

Oct 16 17:38:45 moreproof kernel: snd_hda_intel: disagrees about version 
of symbol snd_hda_resume

This happened without exception every time the rpm (sound) didn't work.

Here is a URL that points to the kickstart part that configures the 
precision 380 and makes it so that kudzu doesn't need to have someone 
standing there at first boot to type "enter" 3 times as kudzu "finds" new 
hardware such as the network card.

http://www.eos.ncsu.edu/hardware/pre-380-setup.txt

This script also unmutes the audio.

I install the snd-hda-intel-1.0.6p-8dkms.noarch.rpm using "at" near the 
bottom of the script because I found it never worked at all when I 
installed the snd-hda-intel rpm directly in my kickstart script.

It seems to be a lot happier when its installed when the machine is in 
run level 5 for some odd reason. So this script (/root/eos/fix-audio2) 
gets run 4 minutes after the install is finished and the system has booted 
for the first time. (atd isn't running at install time which is why this 
technique works)

So... am I doomed to have to send part timers out to check each and every 
machine when I upgrade to 2.6.9-42.0.3.ELsmp and have them test each and 
every machine? Then have them re-install 60% of the machines that sound 
doesn't work on? Then check again, repeat, etc?

I'm really getting frustrated with this problem. Should I call DELLs 
customer support number? Will someone there better be able to explain why 
this even happened with the kernel upgrades? I thought you guys were 
working with red hat to get these sorts of things into the mainline kernel 
at kernel.org so there wouldn't be any of this dkms stuff to deal with?

Thanks,

Gary Gatling      | ITECS Systems
ITECS, BOX 7901   | Technology Support Analyst
NCSU, Raleigh, NC | Email: gsgatlin at eos.ncsu.edu
27695-7901        | Phone: (919) 513-4572 (5B Page Hall)