Messages in this thread |  | | | From | "Rafael J. Wysocki" <> | | Subject | Re: [Linux 2.6.29-rc2] BUG: using smp_processor_id() in preemptible | | Date | Mon, 26 Jan 2009 17:53:34 +0100 |
| |
On Monday 26 January 2009, Linus Torvalds wrote: > > On Sat, 17 Jan 2009, Maciej Rutecki wrote: > > > > During suspend to ram: > > [ 131.287012] BUG: using smp_processor_id() in preemptible [00000000] > > code: suspend_to_ram./2958 > > [ 131.287012] caller is retrigger_next_event+0x13/0xb0 > > [ 131.287012] Pid: 2958, comm: suspend_to_ram. Not tainted 2.6.29-rc2 #1 > > [ 131.287012] Call Trace: > > [ 131.287012] [<c025b41f>] debug_smp_processor_id+0xbf/0xd0 > > [ 131.287012] [<c01473b3>] retrigger_next_event+0x13/0xb0 > > [ 131.287012] [<c01489b7>] raw_notifier_call_chain+0x17/0x20 > > [ 131.287012] [<c014b938>] timekeeping_resume+0xe8/0x110 > > [ 131.287012] [<c02cc651>] __sysdev_resume+0x11/0x50 > > [ 131.287012] [<c02cc6d7>] sysdev_resume+0x47/0x80 > > [ 131.287012] [<c02d2478>] device_power_up+0x8/0x10 > > Very scary. > > device_power_up() calls sysdev_resume _before_ it enables interrupts so it > sounds like something else has - very incorrectly - enabled interrupts too > early in your resume sequence. > > The patch that Andrew sent out and that apparently fixed things for you > should absolutely not have made any difference. This is suspend_enter(): > > arch_suspend_disable_irqs(); > BUG_ON(!irqs_disabled()); > > if ((error = device_power_down(PMSG_SUSPEND))) { > printk(KERN_ERR "PM: Some devices failed to power down\n"); > goto Done; > } > > if (!suspend_test(TEST_CORE)) > error = suspend_ops->enter(state); > > device_power_up(PMSG_RESUME); > Done: > arch_suspend_enable_irqs(); > > and notice how the whole thing is surrounded by that > arch_suspend_disable/enable_irqs(). > > So it looks like some sysdev driver (device_power_up does the sysdev > drivers first, so it can't be the regular low-level PCI drivers) is > enabling interrupts in its resume function. Scary and very wrong. > > It could easily be ACPI, of course. There was some other case where ACPI > did that, iirc.
There is a known bug in the USB controllers' suspend that enables interrupts from within ->suspend_late(). It should be fixed by the next USB merge AFAICS.
Thanks, Rafael
|  |