Bug 5628

Summary: snd_intel8x0 crash with Java application
Product: Drivers Reporter: Christian Casteyde (casteyde.christian)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: CLOSED CODE_FIX    
Severity: normal CC: bunk, tiwai
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.14.2 Subsystem:
Regression: --- Bisected commit-id:
Attachments: dmesg output after crash
lspci -v output
used asound.conf
dmesg output after crash
patch that should at least work around this issue
Fix Oops with ali5455 SPDIF-in

Description Christian Casteyde 2005-11-18 14:28:42 UTC
Most recent kernel where this bug did not occur: unknown  
Distribution: 
   Slackware 10.1  
Hardware Environment: 
   Athlon64/Ali chipset/M5455 audio device/C-Media Electronics Inc CM8738 
alternate audio device (lspci appended) 
 
Software Environment: 
    ShredderClassic chess program  
 
Problem Description:  
   Using a bit the chess program crashes definitely Java VM, with a kernel 
crash in sound device opening. Dmesg appended.  
 
Steps to reproduce: 
   I guess use any Java sound program, I'm using evaluation  
Shredder chess program, on such hardware.
Comment 1 Christian Casteyde 2005-11-18 14:32:51 UTC
Created attachment 6615 [details]
dmesg output after crash
Comment 2 Christian Casteyde 2005-11-18 14:33:28 UTC
Created attachment 6616 [details]
lspci -v output
Comment 3 Christian Casteyde 2005-12-01 11:17:11 UTC
Update: 2.4.15-rc4 still crashes. 
Giving latest/updated oops info below: 
 
 
Unable to handle kernel NULL pointer dereference at virtual address 00000008 
 printing eip: 
f88ad375 
*pde = 00000000 
Oops: 0000 [#1] 
PREEMPT 
Modules linked in: snd_intel8x0 snd_ac97_codec snd_ac97_bus 
CPU:    0 
EIP:    0060:[<f88ad375>]    Not tainted VLI 
EFLAGS: 00210292   (2.6.15-rc4) 
EIP is at snd_intel8x0_pcm_open+0xb5/0x110 [snd_intel8x0] 
eax: 00000000   ebx: f75e9c00   ecx: f740de60   edx: f75e9dd4 
esi: f0bbec00   edi: f75e9dd4   ebp: f157ddf0   esp: f157dddc 
ds: 007b   es: 007b   ss: 0068 
Process java (pid: 3673, threadinfo=f157d000 task=eff69580) 
Stack: 00000011 0000000b 00000000 f7529b40 f157de44 f157de00 f88ad74e f7db4d80 
       f75e9dd4 f157de24 c035e37b f7db4d80 f7529b40 f157de14 f7db4d80 f157d000 
       f7610200 f157d000 f157de74 c035e516 f4d14840 f7610200 00000001 f157de44 
Call Trace: 
 [<c01040df>] show_stack+0x7f/0xa0 
 [<c0104281>] show_registers+0x161/0x1e0 
 [<c010447f>] die+0xef/0x180 
 [<c0417e60>] do_page_fault+0x3c0/0x5ef 
 [<c0103d9b>] error_code+0x4f/0x54 
 [<f88ad74e>] snd_intel8x0_ali_spdifin_open+0x1e/0x20 [snd_intel8x0] 
 [<c035e37b>] snd_pcm_open_file+0x9b/0x100 
 [<c035e516>] snd_pcm_open+0x136/0x250 
 [<c034debb>] snd_open+0x13b/0x2b0 
 [<c016b7f8>] chrdev_open+0xf8/0x1f0 
 [<c01603e5>] __dentry_open+0x1a5/0x2b0 
 [<c0160608>] nameidata_to_filp+0x38/0x60 
 [<c016053d>] filp_open+0x4d/0x60 
 [<c01608b7>] do_sys_open+0x57/0x100 
 [<c016097f>] sys_open+0x1f/0x30 
 [<c0103305>] syscall_call+0x7/0xb 
Code: f8 89 86 08 01 00 00 a1 0c 26 8b f8 89 86 0c 01 00 00 a1 10 26 8b f8 89 
86 10 01 00 00 a1 14 26 8b f8 89 86 14 01 00 00 8b 47 58 <8b> 40 08 89 86 ec 00 
00 00 89 34 24 e8 0a 82 ab c7 83 3b 02 74 
 
The process didn't crash completely however (ie: Shredder was still alive after 
that). 
Oh, btw, I forgot to tell I'm running KDE 3.4.2, with arts started and using 
ALSA. I append asound.conf in attachment (I use dmix). 
 
Comment 4 Christian Casteyde 2005-12-01 11:19:05 UTC
Created attachment 6738 [details]
used asound.conf
Comment 5 Adrian Bunk 2006-04-15 06:16:16 UTC
Is this issue still present in kernel 2.6.16.5?
Comment 6 Christian Casteyde 2006-04-17 14:50:59 UTC
Status update:
Yes, it still crashes with 2.6.16.6.
dmesg appended after crash.

Comment 7 Christian Casteyde 2006-04-17 14:52:21 UTC
Created attachment 7889 [details]
dmesg output after crash
Comment 8 Adrian Bunk 2006-04-17 15:33:26 UTC
Created attachment 7890 [details]
patch that should at least work around this issue

Thanks for this information.

I'm not sure whether this is 100% correct, but if I understand this issue
correctly, this patch should fix the crash.

