Bug 5628

Created attachment 6615 [details]
dmesg output after crash

Created attachment 6616 [details]
lspci -v output

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). 
 

Created attachment 6738 [details]
used asound.conf

Is this issue still present in kernel 2.6.16.5?

Status update:
Yes, it still crashes with 2.6.16.6.
dmesg appended after crash.

Created attachment 7889 [details]
dmesg output after crash

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?

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

Hm, I don't understand why that patch can fix this Oops at all...

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?

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.).

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..?

He has _two_ soundcards:
- a PCI CM8738 that is working fine
- the onboard M5455 causing the problems

Yes, but the effect of the patch is nothing but disablement of the intel8x0 driver.

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)?

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 :)

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?

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.

Created attachment 7894 [details]
Fix Oops with ali5455 SPDIF-in

Could you try the patch above?

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!

Fixed in 2.6.17-rc4