Description of problem:

Inconsistant lock messages appear at each boot.

Version-Release number of selected component (if applicable):

Linux localhost.localdomain 2.6.17-1.2358.fc6PAE #1 SMP Fri Jul 7 04:18:02 EDT
2006 i686 i686 i386 GNU/Linux


How reproducible:

Every time.

Steps to Reproduce:
1. Install mentioned kernel
2. Reboot
3. Read fedora people.. report bug
  
Actual results:
Jul  7 16:12:38 localhost kernel: =================================
Jul  7 16:12:38 localhost kernel: [ INFO: inconsistent lock state ]
Jul  7 16:12:38 localhost kernel: ---------------------------------
Jul  7 16:12:38 localhost kernel: inconsistent {hardirq-on-W} -> {in-hardirq-W}
usage.
Jul  7 16:12:38 localhost kernel: hwclock/479 [HC1[1]:SC0[0]:HE0:SE1] takes:
Jul  7 16:12:38 localhost kernel:  (rtc_lock){+-..}, at: [<c053d07d>]
rtc_get_rtc_time+0x1c/0x177
Jul  7 16:12:38 localhost kernel: {hardirq-on-W} state was registered at:
Jul  7 16:12:38 localhost kernel:   [<c043c546>] lock_acquire+0x4b/0x6d
Jul  7 16:12:38 localhost kernel:   [<c060e983>] _spin_lock+0x19/0x28
Jul  7 16:12:38 localhost kernel:   [<c0407433>] get_cmos_time+0x13/0x11d
Jul  7 16:12:38 localhost kernel:   [<c07ae610>] hpet_time_init+0x8/0x4e
Jul  7 16:12:38 localhost kernel:   [<c07a869b>] start_kernel+0x22c/0x3a9
Jul  7 16:12:38 localhost kernel:   [<c0400210>] 0xc0400210
Jul  7 16:12:38 localhost kernel: irq event stamp: 1688
Jul  7 16:12:38 localhost kernel: hardirqs last  enabled at (1687): [<c0403f77>]
restore_nocheck+0x12/0x15
Jul  7 16:12:38 localhost kernel: hardirqs last disabled at (1688): [<c04049c7>]
common_interrupt+0x1b/0x2c
Jul  7 16:12:38 localhost kernel: softirqs last  enabled at (1212): [<c042987d>]
__do_softirq+0xec/0xf2
Jul  7 16:12:38 localhost kernel: softirqs last disabled at (1207): [<c04065ab>]
do_softirq+0x5a/0xbe
Jul  7 16:12:38 localhost kernel:
Jul  7 16:12:38 localhost kernel: other info that might help us debug this:
Jul  7 16:12:38 localhost kernel: no locks held by hwclock/479.
Jul  7 16:12:38 localhost kernel:
Jul  7 16:12:38 localhost kernel: stack backtrace:
Jul  7 16:12:38 localhost kernel:  [<c0405167>] show_trace_log_lvl+0x54/0xfd
Jul  7 16:12:38 localhost kernel:  [<c040571e>] show_trace+0xd/0x10
Jul  7 16:12:38 localhost kernel:  [<c040583d>] dump_stack+0x19/0x1b
Jul  7 16:12:38 localhost kernel:  [<c043a982>] print_usage_bug+0x1ca/0x1d7
Jul  7 16:12:38 localhost kernel:  [<c043acc8>] mark_lock+0x96/0x36a
Jul  7 16:12:38 localhost kernel:  [<c043b9fa>] __lock_acquire+0x3b2/0x98d
Jul  7 16:12:38 localhost kernel:  [<c043c546>] lock_acquire+0x4b/0x6d
Jul  7 16:12:38 localhost kernel:  [<c060eb8c>] _spin_lock_irq+0x1f/0x2e
Jul  7 16:12:38 localhost kernel:  [<c053d07d>] rtc_get_rtc_time+0x1c/0x177
Jul  7 16:12:38 localhost kernel:  [<c0419824>] hpet_rtc_interrupt+0x92/0x14d
Jul  7 16:12:38 localhost kernel:  [<c04516ec>] handle_IRQ_event+0x20/0x4d
Jul  7 16:12:38 localhost kernel:  [<c04517ad>] __do_IRQ+0x94/0xef
Jul  7 16:12:38 localhost kernel:  [<c04066c8>] do_IRQ+0xb9/0xcd
Jul  7 16:12:38 localhost kernel:  [<c04049d1>] common_interrupt+0x25/0x2c


Expected results:

No messages about lock bugs.

Additional info:

Reporting because davej says so: http://kernelslacker.livejournal.com/41321.html