* 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.
Ingo