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
