Re: OMAP34xx

Kevin Hilman
2012-02-15T23:54:50Z

Luciano Coelho <coelho@ti.com> writes:

[...]

> I just tried this on my Panda and I keep getting this kind of BUGs. It
> spams my console so much that is pretty much unusable:
>
> [ 336.172302] BUG: sleeping function called from invalid context at include/linux/freezer.h:46
> [ 336.181213] in_atomic(): 0, irqs_disabled(): 128, pid: 1618, name: ntpd
> [ 336.181213] INFO: lockdep is turned off.
> [ 336.181213] irq event stamp: 0
> [ 336.181213] hardirqs last enabled at (0): [< (null)>] (null)
> [ 336.201660] hardirqs last disabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
> [ 336.209625] softirqs last enabled at (0): [<c0042314>] copy_process+0x3ec/0x105c
> [ 336.217498] softirqs last disabled at (0): [< (null)>] (null)
> [ 336.217498] [<c001e1e4>] (unwind_backtrace+0x0/0x148) from [<c0502c24>] (dump_stack+0x20/0x24)
> [ 336.232879] [<c0502c24>] (dump_stack+0x20/0x24) from [<c0077998>] (__might_sleep+0x130/0x134)
> [ 336.232879] [<c0077998>] (__might_sleep+0x130/0x134) from [<c0018998>] (do_signal+0x54/0x600)
> [ 336.250793] [<c0018998>] (do_signal+0x54/0x600) from [<c0018fa4>] (do_notify_resume+0x60/0x6c)
> [ 336.250793] [<c0018fa4>] (do_notify_resume+0x60/0x6c) from [<c00154e4>] (work_pending+0x24/0x28)
>
> I have also seen this in 3.3-rc3 (both on Panda (OMAP4460) and on Blaze
> (OMAP4430) boards) and I was hoping your tree would have the fix for it,
> but it doesn't. :( The device boots and seems to work otherwise, but
> this is annoying and looks shaky.
>
> I saw something related to this in another thread from a few months ago,
> and one patch proposal by Russell, but I didn't find any conclusion or
> any related patch queued up for upstream.
>
> Is there any solution for this? I use a tuned .config (attached) and not
> the one generated by omap2plus_defconfig (which I didn't try as
> vanilla).

I see the same thing with your ~/.config, but I don't think this is OMAP
specific. I suspect this will happen on any ARM platform that has
CONFIG_DEBUG_ATOMIC_SLEEP=y.

It appears to be a problem with the recently added audit support for
ARM, since reverting the commit below makes this BUG go away.

Based on the BUG you're seeing, there appears to be a missing IRQ
(re)enable in the syscall path with this new audit support, but I did
not dig further, since it seems Russell is planning to revert this patch
anyways due to other problems.

Kevin

commit 29ef73b7a823b77a7cd0bdd7d7cded3fb6c2587b
Author: Nathaniel Husted <nhusted@gmail.com>
Date: Tue Jan 3 14:23:09 2012 -0500

Kernel: Audit Support For The ARM Platform

This patch provides functionality to audit system call events on the
ARM platform. The implementation was based off the structure of the
MIPS platform and information in this
(http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html)
mailing list thread. The required audit_syscall_exit and
audit_syscall_entry checks were added to ptrace using the standard
registers for system call values (r0 through r3). A thread information
flag was added for auditing (TIF_SYSCALL_AUDIT) and a meta-flag was
added (_TIF_SYSCALL_WORK) to simplify modifications to the syscall
entry/exit. Now, if either the TRACE flag is set or the AUDIT flag is
set, the syscall_trace function will be executed. The prober changes
were made to Kconfig to allow CONFIG_AUDITSYSCALL to be enabled.

Due to platform availability limitations, this patch was only tested
on the Android platform running the modified "android-goldfish-2.6.29"
kernel. A test compile was performed using Code Sourcery's
cross-compilation toolset and the current linux-3.0 stable kernel. The
changes compile without error. I'm hoping, due to the simple modifications,
the patch is "obviously correct".

Signed-off-by: Nathaniel Husted <nhusted@gmail.com>
Signed-off-by: Eric Paris <eparis@redhat.com>