On Mon, Sep 11, 2006 at 07:43:35AM +0200, Ingo Molnar wrote:
>
> * Frederik Deweerdt <[email protected]> wrote:
>
> > Lockdep issues the following warning:
> >
> > [ 16.835268] Freeing unused kernel memory: 260k freed
> > [ 16.842715] Write protecting the kernel read-only data: 432k
> > [ 17.796518] BUG: warning at kernel/lockdep.c:2359/check_flags()
>
> this warning means that the "soft" and "hard" hardirqs-disabled state
> got out of sync: the irqtrace tracking code thinks that hardirqs are
> disabled, while in reality they are enabled. The thing to watch for are
> new "stii" instructions in entry.S (and other assembly code), without a
> matching TRACE_HARDIRQS_ON call. [Another, rarer possiblity is NMI code
> saving/restoring interrupts - do you have NMIs enabled? (are there any
> NMI counts in /proc/interrupts?)]
NMIs were disabled. But I've just booted -mm2 and the warning went away.
Could this be related to the recent pda changes?
FWIW, I did the bisection (inserting TRACE_HARDIRQS_ON between
sysenter_past_esp and the cli) and it gave the following result:
In entry.S:
310
311 pushl %eax
312 CFI_ADJUST_CFA_OFFSET 4
313 SAVE_ALL
314 GET_THREAD_INFO(%ebp)
315
If I put TRACE_HARDIRQS_ON at line 310, lockdep complains about having
interrupts enabled and being told to re-enable them. If I put
TRACE_HARDIRQS_ON at line 315, lockdep goes back to the original
message.
Regards,
Frederik
>
> lockdep automatically generates a minimal trace of hardirqs-off
> state-setting:
>
> > [ 17.885839] irq event stamp: 8318
> > [ 17.892746] hardirqs last enabled at (8317): [<c01032c8>] restore_nocheck+0x12/0x15
> > [ 17.906778] hardirqs last disabled at (8318): [<c0103203>] sysenter_past_esp+0x6c/0x99
> > [ 17.921481] softirqs last enabled at (7128): [<c0123cd1>] __do_softirq+0xe9/0xfa
> > [ 17.936962] softirqs last disabled at (7121): [<c0123d3e>] do_softirq+0x5c/0x60
>
> this means that the last registered 'hardirqs off' event was
> sysenter_past_esp, i.e. the normal sysenter syscall entry code - but
> nothing re-enabled hardirqs - which is weird, given that you ended up in
> sys_brk().
>
> > I've replaced the DEBUG_LOCKS_WARN_ON by a BUG, and it appears that
> > the user space program calling sys_brk is hotplug.
>
> (ok, i'll enhance the debug printout to include the process name and
> PID.)
>
> Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
