Bug 5760

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