Can you confirm this?
Comment 9 Christian Casteyde 2006-04-18 10:25:29 UTC
Yes, this patch works nicely with 2.6.16.17 (with a 3 line offset when 
applied).
There is no more crash, and the software plays sound correctly now.

Thanks a lot!

CC
Comment 10 Takashi Iwai 2006-04-18 10:47:02 UTC
Hm, I don't understand why that patch can fix this Oops at all...
Comment 11 Adrian Bunk 2006-04-18 11:01:21 UTC
From Christian's dmesg:

...
ALSA device list:
  #0: C-Media PCI CMI8738 (model 37) at 0xc800, irq 18
...
AC'97 1 does not respond - RESET
AC'97 1 access is not valid [0xffffffff], removing mixer.
Unable to initialize codec #1
...

The code in snd_intel8x0_mixer() is:

        for (i = 0; i < codecs; i++) {
                ac97.num = i;
                if ((err = snd_ac97_mixer(pbus, &ac97, &chip->ac97[i])) < 0) {
                        if (err != -EACCES)
                                snd_printk(KERN_ERR "Unable to initialize codec
#%d\n", i);
                        if (i == 0)
                                goto __err;
                        continue;
                }
        }


As far as I understand it:
- the first codec is the non-ac97 one
- the first ac97 codec is failing, but in this case i is 1
- since there's no error, the kernel thinks initialisation succeeded, but during
the first access to the soundcard the kernel oopses when trying to dereference
substream in snd_intel8x0_ali_spdifin_open()


I don't know much about ALSA and I think my patch is only a workaround, but I
hope the above explanations help you making a correct fix?
Comment 12 Christian Casteyde 2006-04-18 11:14:29 UTC
Just in case it helps, here is the dmesg output when I modprobe the module 
after the patch:

ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 18 (level, low) -> IRQ 17
AC'97 1 does not respond - RESET
AC'97 1 access is not valid [0xffffffff], removing mixer.
Unable to initialize codec #1
ACPI: PCI interrupt for device 0000:00:04.0 disabled
Intel ICH: probe of 0000:00:04.0 failed with error -5

And effectively, the kernel doesn't crash when the soundcard is used by the 
software. Btw, I do not know at all why there is the codec initialization 
failure, but it never caused problem for other softwares (arts, mencoder, 
etc.).
Comment 13 Takashi Iwai 2006-04-18 11:19:27 UTC
Apparently the failure comes from the secondary codec.  The first codec must be OK.

I'm wondering wheter you can still use sound even after the patch at all..?
Comment 14 Adrian Bunk 2006-04-18 11:25:08 UTC
He has _two_ soundcards:
- a PCI CM8738 that is working fine
- the onboard M5455 causing the problems

Comment 15 Takashi Iwai 2006-04-18 11:29:51 UTC
Yes, but the effect of the patch is nothing but disablement of the intel8x0 driver.
Comment 16 Adrian Bunk 2006-04-18 11:37:26 UTC
Unless I'm misunderstanding Christian, the card he is actually using is the PCI
card.

I'm assuming the reason why initializing the intel8x0 card fails might even be
that it's disabled in the BIOS (but for some reason still visible)?

Comment 17 Takashi Iwai 2006-04-18 11:40:57 UTC
Well, but apparently BIOS doesn't disable the device.

The probe of the first codec is OK.  The secondary codec is likely a modem
codec, so it's normal that fails.  That is, the patch would effectively disable
the all boards with an AC97 softmodem :)
Comment 18 Adrian Bunk 2006-04-18 11:50:49 UTC
I always said my patch is only a workaround...

Is there any way to differenciate between two codecs on the same device and two
codecs on different devices?
Comment 19 Christian Casteyde 2006-04-18 12:04:52 UTC
Oh, I'm sorry, effectively, the sound does not work at all after the patch.
I didn't noticed it since I effectively use a PCI card, and I'm not using the 
mainboard chipset very often.

In fact, I use the i8x0 chip to record sound from my DSL video modem (which has 
video output capability), and as you wondered if this still worked, I confirm 
this is not the case.

The patch effectively completely disable the i8x0 chip apparently. It is not 
disabled in the BIOS at all, since I use it with my DSL video decoder. In fact, 
it is compiled as a module because with this configuration I can simply remove 
the module, this is the way I used the crashing software indeed.

The workaround is therefore useless, since I already could remove the module.
Comment 20 Takashi Iwai 2006-04-18 12:07:47 UTC
Created attachment 7894 [details]
Fix Oops with ali5455 SPDIF-in
Comment 21 Takashi Iwai 2006-04-18 12:08:24 UTC
Could you try the patch above?
Comment 22 Christian Casteyde 2006-04-18 14:34:23 UTC
This times, it works.

Shredder can start with the module loaded and without crashing, use the PCI 
sound card as usual, and I can record sound from the intel8x0 onboard chipset 
with mencoder (and pipe the result to play on the PCI sound).

I've tested sound output by plugging in my headphones on the onboard card, it 
works too.

dmesg output is unchanged since last time at module probe:
ACPI: PCI interrupt for device 0000:00:04.0 disabled
ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 18 (level, low) -> IRQ 17
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 50777 usecs
intel8x0: clocking to 48000
... and no more error after when used.

Thanks a lot!
Comment 23 Christian Casteyde 2006-05-12 11:22:54 UTC
Fixed in 2.6.17-rc4