)]}'
{
  "commit": "1d4a7f1c4faf53eb9e822743ec8a70b3019a26d2",
  "tree": "a3f54cd702bb48e19aa79e45deb7c4812ed0c177",
  "parents": [
    "934d96eafadcf3eb3ccd094af9919f020907fc41"
  ],
  "author": {
    "name": "Peter Zijlstra",
    "email": "peterz@infradead.org",
    "time": "Sun Jan 18 16:39:29 2009 +0100"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@elte.hu",
    "time": "Sun Jan 18 21:31:37 2009 +0100"
  },
  "message": "hrtimers: fix inconsistent lock state on resume in hres_timers_resume\n\nAndrey Borzenkov reported this lockdep assert:\n\n\u003e [17854.688347] \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\u003e [17854.688347] [ INFO: inconsistent lock state ]\n\u003e [17854.688347] 2.6.29-rc2-1avb #1\n\u003e [17854.688347] ---------------------------------\n\u003e [17854.688347] inconsistent {in-hardirq-W} -\u003e {hardirq-on-W} usage.\n\u003e [17854.688347] pm-suspend/18240 [HC0[0]:SC0[0]:HE1:SE1] takes:\n\u003e [17854.688347]  (\u0026cpu_base-\u003elock){++..}, at: [\u003cc0136fcc\u003e] retrigger_next_event+0x5c/0xa0\n\u003e [17854.688347] {in-hardirq-W} state was registered at:\n\u003e [17854.688347]   [\u003cc01443cd\u003e] __lock_acquire+0x79d/0x1930\n\u003e [17854.688347]   [\u003cc01455bc\u003e] lock_acquire+0x5c/0x80\n\u003e [17854.688347]   [\u003cc03092e5\u003e] _spin_lock+0x35/0x70\n\u003e [17854.688347]   [\u003cc0136e61\u003e] hrtimer_run_queues+0x31/0x140\n\u003e [17854.688347]   [\u003cc0128d98\u003e] run_local_timers+0x8/0x20\n\u003e [17854.688347]   [\u003cc0128dd3\u003e] update_process_times+0x23/0x60\n\u003e [17854.688347]   [\u003cc013e274\u003e] tick_periodic+0x24/0x80\n\u003e [17854.688347]   [\u003cc013e2e2\u003e] tick_handle_periodic+0x12/0x70\n\u003e [17854.688347]   [\u003cc0104e24\u003e] timer_interrupt+0x14/0x20\n\u003e [17854.688347]   [\u003cc01607b9\u003e] handle_IRQ_event+0x29/0x60\n\u003e [17854.688347]   [\u003cc0161c59\u003e] handle_level_irq+0x69/0xe0\n\u003e [17854.688347]   [\u003cffffffff\u003e] 0xffffffff\n\u003e [17854.688347] irq event stamp: 55771\n\u003e [17854.688347] hardirqs last  enabled at (55771): [\u003cc0309125\u003e] _spin_unlock_irqrestore+0x35/0x60\n\u003e [17854.688347] hardirqs last disabled at (55770): [\u003cc0309419\u003e] _spin_lock_irqsave+0x19/0x80\n\u003e [17854.688347] softirqs last  enabled at (54836): [\u003cc0124f54\u003e] __do_softirq+0xc4/0x110\n\u003e [17854.688347] softirqs last disabled at (54831): [\u003cc01049ae\u003e] do_softirq+0x8e/0xe0\n\u003e [17854.688347]\n\u003e [17854.688347] other info that might help us debug this:\n\u003e [17854.688347] 3 locks held by pm-suspend/18240:\n\u003e [17854.688347]  #0:  (\u0026buffer-\u003emutex){--..}, at: [\u003cc01dd4c5\u003e] sysfs_write_file+0x25/0x100\n\u003e [17854.688347]  #1:  (pm_mutex){--..}, at: [\u003cc015056f\u003e] enter_state+0x4f/0x140\n\u003e [17854.688347]  #2:  (dpm_list_mtx){--..}, at: [\u003cc027880f\u003e] device_pm_lock+0xf/0x20\n\u003e [17854.688347]\n\u003e [17854.688347] stack backtrace:\n\u003e [17854.688347] Pid: 18240, comm: pm-suspend Not tainted 2.6.29-rc2-1avb #1\n\u003e [17854.688347] Call Trace:\n\u003e [17854.688347]  [\u003cc0306248\u003e] ? printk+0x18/0x20\n\u003e [17854.688347]  [\u003cc0141fac\u003e] print_usage_bug+0x16c/0x1d0\n\u003e [17854.688347]  [\u003cc0142bcf\u003e] mark_lock+0x8bf/0xc90\n\u003e [17854.688347]  [\u003cc0106b8f\u003e] ? pit_next_event+0x2f/0x40\n\u003e [17854.688347]  [\u003cc01441b0\u003e] __lock_acquire+0x580/0x1930\n\u003e [17854.688347]  [\u003cc030916d\u003e] ? _spin_unlock+0x1d/0x20\n\u003e [17854.688347]  [\u003cc0106b8f\u003e] ? pit_next_event+0x2f/0x40\n\u003e [17854.688347]  [\u003cc013dd38\u003e] ? clockevents_program_event+0x98/0x160\n\u003e [17854.688347]  [\u003cc0142fe8\u003e] ? mark_held_locks+0x48/0x90\n\u003e [17854.688347]  [\u003cc0309125\u003e] ? _spin_unlock_irqrestore+0x35/0x60\n\u003e [17854.688347]  [\u003cc0143229\u003e] ? trace_hardirqs_on_caller+0x139/0x190\n\u003e [17854.688347]  [\u003cc014328b\u003e] ? trace_hardirqs_on+0xb/0x10\n\u003e [17854.688347]  [\u003cc01455bc\u003e] lock_acquire+0x5c/0x80\n\u003e [17854.688347]  [\u003cc0136fcc\u003e] ? retrigger_next_event+0x5c/0xa0\n\u003e [17854.688347]  [\u003cc03092e5\u003e] _spin_lock+0x35/0x70\n\u003e [17854.688347]  [\u003cc0136fcc\u003e] ? retrigger_next_event+0x5c/0xa0\n\u003e [17854.688347]  [\u003cc0136fcc\u003e] retrigger_next_event+0x5c/0xa0\n\u003e [17854.688347]  [\u003cc013711a\u003e] hres_timers_resume+0xa/0x10\n\u003e [17854.688347]  [\u003cc013aa8e\u003e] timekeeping_resume+0xee/0x150\n\u003e [17854.688347]  [\u003cc0273384\u003e] __sysdev_resume+0x14/0x50\n\u003e [17854.688347]  [\u003cc0273407\u003e] sysdev_resume+0x47/0x80\n\u003e [17854.688347]  [\u003cc02791ab\u003e] device_power_up+0xb/0x20\n\u003e [17854.688347]  [\u003cc015043f\u003e] suspend_devices_and_enter+0xcf/0x150\n\u003e [17854.688347]  [\u003cc0150c2f\u003e] ? freeze_processes+0x3f/0x90\n\u003e [17854.688347]  [\u003cc0150614\u003e] enter_state+0xf4/0x140\n\u003e [17854.688347]  [\u003cc01506dd\u003e] state_store+0x7d/0xc0\n\u003e [17854.688347]  [\u003cc0150660\u003e] ? state_store+0x0/0xc0\n\u003e [17854.688347]  [\u003cc0202da4\u003e] kobj_attr_store+0x24/0x30\n\u003e [17854.688347]  [\u003cc01dd53c\u003e] sysfs_write_file+0x9c/0x100\n\u003e [17854.688347]  [\u003cc019916c\u003e] vfs_write+0x9c/0x160\n\u003e [17854.688347]  [\u003cc0103494\u003e] ? restore_nocheck_notrace+0x0/0xe\n\u003e [17854.688347]  [\u003cc01dd4a0\u003e] ? sysfs_write_file+0x0/0x100\n\u003e [17854.688347]  [\u003cc01992ed\u003e] sys_write+0x3d/0x70\n\u003e [17854.688347]  [\u003cc0103371\u003e] sysenter_do_call+0x12/0x31\n\nAndrey\u0027s analysis:\n\n\u003e timekeeping_resume() is called via class -\u003eresume\n\u003e method; and according to comments in sysdev_resume() and\n\u003e device_power_up(), they are called with interrupts disabled.\n\u003e\n\u003e Looking at suspend_enter, irqs *are* disabled at this point.\n\u003e\n\u003e So it actually looks like something (may be some driver)\n\u003e unconditionally enabled irqs in resume path.\n\nAdd a debug check to test this theory. If it triggers then it\ntriggers because the resume code calls it with irqs enabled,\nwhich is a no-no not just for timekeeping_resume(), but also\nbad for a number of other resume handlers.\n\nReported-by: Andrey Borzenkov \u003carvidjaar@mail.ru\u003e\nSigned-off-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1455b7651b6b27f9343809260976a1df3e4678e6",
      "old_mode": 33188,
      "old_path": "kernel/hrtimer.c",
      "new_id": "cb83c6d4c07c4a4af861ccd57c14d6cdd71c2f7f",
      "new_mode": 33188,
      "new_path": "kernel/hrtimer.c"
    }
  ]
}