I ran into this problem, like someone else on the mailing list.
Pentium III 800MHz 512MB ram
CM8738 sound card
on 2.6.12-rc5-mm1 on gentoo-linux
play sound through alsa, then quit program. I get an oops:
Unable to handle kernel NULL pointer dereference at virtual address 000000a4
printing eip:
c02acb79
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in:
CPU: 0
EIP: 0060:[<c02acb79>] Not tainted VLI
EFLAGS: 00210286 (2.6.12-rc5-mm1-personal)
EIP is at snd_pcm_mmap_data_close+0xa/0x11
eax: 00000000 ebx: db194000 ecx: d9fc8720 edx: d9f24b40
esi: dfabd080 edi: d9f24b18 ebp: df461b80 esp: db195f58
ds: 007b es: 007b ss: 0068
Process mplayer (pid: 14876, threadinfo=db194000 task=df382540)
Stack: c013dd8c d9f24b18 00000000 df461b80 b653d000 c013f1d5 d9f24b18 d9f24b18
d9f24b18 b6545000 c013f4ec df461b80 d9f24b18 d9fc8858 df461b80 df461bb0
00008000 db194000 c013f529 df461b80 b653d000 00008000 b653d000 00008000
Call Trace:
[<c013dd8c>] remove_vm_struct+0x49/0x6f
[<c013f1d5>] unmap_vma_list+0x14/0x1f
[<c013f4ec>] do_munmap+0xe7/0xf3
[<c013f529>] sys_munmap+0x31/0x4b
[<c0102bd7>] sysenter_past_esp+0x54/0x75
Code: 8b 54 24 04 81 48 14 00 00 08 00 c7 40 44 fc c6 38 c0 89 50 50 8b 42 60 ff
80 a4 00 00 00 31 c0 c3 8b 44 24 04 8b 40 50 8b 40 60 <ff> 88 a4 00 00 00 c3 8b
44 24 04 8b 40 50 8b 40 60 ff 80 a4 00
I reported it here:
http://bugzilla.kernel.org/show_bug.cgi?id=4662
thinking it would appear on lkml, but it didn't. Anyway, tell me if more
info is needed.
Thanks in advance.
<snip>
Andrew,
similar oopses as the one I'm replying to all over the place. At it happens m
in snd_pcm_mmap_data_close(). Here's a stack trace:
May 26 19:19:14 zmei kernel: [ 9453.397240] Unable to handle kernel paging
request at virtual address b6514060
May 26 19:19:14 zmei kernel: [ 9453.397247] printing eip:
May 26 19:19:14 zmei kernel: [ 9453.397249] c0298ef6
May 26 19:19:14 zmei kernel: [ 9453.397250] *pde = 137ef067
May 26 19:19:14 zmei kernel: [ 9453.397252] *pte = 00000000
May 26 19:19:14 zmei kernel: [ 9453.397255] Oops: 0000 [#1]
May 26 19:19:14 zmei kernel: [ 9453.397258] PREEMPT SMP
May 26 19:19:14 zmei kernel: [ 9453.397261] Modules linked in: nls_iso8859_15
isofs nfsd exportfs lockd sunrpc pcspkr tuner tvaudio bttv video_buf
firmware_class i2c_algo_bit v4l2_common btcx_risc tveeprom i2c_core videodev
rtc
May 26 19:19:14 zmei kernel: [ 9453.397281] CPU: 0
May 26 19:19:14 zmei kernel: [ 9453.397282] EIP: 0060:
[snd_pcm_mmap_data_close+6/18] Not tainted VLI
May 26 19:19:14 zmei kernel: [ 9453.397284] EFLAGS: 00210286
(2.6.12-rc5-mm1)
May 26 19:19:14 zmei kernel: [ 9453.397291] EIP is at
snd_pcm_mmap_data_close+0x6/0x12
May 26 19:19:14 zmei kernel: [ 9453.397295] eax: b6514000 ebx: df22d714
ecx: df22d714 edx: c0298ef0
May 26 19:19:14 zmei kernel: [ 9453.397298] esi: df22d744 edi: d160b964
ebp: c3d6af48 esp: c3d6af48
May 26 19:19:14 zmei kernel: [ 9453.397301] ds: 007b es: 007b ss: 0068
May 26 19:19:14 zmei kernel: [ 9453.397304] Process xmms (pid: 5026,
threadinfo=c3d6a000 task=dc4aa560)
May 26 19:19:14 zmei kernel: [ 9453.397307] Stack: c3d6af60 c01505e5 d61dbd38
d61dbd38 dcd377f0 dcd377f0 c3d6af70 c0151d69
May 26 19:19:14 zmei kernel: [ 9453.397317] fffffff0 00000000 c3d6af80
c0151d8a b6514000 b6504000 c3d6afa4 c0152137
May 26 19:19:14 zmei kernel: [ 9453.397327] b6504000 b6514000 d61dbd38
d481a11c dcd377f0 dcd37820 00000002 c3d6afb4
May 26 19:19:14 zmei kernel: [ 9453.397337] Call Trace:
May 26 19:19:14 zmei kernel: [ 9453.397339] [show_stack+122/144]
show_stack+0x7a/0x90
May 26 19:19:14 zmei kernel: [ 9453.397345] [show_registers+342/448]
show_registers+0x156/0x1c0
May 26 19:19:14 zmei kernel: [ 9453.397350] [die+244/368] die+0xf4/0x170
May 26 19:19:14 zmei kernel: [ 9453.397355] [do_page_fault+879/1695]
do_page_fault+0x36f/0x69f
May 26 19:19:14 zmei kernel: [ 9453.397361] [error_code+79/84]
error_code+0x4f/0x54
May 26 19:19:14 zmei kernel: [ 9453.397365] [remove_vm_struct+149/160]
remove_vm_struct+0x95/0xa0
May 26 19:19:14 zmei kernel: [ 9453.397371] [unmap_vma+89/96]
unmap_vma+0x59/0x60
May 26 19:19:14 zmei kernel: [ 9453.397376] [unmap_vma_list+26/48]
unmap_vma_list+0x1a/0x30
May 26 19:19:14 zmei kernel: [ 9453.397381] [do_munmap+231/288]
do_munmap+0xe7/0x120
May 26 19:19:14 zmei kernel: [ 9453.397385] [sys_munmap+78/112]
sys_munmap+0x4e/0x70
May 26 19:19:14 zmei kernel: [ 9453.397390] [syscall_call+7/11]
syscall_call+0x7/0xb
May 26 19:19:14 zmei kernel: [ 9453.397394] Code: 5d c3 8d 76 00 55 8b 40 50
89 e5 8b 40 60 f0 ff 80 a4 00 00 00 5d c3 8d b4 26 00 00 00 00 8d bc 27 00 00
00 00 55 8b 40 50 89 e5 <8b> 40 60 f0 ff 88 a4 00 00 00 5d c3 51 52 e8 e7 63
09 00 5a 59
May 26 19:20:17 zmei kernel: [ 9453.397447] <3>kfree_debugcheck: out of range
ptr b7f24000h.
May 26 19:20:17 zmei kernel: [ 9515.781705] ------------[ cut
here ]------------
May 26 19:20:17 zmei kernel: [ 9515.781724] kernel BUG at mm/slab.c:1893!
May 26 19:20:17 zmei kernel: [ 9515.781742] invalid operand: 0000 [#2]
May 26 19:20:17 zmei kernel: [ 9515.781758] PREEMPT SMP
May 26 19:20:17 zmei kernel: [ 9515.781784] Modules linked in: nls_iso8859_15
isofs nfsd exportfs lockd sunrpc pcspkr tuner tvaudio bttv video_buf
firmware_class i2c_algo_bit v4l2_common btcx_risc tveeprom i2c_core videodev
rtc
May 26 19:20:17 zmei kernel: [ 9515.781916] CPU: 0
May 26 19:20:17 zmei kernel: [ 9515.781918] EIP: 0060:
[kfree_debugcheck+112/128] Not tainted VLI
May 26 19:20:17 zmei kernel: [ 9515.781920] EFLAGS: 00010096
(2.6.12-rc5-mm1)
May 26 19:20:17 zmei kernel: [ 9515.781971] EIP is at
kfree_debugcheck+0x70/0x80
May 26 19:20:17 zmei kernel: [ 9515.781991] eax: 00000031 ebx: 000f7f24
ecx: c0397dac edx: 00000001
May 26 19:20:17 zmei kernel: [ 9515.782016] esi: b7f24000 edi: b7f24000
ebp: df7fbef4 esp: df7fbee4
May 26 19:20:17 zmei kernel: [ 9515.782037] ds: 007b es: 007b ss: 0068
May 26 19:20:17 zmei kernel: [ 9515.782056] Process XFree86 (pid: 4718,
threadinfo=df7fb000 task=daaa7a90)
May 26 19:20:17 zmei kernel: [ 9515.782069] Stack: c034d3a0 b7f24000 b7f24000
00000000 df7fbf0c c01482cf 00000286 dcc4bf00
May 26 19:20:17 zmei kernel: [ 9515.782139] 00000000 b7f24000 df7fbf48
c0216205 b7b24000 df71911c 00000000 da7a9124
May 26 19:20:17 zmei kernel: [ 9515.782206] df71911c c014c34e dfced36c
b7f24000 00000000 c15e82a8 dfced34c dfced37c
May 26 19:20:17 zmei kernel: [ 9515.782276] Call Trace:
May 26 19:20:17 zmei kernel: [ 9515.782301] [show_stack+122/144]
show_stack+0x7a/0x90
May 26 19:20:17 zmei kernel: [ 9515.782326] [show_registers+342/448]
show_registers+0x156/0x1c0
May 26 19:20:17 zmei kernel: [ 9515.782350] [die+244/368] die+0xf4/0x170
May 26 19:20:17 zmei kernel: [ 9515.782372] [do_trap+159/176]
do_trap+0x9f/0xb0
May 26 19:20:17 zmei kernel: [ 9515.782395] [do_invalid_op+169/192]
do_invalid_op+0xa9/0xc0
May 26 19:20:17 zmei kernel: [ 9515.782418] [error_code+79/84]
error_code+0x4f/0x54
May 26 19:20:17 zmei kernel: [ 9515.782441] [kfree+31/144] kfree+0x1f/0x90
May 26 19:20:17 zmei kernel: [ 9515.782465] [drm_vm_shm_close+549/704]
drm_vm_shm_close+0x225/0x2c0
May 26 19:20:17 zmei kernel: [ 9515.782491] [remove_vm_struct+149/160]
remove_vm_struct+0x95/0xa0
May 26 19:20:17 zmei kernel: [ 9515.782515] [unmap_vma+89/96]
unmap_vma+0x59/0x60
May 26 19:20:17 zmei kernel: [ 9515.782538] [unmap_vma_list+26/48]
unmap_vma_list+0x1a/0x30
May 26 19:20:17 zmei kernel: [ 9515.782561] [do_munmap+231/288]
do_munmap+0xe7/0x120
May 26 19:20:17 zmei kernel: [ 9515.782584] [sys_munmap+78/112]
sys_munmap+0x4e/0x70
May 26 19:20:17 zmei kernel: [ 9515.782607] [syscall_call+7/11]
syscall_call+0x7/0xb
May 26 19:20:17 zmei kernel: [ 9515.782630] Code: 04 24 60 d3 34 c0 e8 00 70
fd ff 0f 0b 6a 07 0a c5 34 c0 eb d6 8d b6 00 00 00 00 89 44 24 04 c7 04 24 a0
d3 34 c0 e8 e0 6f fd ff <0f> 0b 65 07 0a c5 34 c0 eb a5 8d b6 00 00 00 00 55
89 e5 57 56
Regards,
Boris.
On Thu, 2005-05-26 at 19:44 +0200, Borislav Petkov wrote:
> <snip>
>
> Andrew,
>
> similar oopses as the one I'm replying to all over the place. At it happens m
> in snd_pcm_mmap_data_close(). Here's a stack trace:
No one using ALSA CVS or any of the 1.0.9 release candidates ever
reported this, but lots of -mm users are... does that help at all? I
suspect some upstream bug that ALSA just happens to trigger.
Lee
On Thursday 26 May 2005 20:01, Lee Revell wrote:
> On Thu, 2005-05-26 at 19:44 +0200, Borislav Petkov wrote:
> > <snip>
> >
> > Andrew,
> >
> > similar oopses as the one I'm replying to all over the place. At it
> > happens m in snd_pcm_mmap_data_close(). Here's a stack trace:
>
> No one using ALSA CVS or any of the 1.0.9 release candidates ever
> reported this, but lots of -mm users are... does that help at all? I
> suspect some upstream bug that ALSA just happens to trigger.
yeah,
this has to do with alsa indirectly. snd_pcm_mmap_data_close() accesses some
vm_area_struct->vm_private_data and apparently there have been some
optimizations to mmap code to avoid fragmentation of vma's so i think there's
the problem. However, we'll need the smarter ones here :))
Regards,
Boris.
On Thu, 2005-05-26 at 20:12 +0200, Borislav Petkov wrote:
> On Thursday 26 May 2005 20:01, Lee Revell wrote:
> > On Thu, 2005-05-26 at 19:44 +0200, Borislav Petkov wrote:
> > > <snip>
> > >
> > > Andrew,
> > >
> > > similar oopses as the one I'm replying to all over the place. At it
> > > happens m in snd_pcm_mmap_data_close(). Here's a stack trace:
> >
> > No one using ALSA CVS or any of the 1.0.9 release candidates ever
> > reported this, but lots of -mm users are... does that help at all? I
> > suspect some upstream bug that ALSA just happens to trigger.
> yeah,
>
> this has to do with alsa indirectly. snd_pcm_mmap_data_close() accesses some
> vm_area_struct->vm_private_data and apparently there have been some
> optimizations to mmap code to avoid fragmentation of vma's so i think there's
> the problem. However, we'll need the smarter ones here :))
Any idea which patches to back out?
Lee
Lee Revell wrote:
> On Thu, 2005-05-26 at 20:12 +0200, Borislav Petkov wrote:
>
>>On Thursday 26 May 2005 20:01, Lee Revell wrote:
>>
>>>On Thu, 2005-05-26 at 19:44 +0200, Borislav Petkov wrote:
>>>
>>>><snip>
>>>>
>>>>Andrew,
>>>>
>>>>similar oopses as the one I'm replying to all over the place. At it
>>>>happens m in snd_pcm_mmap_data_close(). Here's a stack trace:
>>>
>>>No one using ALSA CVS or any of the 1.0.9 release candidates ever
>>>reported this, but lots of -mm users are... does that help at all? I
>>>suspect some upstream bug that ALSA just happens to trigger.
>>
>>yeah,
>>
>>this has to do with alsa indirectly. snd_pcm_mmap_data_close() accesses some
>>vm_area_struct->vm_private_data and apparently there have been some
>>optimizations to mmap code to avoid fragmentation of vma's so i think there's
>>the problem. However, we'll need the smarter ones here :))
>
>
> Any idea which patches to back out?
avoiding-mmap-fragmentation-fix-2.patch
seems to do the trick. Ken will likely have a fix-3 shortly ;-)
Wolfgang
Yes I reversed as mentioned here : http://lkml.org/lkml/2005/5/26/109
It's working like a charm now.
I reckon avoiding-mmap-fragmentation-fix-2.patch is the one to back out.
Wolfgang Wander [[email protected]] wrote:
> Lee Revell wrote:
> >On Thu, 2005-05-26 at 20:12 +0200, Borislav Petkov wrote:
> >
> >>On Thursday 26 May 2005 20:01, Lee Revell wrote:
> >>
> >>>On Thu, 2005-05-26 at 19:44 +0200, Borislav Petkov wrote:
> >>>
> >>>><snip>
> >>>>
> >>>>Andrew,
> >>>>
> >>>>similar oopses as the one I'm replying to all over the place. At it
> >>>>happens m in snd_pcm_mmap_data_close(). Here's a stack trace:
> >>>
> >>>No one using ALSA CVS or any of the 1.0.9 release candidates ever
> >>>reported this, but lots of -mm users are... does that help at all? I
> >>>suspect some upstream bug that ALSA just happens to trigger.
> >>
> >>yeah,
> >>
> >>this has to do with alsa indirectly. snd_pcm_mmap_data_close() accesses
> >>some vm_area_struct->vm_private_data and apparently there have been some
> >>optimizations to mmap code to avoid fragmentation of vma's so i think
> >>there's the problem. However, we'll need the smarter ones here :))
> >
> >
> >Any idea which patches to back out?
>
>
> avoiding-mmap-fragmentation-fix-2.patch
>
> seems to do the trick. Ken will likely have a fix-3 shortly ;-)
>
Reverting this patch makes it work for me. <tm>
--
*--* Mail: [email protected]
*--* Voice: 425.739.4247
*--* Fax: 425.827.9577
*--* HTTP://the-penguin.otak.com/~lawrence
--------------------------------------
- - - - - - O t a k i n c . - - - - -
Wolfgang Wander <[email protected]> wrote:
>
> Lee Revell wrote:
> > On Thu, 2005-05-26 at 20:12 +0200, Borislav Petkov wrote:
> >
> >>On Thursday 26 May 2005 20:01, Lee Revell wrote:
> >>
> >>>On Thu, 2005-05-26 at 19:44 +0200, Borislav Petkov wrote:
> >>>
> >>>><snip>
> >>>>
> >>>>Andrew,
> >>>>
> >>>>similar oopses as the one I'm replying to all over the place. At it
> >>>>happens m in snd_pcm_mmap_data_close(). Here's a stack trace:
> >>>
> >>>No one using ALSA CVS or any of the 1.0.9 release candidates ever
> >>>reported this, but lots of -mm users are... does that help at all? I
> >>>suspect some upstream bug that ALSA just happens to trigger.
> >>
> >>yeah,
> >>
> >>this has to do with alsa indirectly. snd_pcm_mmap_data_close() accesses some
> >>vm_area_struct->vm_private_data and apparently there have been some
> >>optimizations to mmap code to avoid fragmentation of vma's so i think there's
> >>the problem. However, we'll need the smarter ones here :))
> >
> >
> > Any idea which patches to back out?
>
>
> avoiding-mmap-fragmentation-fix-2.patch
>
> seems to do the trick. Ken will likely have a fix-3 shortly ;-)
>
Yup. This appears to be not-an-alsa-bug. Thanks.
Andrew Morton wrote on Thursday, May 26, 2005 2:25 PM
> > >>
> > >>this has to do with alsa indirectly. snd_pcm_mmap_data_close() accesses some
> > >>vm_area_struct->vm_private_data and apparently there have been some
> > >>optimizations to mmap code to avoid fragmentation of vma's so i think there's
> > >>the problem. However, we'll need the smarter ones here :))
> > >
> > >
> > > Any idea which patches to back out?
> >
> >
> > avoiding-mmap-fragmentation-fix-2.patch
> >
> > seems to do the trick. Ken will likely have a fix-3 shortly ;-)
> >
>
> Yup. This appears to be not-an-alsa-bug. Thanks.
I'm the guilty one here. avoiding-mmap-fragmentation-fix-2.patch has
a major clash using vm_private_data where alsa is also using. I just
posted a patch, please try that out. Thanks.
http://marc.theaimsgroup.com/?l=linux-mm&m=111721191501940&w=2
- Ken
On Friday 27 May 2005 18:42, Chen, Kenneth W wrote:
> Andrew Morton wrote on Thursday, May 26, 2005 2:25 PM
>
> > > >>this has to do with alsa indirectly. snd_pcm_mmap_data_close()
> > > >> accesses some vm_area_struct->vm_private_data and apparently there
> > > >> have been some optimizations to mmap code to avoid fragmentation of
> > > >> vma's so i think there's the problem. However, we'll need the
> > > >> smarter ones here :))
> > > >
> > > > Any idea which patches to back out?
> > >
> > > avoiding-mmap-fragmentation-fix-2.patch
> > >
> > > seems to do the trick. Ken will likely have a fix-3 shortly ;-)
> >
> > Yup. This appears to be not-an-alsa-bug. Thanks.
>
> I'm the guilty one here. avoiding-mmap-fragmentation-fix-2.patch has
> a major clash using vm_private_data where alsa is also using. I just
> posted a patch, please try that out. Thanks.
>
> http://marc.theaimsgroup.com/?l=linux-mm&m=111721191501940&w=2
this one seems to be fine. Lightly tested for several hours yesterday.
Regards,
Boris.