Most recent kernel where this bug did not occur: 2.6.15-rc4 Distribution: Slackware 10.1 Hardware Environment: ALi M5455 onboard chipset Software Environment: gcc 3.4.4 glibc 2.3.5 Problem Description: Driver crash if included in the kernel, and is deactivated as module. Unable to play and record any sound. Steps to reproduce: Boot 2.6.15-rc6 on described hardware Appended lspci and dmesg output.
Created attachment 6859 [details] lspci -v output
Created attachment 6860 [details] dmesg output There is a kobject crash while trying to use the mixer (I guess).
I confirmed this problem. Actually this problem is not only in kernel 2.6.15, I also tried in kernel 2.6.8, 2.6.13, 2.6.14. All failed in those kernels.
Created attachment 6884 [details] lspci -v output
Created attachment 6885 [details] dmesg output
Forget to say, my previous attachment "dmesg output" is got in kernel 2.6.14. ------------ ... AC'97 0 does not respond - RESET AC'97 0 access is not valid [0xffffffff], removing mixer. ------------ So when I restart alsa service in my Debian sarge, it said: ------------ Shutting down ALSA.../etc/init.d/alsa: Warning: 'alsactl store' failed with error message 'alsactl: save_state:1194: No soundcards found...'. failed. Setting up ALSA.../etc/init.d/alsa: Warning: 'alsactl restore' failed with error message 'alsactl: load_state:1267: No soundcards found...'. done. ------------
In my case the RESET printk is harmless for previous kernels (up to 2.6.14 included). I can record and play sound. However, for these kernels, recording a sound gives a high frequency noise (very strident). This phenomenon disappeared with the 2.6.15-rc4 kernel, I was quite happy (in fact, some sounds still have a strident noise after sharp level change). But 2.6.15-rc6 simply crashes (if the driver is built in) and seems to be deactivated (mplayer / mencoder says "no sound"), even if the card stills appear in /proc. This may be due to a kernel change in kobject code (this is were it seems to crash when registering).
Christian, please do a binary search for the guilty patch: - try 2.6.15-rc5 - find the last good and the first bad git snapshot (between the last good and the first broken -rc kernel)
OK, I've done the binary search, and found the latest version that works: it's really 2.6.15-rc4. 2.6.15-rc4-git1 does not work anymore, neither 2.6.15-rc5, rc6 and rc7. There is nothing interesting in dmesg output (diff appended between both kernels). git1 patch doesn't seem to touch snd-intel8x0 module, however some things were done in saa7134, which I do not use (maybe there is a hidden dependency ?). It may be a modification in other kernel subsystems that have broken this driver (I'm still convinced kobject dumps in my first attachment (6860) are worrying, but I didn't checked if they were still present in rc7). By the way, I append the dmesg diff. And I confirm I do have these lines: AC'97 1 does not respond - RESET AC'97 1 access is not valid [0xffffffff], removing mixer. Unable to initialize codec #1 intel8x0_measure_ac97_clock: measured 50833 usecs intel8x0: clocking to 48000 in dmesg output, with every kernel, and even with -rc4, which works. Happy new year, CC
Created attachment 6912 [details] dmesg diff between rc4 and rc4-git1
Ehh, while rebuilding the rc7 kernel, I noticed an interesting warning from kconfig: Warning! Found recursive dependency: VIDEO_SAA7134_ALSA VIDEO_SAA7134_OSS VIDEO_SAA7134_ALSA Indeed, I seem to use effectively SAA7134, which was modified in rc4-git1 ! If this can help... I'm giving more info on what I'm doing... I have two sound card: one on my motherboard (intel8x0 compatible), and another (a CMIPCI). I also have a video card bttv 848 based, which has no sound mixer. Therefore, I use a cable to link the output of the bttv to my CMI card (just because before 2.6.15-rc4, recording from the line-in of intel8x0 card gives that annoying strident sound). Now, I noticed this sound disappeared, but I didn't changed the line-in to the intel8x0 (still some glitches, and because I need that second line-in to record from another sound source [a ADSL TV Decoder for info, provided by my ISP]). Now, when I want to watch TV from ADSL, I configure my video card to take the external video source, and want to hear the sound from the intel8x0 (not the CMI, on which the sound of the TV is plugged). I therefore use mencoder to record video from the video card and the sound from the intel8x0, and pipe the divX stream to mplayer to watch the result (yes, it works!) OK, it's quite complicated and may be simpler, but I also want to have a HDD recorder for the same price. My problem is that with kernel < 2.6.15-rc4, the sound is awful, and with 2.6.15-rc4-git1+, mencoder barks and says there is no sound card (I only have the CMI). It cannot record, and I have a video file without sound track. Therefore, the fact is I use Video4Linux, and it seems this brings back SAA7134 code (OSS too, btw). And I do not have OSS support in my kernel. I append the .config too for info. Regards, CC
Created attachment 6913 [details] kernel config file
Created attachment 6914 [details] drivers/media/video/bttv-driver.c part of the 2.6.15-rc4-git1 patch The recursive dependency is an unrelated issue (and already fixed in Linus' tree). Both your lspci output and your .config show that you aren't using SAA7134. Can you try whether this attachment that contains the bttv-driver.c part of the 2.6.15-rc4-git1 patch alone applied against 2.6.15-rc4 causes the breakage?
This patch, applied alone to 2.6.14-rc4, does break the sound. It is effectively (at least) bttv modifications that causes the breakage.
To be complete, my bttv card does have a mixer, but it is not a sound card. That is the reason I must use an external cable from the bttc card to a sound card line-in. If the bttv driver declares a sound card, it may overwrite my second card's config? I'm doing the inverse test: remove the bttv driver (from rc7 first, if it fails I'll test on rc4) and see if I can record sound from my DSL decoder. Wait a few minutes.
2.6.15-rc7 works without bttv (I managed to record sound only, with record - this is not mencoder anymore, but the sound card is detected now).
Christian, thanks for your testing. Mauro, can you look into this bug?
Last thoughts about this problem... before going to sleep ;-) kobject error disappeared in my last test (I guess the slot is free now that bttv is out). In my config, I used to compile bttv in kernel and intel8x0 as module. Compiling intel8x0 in kernel causes kobject crash (certainly due to the conflict). Either bttv uses an entry without reserving it (and intel8x0 conflicts, kobject find the problem and refuses intel8x0, be it initialized after boot as a module or after bttv in kernel), either intel8x0 doesn't select the right entry and bttv presence shows only the bug. I'm therefore still not convinced the problem is bttv related (I could swap CMIPCI and intel8x0 role to see, but that is not guaranteed and I'm fed up with that for today).
May it be related to irq stuff? Maybe bttv and i8x0 are using the same irq line. Also, what happens when both bttv and i8x0 are compiled as module?
The dmesg is in comment #2, and yes they do share IRQ 17.
Tested with all compiled as modules (very unstable, see below). If I load snd_intel8x0 first and snd_cmipci second, the sound is broken in cmipci. This not a problem related to snd_intel8x0 then, but rather to bttv. bttv is does not seem to be affected by the fact it is loaded after both sound modules. Loading snd_cmipci first, then snd_intel8x0 is the same as my config without modules. Removing modules snd_cmipci crashes very often, but I think this is another bug. This is true even if bttv is not loaded before. Should I report another bug against the snd_cmipci module? (several dumps appended).
Fixing minimum kernel version. Update user config: Slackware 10.2/Kernel 2.6.15/glibc 2.3.6/gcc 3.4.5
Created attachment 6926 [details] First crash at module removal
Created attachment 6927 [details] Second crash at module removal
Created attachment 6928 [details] Third crash at module removal This one seems to be identical to the first.
Status update: 2.6.16-rc2 Still broken for both sound cards (no recording if bttv present). Also tried routeirq option to get different IRQ routing, and tried to remove intel8x0 modules and use only CMIPCI sound card (therefore no shared IRQ between bttv and the sound card used to record): it doesn't help either.
I've tested a little more further, and dichotomized the breaking patch identified previously in comment #13, to see what had broken sound recording from my bttv card. I thought at first it was the change to compute the "t->rangehigh" of the tuner, since it could have caused a conflict, but it is luckily far more simple. This is the first change: - i->audioset = 1; + i->audioset = 0; which seems to simply disable audio support from my bttv mixer. Quite curious, I do not know if all cards are equals, but for my hardware at least, this single change breaks my sound recording. I restored the previous ligne (ie : setting audioset to 1 does fix my problem), and it works for both 2.6.15.4 and 2.6.16-rc3. Either this is a bug, or there must be a test depending of the hardware if other cards requires this to be null. I hope somebody could explain why this was modified in this way, and what was intended... I'm also changing the bug title, since it is a bttv bug and not a CMIPCI/intel8x0 bug. Best regards
Status update: Does not work with 2.6.16.6.
Update: Not fixed in 2.6.17-rc4
Update: still present in 2.6.17.6, and certainly (not verified) 2.6.18-rc2 since bttv was not changed in changeset. However my fix still works with those recent kernels. As somebody asked me more explanations, I restate it: Simply change 'i->audioset = 1; ' to 'i->audioset = 0;' in bttv-driver.c to make it work again.
Christian, What software app are you using? I've checked other drivers and audioset is left 0 on most drivers (only saa7134 really cares about it). It seems that this field is somewhat obsolete. From kernel POV, I see no reason why bttv mixer won't work whatever audioset value is used. Anyway, since the patch did a regression, I'm reverting the audioset change as you've proposed.
I'm using mencoder (pre7). I didn't checked if mplayer 1.0 rc1 still exhibits the problem, since I always apply my patch anyway. Maybe the software uses this field to check if the card has a mixer. I don't have other hardware to see if mencoder does the same with audioset=0. The mplayer command line is classic: mencoder -tv driver=v4l2:device=/dev/video0:input=0:freq=$CHANNEL:norm=$NORM:width=768:height=576:fps=25:alsa:adevice=hw.0:amode=1 -ovc lavc -oac lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=9000:keyint=25:acodec=mp2 $TIMELIMIT tv:// -o file.avi with $CHANNEL, $NORM, etc. fixed to reasonnable value for my country and what I want to record. Thanks for applying my proposal. CC