Re: 2.6.17-rc5-mm1

[Ingo Molnar <mingo@elte.hu>]

* 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