On Tue, 2007-05-22 at 17:19 -0700, Sven-Thorsten Dietrich wrote:
> swapper/1 just changed the state of lock:
>
> (rtc_lock#2){-...}, at: [<ffffffff8085b185>] sbf_init+0x25/0xe0
>
> but this lock was taken by another, hard-irq-safe lock in the past:
>
> (xtime_lock){+...}
>
>
>
> and interrupts could create inverse lock ordering between them.
>
>
>
>
>
> other info that might help us debug this:
>
> no locks held by swapper/1.
>
>
>
> the first lock's dependencies:
>
> -> (rtc_lock#2){-...} ops: 2 {
>
> initial-use at:
>
> [<ffffffff8025d383>] mark_lock+0xf3/0x5b0
>
> [<ffffffff8025e6f4>] __lock_acquire+0x664/0xf80
>
> [<ffffffff8025f098>] lock_acquire+0x88/0xc0
>
> [<ffffffff8047e2c5>] rt_spin_lock+0x35/0x40
>
> [<ffffffff8020e162>] read_persistent_clock+0x22/0x1b0
>
> [<ffffffff80867e86>] timekeeping_init+0x86/0x100
>
> [<ffffffff808537af>] start_kernel+0x1bf/0x350
>
> [<ffffffff80853179>] _sinittext+0x179/0x180
>
> [<ffffffffffffffff>] 0xffffffffffffffff
Hmm. That's the code in question:
void __init timekeeping_init(void)
{
unsigned long flags;
unsigned long sec = read_persistent_clock();
write_seqlock_irqsave(&xtime_lock, flags);
The rtc_lock is never taken inside the xtime_lock.
Looks like code reordering due to gcc extra magic. Which compiler ?
Thanks,
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
