In next-20080530 and next-20080602 (and possibly earlier - I can't remember the linux-next tree before that I tried) I get the following: [ 12.885153] ------------[ cut here ]------------ [ 12.885203] WARNING: at kernel/lockdep.c:2680 check_flags+0x98/0x151() [ 12.885248] Pid: 4, comm: watchdog/0 Not tainted 2.6.26-rc4-next-20080602 #13 [ 12.885292] [ 12.885293] Call Trace: [ 12.885364] [<ffffffff8022bbd5>] warn_on_slowpath+0x58/0x8a [ 12.885410] [<ffffffff804c9cfe>] ? _spin_unlock_irqrestore+0x51/0x6d [ 12.885455] [<ffffffff8032ff41>] ? debug_locks_off+0x9/0x3c [ 12.885498] [<ffffffff802582dd>] ? ftrace_record_ip+0x1fa/0x272 [ 12.885542] [<ffffffff8025278a>] ? watchdog+0xc5/0x1ff [ 12.885584] [<ffffffff8020b2c0>] ? mcount_call+0x5/0x35 [ 12.885627] [<ffffffff8025278a>] ? watchdog+0xc5/0x1ff [ 12.885668] [<ffffffff80247c80>] check_flags+0x98/0x151 [ 12.885710] [<ffffffff8024ae72>] lock_acquire+0x4a/0xa9 [ 12.885753] [<ffffffff8025278a>] ? watchdog+0xc5/0x1ff [ 12.885795] [<ffffffff802526c5>] ? watchdog+0x0/0x1ff [ 12.885837] [<ffffffff804c98da>] _read_lock+0x37/0x43 [ 12.885879] [<ffffffff8025278a>] watchdog+0xc5/0x1ff [ 12.885921] [<ffffffff802526c5>] ? watchdog+0x0/0x1ff [ 12.885963] [<ffffffff8023e48b>] kthread+0x4e/0x7b [ 12.886005] [<ffffffff8020bf18>] child_rip+0xa/0x12 [ 12.886046] [<ffffffff80227d8f>] ? finish_task_switch+0x57/0x92 [ 12.886090] [<ffffffff804c9d55>] ? _spin_unlock_irq+0x3b/0x57 [ 12.886133] [<ffffffff8020bad3>] ? restore_args+0x0/0x30 [ 12.886137] [<ffffffff8023e43d>] ? kthread+0x0/0x7b [ 12.886137] [<ffffffff8020bf0e>] ? child_rip+0x0/0x12 [ 12.886137] [ 12.886137] ---[ end trace 60e7f098a6913839 ]--- [ 12.886137] possible reason: unannotated irqs-on. [ 12.886137] irq event stamp: 20 [ 12.886137] hardirqs last enabled at (19): [<ffffffff80249cc3>] trace_hardirqs_on+0xd/0xf [ 12.886137] hardirqs last disabled at (20): [<ffffffff80248565>] trace_hardirqs_off+0xd/0xf [ 12.886137] softirqs last enabled at (0): [<ffffffff80229fef>] copy_process+0x2da/0x109e [ 12.886137] softirqs last disabled at (0): [<0000000000000000>] 0x0 Do I understand this correctly that something enabled irqs in a way that got around lockdep? I assume the problem is not in watchdog, just that the watchdog was the next thing to run that interacted with irqs and thus lockdep picked up the situation then? Is there additional debugging I can do, given some instructions? If the cause is readily apparent to anyone, could they let me know (for my own interest) why it is apparent so that I can investigate things like this further next time? This is completely reproducible on every boot - should I try to bisect it? -- Kevin Winchester --
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Greg Kroah-Hartman | [PATCH 007/196] Chinese: add translation of stable_kernel_rules.txt |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
git: | |
| Alexey Dobriyan | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [BUG] New Kernel Bugs |
