From: Andy Walls <awalls@md.metrocast.net>
To: linux-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, David Miller <davem@davemloft.net>,
linux-media@vger.kernel.org,
Devin Heitmueller <dheitmueller@kernellabs.com>,
Hugh Dickins <hughd@google.com>, Hugh Dickins <hugh@veritas.com>
Subject: Re: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded
Date: Sat, 05 Mar 2011 16:59:25 -0500 [thread overview]
Message-ID: <1299362366.2570.27.camel@localhost> (raw)
In-Reply-To: <1299204400.2812.35.camel@localhost>
On Thu, 2011-03-03 at 21:06 -0500, Andy Walls wrote:
> Hi,
>
> I got a BUG when loading the cx18.ko module (which in turn requests the
> cx18-alsa.ko module) on a kernel built from this repository
>
> http://git.linuxtv.org/media_tree.git staging/for_v2.6.39
>
> which I beleive is based on 2.6.38-rc2.
[snip]
> So here is my transcription of a fuzzy digital photo of the screen:
>
> kernel BUG at /home/andy/cx18dev/git/media_tree/mm/mmap.c:2309!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/module/snd_pcm/initstate
> Modules linked in: tda9887 tda8290 mxl5005s s5h1409 tuner_simple ...
> ...
> Pid: 2580, comm: udevd Not tainted 2.6.38-rc2-cx18-vb2-proto+
> RIP: 0010:[<ffffffff810eb50b>] [<ffffffff810eb50b>] exit_mmap+0x10f/0x11e
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0020000000000000
> RDX: 0000000000160011 RSI: ffffea____c42___ RDI: 0000000000000202
> RBP: ffff____18c1f_58 R08: ffff____________ R09: 0000000000000004
> R10: ffff_______bb_38 R11: 0000000000000000 R12: ffff____344a6680
> R13: 00007fff22______ R14: ffff____________ R15: 0000000000000001
> ...
> CR2: 0000000000000000 ...
> ....
> Process udevd (pid: 25__, threadinfo ffff________, ...
> Stack:
> 000000000000015e ffff00003bc0e1d0 0000000000000246 ....
> .....
> Call Trace:
> ... mmput+0x63/0xcf
> ... exit_mm+0x132/0x13f
> ... do_exit+0x238/0x749
> ... ? __dequeue_signal+0xfa/0x12f
> ... do_group_exit+0x7d/0xa5
> ... get_signal_to_deliver+0x371/0x395
> ... do_signal+0x72/0x692
> ... ? do_page_fault+0x24a/0x391
> ... ? printk+0x41/0x47
> ... ? sigprocmask+0xa3/0xcd
> ... do_notify_resume+0x2c/0x64
> ... retint_signal+0x48/0x8c
>
> Code: ff ff 48 8b 7d d8 4c 89 ea 31 f6 e8 3e fe ff ff 48 89 df e8 78 fe
> ff ff 48 85 c0 48 89 c3 75 f0 49 83 bc 24 e0 00 00 00 00 74 04 <0f> 0b
> eb fe 48 83 c4 18 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 57
> RIP [<ffffffff810eb50b>] exit_mmap+0x10f/0x11e
> RSP <ffff880018c1fc28>
> general protection fault: 0000 [#2] SMP
> last sysfs file: /sys/devices/virtual/sound/card2/uevent
> CPU 1
> Modules linked in: cx18-alsa tda9887 tda8290 mxl5005s s5h1409
> tuner_simple tuner_types cs5345 tuner cx18 dvb_core cx2341x v4l2_common
> videodev v4l2_compat_ioctl32
I'm dumping all my previous assumtpions about this BUG. After a bit of
reading, all I can say is that it's a page table deallocation problem at
process exit. After all the page table deallocations on exit,
mm->nr_ptes is still > 0, and that's a bad thing.
It apparently happened in a child udevd exiting shortly after cx18.ko
loaded. The cx18 driver allocating large amounts kernel memory for DMA
buffers upon load may be related to triggering the problem, but I doubt
it is a root cause of the BUG.
This monsterous thread from 5 years ago is somewhat enlightening:
http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/1680.html
http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/1787.html
so it gives me a place to start looking for the problem.
Any advice on what data to collect is appreciated.
Regards,
Andy
next prev parent reply other threads:[~2011-03-05 21:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-04 2:06 BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded Andy Walls
2011-03-04 15:50 ` Devin Heitmueller
2011-03-04 17:13 ` Andy Walls
2011-03-07 10:32 ` Takashi Iwai
2011-03-05 21:59 ` Andy Walls [this message]
2011-03-06 2:03 ` Andy Walls
2011-03-06 18:37 ` Hugh Dickins
2011-03-06 21:04 ` Andy Walls
2011-03-07 2:34 ` Hugh Dickins
2011-03-09 0:37 ` Andy Walls
2011-03-11 0:34 ` Andy Walls
2011-03-11 0:47 ` Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1299362366.2570.27.camel@localhost \
--to=awalls@md.metrocast.net \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dheitmueller@kernellabs.com \
--cc=hugh@veritas.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.