Messages in this thread | | | Date | Tue, 30 May 2006 21:42:59 +0200 | From | Ingo Molnar <> | Subject | Re: 2.6.17-rc5-mm1 |
| |
* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> SCSI or libata problem.
i think SCSI and libata is innocent here.
> ============================ > [ BUG: illegal lock usage! ] > ---------------------------- > illegal {in-hardirq-W} -> {hardirq-on-W} usage.
> 1 locks held by init/1: > #0: (&base->lock#2){++..}, at: [<c0129a24>] lock_timer_base+0x29/0x55 > > stack backtrace: > [<c0103e52>] show_trace_log_lvl+0x4b/0xf4 > [<c01044b3>] show_trace+0xd/0x10 > [<c010457b>] dump_stack+0x19/0x1b > [<c0137d63>] print_usage_bug+0x1a1/0x1ab > [<c0138458>] mark_lock+0x2d7/0x514 > [<c01386dc>] mark_held_locks+0x47/0x65 > [<c0139745>] trace_hardirqs_on+0x12b/0x16f > [<c02f2b61>] restore_nocheck+0x8/0xb
weird. We are holding base->lock#2 [CPU#1's timer base lock], _and_ we execute restore_nocheck - which is a return-to-userspace thing.
unfortunately the stacktrace provides no clues of how we got here. For such nasty cases i have a kernel tracing patch prepared, you can get it from:
http://redhat.com/~mingo/lockdep-patches/latency-tracing-lockdep.patch
just apply it ontop of your current tree and accept all the new .config options as the kernel suggests them to you. Then rebuild and reboot into the kernel, and reproduce the lockdep bug. Once such a bug is reported, /proc/latency_trace should have a full kernel trace leading up to the bug. Please upload that trace to your site and send us the URL.
(the tracer runs nonstop and it saves the current trace if it encounters a lockdep bug. That way i can see the history of the bug.)
if possible it would be nice to boot with maxcpus=1 as well, to make sure we have all relevant kernel activity traced. (assuming that booting with maxcpus=1 does not make the bug go away)
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/
| |