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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox