![]() | |||||||||||||
Messages in this thread |
* Frederik Deweerdt <deweerdt@free.fr> 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?)] 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-09-11 05:55 [W:3.665 / U:0.170 seconds] ©2003-2008 Jasper Spaans | |||||||||||||