Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Recently I updated my system (testing) from alsa-headers and alsa-lib from 1.0.8 to 1.0.9_rc2. After that all my Alsa apps start to fail generating an error like this: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c01e7ef2 *pde = 00000000 Oops: 0002 [#4] Modules linked in: snd_pcm_oss snd_mixer_oss snd_atiixp_modem snd_atiixp snd_ac97_codec snd_pcm snd_timer snd_page_alloc radeon drm usbhid ndiswrapper CPU: 0 EIP: 0060:[<c01e7ef2>] Tainted: P VLI EFLAGS: 00210202 (2.6.11-gentoo-r4) EIP is at memcpy+0x1e/0x39 eax: 00000010 ebx: db84f300 ecx: 00000004 edx: 00000000 esi: cd6f7edc edi: 00000000 ebp: bfffccf0 esp: cd6f7eac ds: 007b es: 007b ss: 0068 Process alsaplayer (pid: 30253, threadinfo=cd6f6000 task=cc0c1590) Stack: ffffffea ffffffea cd6f7eec e09a28f8 00000000 cd6f7edc 00000010 db84f300 e09a3630 db84f300 cd6f7edc 00000050 00000006 00000000 00000000 00000000 00000005 00000001 00000000 00000000 00008002 00000000 00000000 00000000 Call Trace: [<e09a28f8>] snd_timer_user_append_to_tqueue+0x40/0x49 [snd_timer] [<e09a3630>] snd_timer_user_params+0x21c/0x221 [snd_timer] [<e09a381d>] snd_timer_user_ioctl+0xdf/0x1f9 [snd_timer] [<c015f507>] do_ioctl+0x53/0x7a [<c015f6ef>] vfs_ioctl+0x65/0x1d4 [<c015f8a3>] sys_ioctl+0x45/0x6a [<c0102da9>] sysenter_past_esp+0x52/0x75 Code: fd 31 c0 c3 31 d2 b8 f2 ff ff ff c3 90 83 ec 0c 8b 44 24 18 8b 54 24 10 89 74 24 04 89 c1 89 7c 24 08 8b 74 24 14 c1 e9 02 89 d7 <f3> a5 a8 02 74 02 66 a5 a8 01 74 01 a4 89 d0 8b 74 24 04 8b 7c <4>PCI: IRQ 5 for device 0000:00:14.5 doesn't match PIRQ mask - try pci=usepirqmask PCI: IRQ 5 for device 0000:00:14.6 doesn't match PIRQ mask - try pci=usepirqmask I downgraded to 1.0.8 and now everything is Ok, but I did like to inform about this to the dev team Reproducible: Always Steps to Reproduce: Start any alsaplayer or artsd Actual Results: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c01e7ef2 *pde = 00000000 Oops: 0002 [#4] Modules linked in: snd_pcm_oss snd_mixer_oss snd_atiixp_modem snd_atiixp snd_ac97_codec snd_pcm snd_timer snd_page_alloc radeon drm usbhid ndiswrapper CPU: 0 EIP: 0060:[<c01e7ef2>] Tainted: P VLI EFLAGS: 00210202 (2.6.11-gentoo-r4) EIP is at memcpy+0x1e/0x39 eax: 00000010 ebx: db84f300 ecx: 00000004 edx: 00000000 esi: cd6f7edc edi: 00000000 ebp: bfffccf0 esp: cd6f7eac ds: 007b es: 007b ss: 0068 Process alsaplayer (pid: 30253, threadinfo=cd6f6000 task=cc0c1590) Stack: ffffffea ffffffea cd6f7eec e09a28f8 00000000 cd6f7edc 00000010 db84f300 e09a3630 db84f300 cd6f7edc 00000050 00000006 00000000 00000000 00000000 00000005 00000001 00000000 00000000 00008002 00000000 00000000 00000000 Call Trace: [<e09a28f8>] snd_timer_user_append_to_tqueue+0x40/0x49 [snd_timer] [<e09a3630>] snd_timer_user_params+0x21c/0x221 [snd_timer] [<e09a381d>] snd_timer_user_ioctl+0xdf/0x1f9 [snd_timer] [<c015f507>] do_ioctl+0x53/0x7a [<c015f6ef>] vfs_ioctl+0x65/0x1d4 [<c015f8a3>] sys_ioctl+0x45/0x6a [<c0102da9>] sysenter_past_esp+0x52/0x75 Code: fd 31 c0 c3 31 d2 b8 f2 ff ff ff c3 90 83 ec 0c 8b 44 24 18 8b 54 24 10 89 74 24 04 89 c1 89 7c 24 08 8b 74 24 14 c1 e9 02 89 d7 <f3> a5 a8 02 74 02 66 a5 a8 01 74 01 a4 89 d0 8b 74 24 04 8b 7c <4>PCI: IRQ 5 for device 0000:00:14.5 doesn't match PIRQ mask - try pci=usepirqmask PCI: IRQ 5 for device 0000:00:14.6 doesn't match PIRQ mask - try pci=usepirqmask
I can confirm exactly the same issue with timidity++ used as a sequencer. Always happens. Apr 1 14:57:34 [kernel] Unable to handle kernel NULL pointer dereference at virtual address 00000000 Apr 1 14:57:34 [kernel] printing eip: Apr 1 14:57:34 [kernel] c01df176 Apr 1 14:57:34 [kernel] *pde = 00000000 Apr 1 14:57:34 [kernel] Oops: 0002 [#2] Apr 1 14:57:35 [kernel] PREEMPT Apr 1 14:57:35 [kernel] Modules linked in: i915 drm ppp_synctty ppp_async crc_ccitt ppp_generic slhc iptable_mangle iptable_nat ipt_multiport ipt_state ip_conntrack iptable_filter ip_tables snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_intel8x0m snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc yenta_socket rsrc_nonstatic pcmcia_core tg3 intel_agp agpgart hw_random thermal processor fan button battery ac uhci_hcd usb_storage usbhid ehci_hcd usbcore Apr 1 14:57:35 [kernel] CPU: 0 Apr 1 14:57:35 [kernel] EIP: 0060:[<c01df176>] Not tainted VLI Apr 1 14:57:35 [kernel] EFLAGS: 00010202 (2.6.11-gentoo-r4) Apr 1 14:57:35 [kernel] EIP is at memcpy+0x1e/0x39 Apr 1 14:57:35 [kernel] eax: 00000010 ebx: ea24bb80 ecx: 00000004 edx: 00000000 Apr 1 14:57:35 [kernel] esi: e5c79ecc edi: 00000000 ebp: bfffdfb0 esp: e5c79e9c Apr 1 14:57:35 [kernel] ds: 007b es: 007b ss: 0068 Apr 1 14:57:35 [kernel] Process artsd (pid: 14343, threadinfo=e5c78000 task=ea200520) Apr 1 14:57:35 [kernel] Stack: e5c79edc ffffffea e5c79edc f0c1dd98 00000000 e5c79ecc 00000010 ea24bb80 Apr 1 14:57:35 [kernel] f0c1eb78 ea24bb80 e5c79ecc 00000050 00000006 00000000 00000000 00000000 Apr 1 14:57:35 [kernel] 00000005 00000001 00000000 00000000 00008002 00000000 00000000 00000000 Apr 1 14:57:35 [kernel] Call Trace: Apr 1 14:57:35 [kernel] [<f0c1dd98>] snd_timer_user_append_to_tqueue+0x40/0x49 [snd_timer] Apr 1 14:57:35 [kernel] [<f0c1eb78>] snd_timer_user_params+0x242/0x251 [snd_timer] Apr 1 14:57:35 [kernel] [<f0c1edde>] snd_timer_user_ioctl+0x122/0x23a [snd_timer] Apr 1 14:57:35 [kernel] [<c016701b>] do_ioctl+0x6f/0xa9 Apr 1 14:57:35 [kernel] [<c0167261>] vfs_ioctl+0x65/0x1e1 Apr 1 14:57:35 [kernel] [<c0152f6b>] fd_install+0x46/0x81 Apr 1 14:57:35 [kernel] [<c0167422>] sys_ioctl+0x45/0x6b Apr 1 14:57:35 [kernel] [<c010302d>] sysenter_past_esp+0x52/0x75 Apr 1 14:57:35 [kernel] Code: fd 31 c0 c3 31 d2 b8 f2 ff ff ff c3 90 83 ec 0c 8b 44 24 18 8b 54 24 10 89 74 24 04 89 c1 89 7c 24 08 8b 74 24 14 c1 e9 02 89 d7 <f3> a5 a8 02 74 02 66 a5 a8 01 74 01 a4 89 d0 8b 74 24 04 8b 7c
yes, I can confirm this. I try to re-emerge some of them and look if it still fails. At least now *all* ALSA-apps are broken. Looks like an ABI change.
*** Bug 87718 has been marked as a duplicate of this bug. ***
As I said for the other bug, the ones which are getting this problem are using in-kernel drivers or alsa-driver's ones? In the latter case, which version?
Well the kernel shouldn't oops no matter what userland tries, so first and foremost, this is a bug in the drivers, so what version of the alsa drivers are you using?
I'm using modules (snd_intel8x0) from the vanilla kernel 2.6.11.
Can you please try media-sound/alsa-driver-1.0.8 and 1.0.9_rc2 to see if that helps...
It works when I disabled in-kernel ALSA and installed alsa-driver-1.0.9_rc2.
*** Bug 87385 has been marked as a duplicate of this bug. ***
Ok, then I'm going to mark this fixed as the recommended way to install alsa works, and alsa-driver changes will eventually work their way into the kernel, so it's a bug just in the kernel rivers.
Wouldn't it be possible to introduce a virtual package alsa that is either provided by the kernel or the alsa-driver package. That way the alsa-lib / -headers packages could depend on a particular version of alsa and would not be upgraded as long as the kernel does not provide the right version. The point is that I am happy that I have a clean kernel without any external drivers, because I do not want to have a list of drivers I need to upgrade whenever I upgrade the kernel - and I am sure I am not the only one who does this. Furthermore that would IMHO be the clean and should-be solution to that problem. Don't get me wrong. I don't even care if it will be done this way - it simply creates much less work than maintaining bug reports everytime something like this happens.
Please forget about my previous comment - How would the kernel-ebuild know if alsa modules have actually been installed...
*** Bug 87775 has been marked as a duplicate of this bug. ***
spamprotect: that does exist... virtual/alsa the kernel doesn't care about what external modules are installed. media-sound/alsa-driver verifies that you haven't enabled the in-kernel modules
Using alsa-lib-1.0.9_rc2-r1 with kernel drivers makes kde hang when it's started (artsd, I expect), with 100% CPU. C-M-Backspace is the only solution (and yet, it takes > 15 s. to be processed). So I guess that the patch in portage isn't enough. Downgrading to 1.0.8 (as always) fixes the issue. PS: Maybe bug #88034 is a dupe of this.
*** Bug 88034 has been marked as a duplicate of this bug. ***
*** Bug 87996 has been marked as a duplicate of this bug. ***
Please update to gentoo-sources-2.6.11-r6 or use media-sound/alsa-driver
huh, 2.6.11-r6 is available now? until now, gentoo-sources-2.6.11-r5 is the latest... ahh, I see, it's masked... ;)
Yeah, it was masked until the patches hit mirrors, but I unmasked it a few hours ago.
Nope, -r6 doesn't fix artsd problem.
the new kernel and rc2-rc1 made the error go away on my IBM-T40 but there in still no sound.
Harris: Use media-sound/alsa-driver
@Harris: I'm using linux 2.6.11-gentoo-r5 (alsa drivers) and gentoo alsa-lib, -utils, headers, ...,-1.0.8 on my IBM R51 Laptop. ==> No kernel oops, but also not sound (muted!) It took me hours to find out that you have to "mute" both, the "Headphone Jack Sense" and the "Line Jack Sense". (source: http://marc.theaimsgroup.com/?t=110985464600003&r=1&w=2) Don't know, if this happens only on IBM Laptops with "intel8x0"... Cheers, Axel
I am experiencing the same issue as Matteo Settenvini described in comment 15. Using alsa-lib-1.0.9_rc2-r1, artsd (from kde 3.4) consumes 100% cpu. Downgrading to alsa-lib-1.0.8 solves this issue. This is with gentoo-sources-2.6.11-r6. If this is due to a mismatch between the kernel's 1.0.8 and the 1.0.9 library, maybe packages like beep-media-player-0.9.7-r5 shouldn't depend on alsa-lib-1.0.9_rc2? (See bug 86066.)
Muting Line Sense Jack and Headphone Sense Jack fixed it for me.
This was fixed in April it looks like, yet there is still some einfo output which says "please use media-sound/alsa-driver rather than in-kernel drivers as there have been some problems recently with the in-kernel drivers. See Bug #87544" when I emerge alsa-lib. Is this message obsolete?
it's not an issue right now. But the problem remains. If there is some incompatibility between installed kernel-alsa and alsa-lib, you can run into problems again. But this highly depends on kernel-alsa/alsa-lib revisions.
