* Linus Torvalds <[email protected]> wrote:
> > this looks harmless
> >
> > [ 116.733327] PM: suspend-to-disk mode set to 'shutdown' [
> > 116.738849] swsusp: Basic memory bitmaps created [ 116.745353]
> > Stopping tasks ... WARNING: at
> > /home/devel/linux-git/kernel/lockdep.c:2414 check_flags()
> > [ 116.755052] irq event stamp: 69
> > [ 116.755060] hardirqs last enabled at (69): [<c04040f9>] syscall_exit_work+0x11/0x26
> > [ 116.755084] hardirqs last disabled at (68): [<c0403fdd>] syscall_exit+0x9/0x1a
> > [ 116.755109] softirqs last enabled at (0): [<c042150c>] copy_process+0x4dd/0x1286
> > [ 116.755139] softirqs last disabled at (0): [<00000000>] 0x0
> > [ 116.945776] done.
> Well, it's harmless in the sense that "yeah, the system still works",
> but it does seem to be a real bug. We have hardware interrupts
> disabled when we _think_ we should have them on, so our irq tracking
> is off.
>
> Ingo, do you see what's up? It looks like we got a signal to a process
> that just got created, is the setup stuff for "tsk->hardirqs_enabled"
> perhaps off a bit?
hm. I cannot see the source of the bug at the moment, but here's my
analysis so far:
the last event that irqtrace got was #69, and that was a 'hardirqs on'
in syscall_exit_work. After that we did a 'hardirqs off' without
properly tracking that via irqtrace. Next time we got an irqtrace event
(event 70) the assert caught up with us and turned off lockdep and
backed out of that function. This was in:
> [ 116.754957] [<c043c3e5>] check_flags+0x95/0x143
> [ 116.754967] [<c043f158>] lock_acquire+0x29/0x82
> [ 116.754977] [<c06313a7>] _spin_lock+0x35/0x42
> [ 116.754990] [<c044894a>] refrigerator+0x14/0xc6
> [ 116.755002] [<c042d4b3>] get_signal_to_deliver+0x33/0x397
> [ 116.755016] [<c0403597>] do_notify_resume+0x94/0x6ed
> [ 116.755029] [<c0404099>] work_notifysig+0x13/0x1a
isnt the refrigerator() suspend related? Perhaps suspend disables irqs
somewhere that we forgot to track?
a new thread gets its hardirqs_enabled this way:
#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
p->hardirqs_enabled = 1;
#else
p->hardirqs_enabled = 0;
#endif
on i386 __ARCH_WANT_INTERRUPTS_ON_CTXSW is off so it starts with 0. We
set this up in copy_process() so there's no chance this task can run
without this initialized.
Ingo
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
