Hi, On Thu, 2009-07-16 at 13:02 -0400, Alan Stern wrote: > On Thu, 16 Jul 2009, Wu Zhangjin wrote: > > > we can not call msleep() when resuming from STR/Standby: if the > > current_state of the pci device is PCI_D3hot, means we are in the > > procedure of resuming, in this procedure, we can not re-schedule, > > otherwise, there will be a deadlock. > > I don't understand. > > First of all, why does current_state == PCI_D3hot mean the system is > resuming from sleep? Isn't it possible that the PCI device is going > through a runtime resume? > > Secondly, why will scheduling during a resume cause a deadlock? Sorry, I'm stupid to make conclusion before describing the problem clearly, here is the problem I encountered: when I enabled SUSPEND=y in linux-2.6.30.1(with relative patches) on a loongson-based machine(yeeloong laptop,loongson is mips-compatiable), I tried to suspend it via "echo standby > /sys/power/state", with the serial port debugging support, I found it enter into the standby mode successfully. and then, tried to wake it up via the keyboard interrupt, but it stopped at the "Power_up_devices:" of kernel/power/main.c. here is a short path of this procedure: suspend_enter: ... device_power_down ... arch_suspend_disable_irqs ... sysdev_suspend ... suspend_ops->enter (board-specific part) ... sysdev_resume ... arch_suspend_enable_irqs ... device_power_up <-----------------------stop here ... and then I continue to trace it: device_power_up: dpm_power_up: list_for_each_entry(dev, &dpm_list, power.entry) <<DEBUG>> if (dev->power.status > DPM_OFF) { int error; dev->power.status = DPM_OFF; error = resume_device_noirq(dev, state); if (error) pm_dev_err(dev, state, " early", error); } I tried to add prom_putchar() at <<DEBUG>> to print something, and This will make it resume from standby mode successfully. seems, prom_putchar() have influenced the power.status, and make some devices not enter into the condition statement, and make dpm_power_up return directly. (this is very weird, not sure why?) so, I removed the prom_putchar() from <<DEBUG>>, and it stopped at resume_device_noirq, here is the following tracing path: resume_device_noirq: --> pm_noirq_op --> ops->resume_noirq (dev) <--> pci_pm_resume_noirq: --> pci_pm_default_resume_noirq --> pci_restore_standard_config --> pci_set_power_state --> pci_raw_set_power_state --> msleep <-----------------------[ stop here] msleep: --> schedule_timeout_uninterruptible --> schedule_timeout --> ... --> __mod_timer --> ... --> schedule ---> a new scheduling happen and never return and then I tried to trace schedule(), and even added a prom_putchar() to the end of the schedule() function, it output something successfully, but never return to schedule_timeout(dead? no keyboard response), seems very weird! this is reproductive, perhaps I have missed something here. so, to avoid this 'weird' situation, I think it's better not to re-schedule in the resuming procedure from standby. and here, I can not find another condition to judge the resuming procedure from standby, so, I use "current_state == PCI_D3hot"(so, my pre-expression is really wrong for it maybe not resume from standby as you indicated). and is there another condition to judge we are resuming from standby? perhaps this is better: ((current_state == PCI_D3hot) && (state == PCI_D0)) but seems this also can not indicate we are resuming from standby. Regards, Wu Zhangjin _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm