* Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> 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
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
