At Wed, 16 Jul 2008 11:16:32 +0200, Rene Herman wrote:
On 15-07-08 22:28, Landis McGauhey wrote:
Yes, I did delete '-dry-run'.
In fact, just to be doubly certain, I just re-ran the whole process and
I still worry a little bit, since if all's well, you should have seen the "patch -p1" command fail this time (it commenting that the patch seemed already applied) but I'll assume you did see that then. It's unfortunate that the problem with your card seems involved in a way which makes it fairly hard to debug this while not having the card locally to fiddle around with, adding delays between things ...
additionally ran alsaconf (and again there was a loud 'click' in the speakers when alsaconf loaded the driver):
# cat /proc/asound/AudioPCI/codec97#0/ac97#0-0= 0-0/0: 0x83848384 STS
... because, lovely, yet another variant.
Well, from The fact that this is repeated numbers, I guess this is a result of (still) wrong codec communication. Likely the previous number remains to the next read.
I guess my patch did something wrong, too -- at least, waiting for SRC up/down shouldn't be with sleep but a busy loop.
There is an interface problem between the ES1371 and (supposed) STAC9704 chips on your card and even though that MIGHT not be all the problem (even though the ALSA driver doesn't recognize your AC97 codec due to this, the OSS driver also drives it without any special quirks) this will need to be taken care of first.
With the card locally, the attached is the first thing I'd try. It makes the driver wait around a bit to have the codec recover from reset. Apply it as before, run "make" and "make modules_install" and re-load the snd-ens1371 driver with (as root) "modprobe -r snd-ens1371 && modprobe -r es1371 && modprobe snd-ens1371" after which ALSA sound may or may not work (test through aplay).
(note by the way that for now I'm foregoing any other problems you have with rebooting not loading the correct driver and such -- your dmesg indicated that the OSS es1371 driver was loading even though you said you blacklisted that, so just do the manual modprobe/modprobe -r stuff.)
Please also make sure that, after loading the newly patched snd-ens1371, there's nothing interesting at the end of dmesg -- nothing about timeouts and such. If there is something, please post.
Yeah, the kernel messages are really important. Some messages should appear if the codec access timeout occured. Then it can explains why zero is read for many registers.
Takashi