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