Message-Id: <1247801913.19112.96.camel@falcon>
Date:	Fri, 17 Jul 2009 11:38:33 +0800
From:	Wu Zhangjin <wuzhangjin@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	linux-pm@...ts.linux-foundation.org, len.brown@...el.com,
	yanh@...ote.com, linux-kernel@...r.kernel.org, zhangfx@...ote.com,
	pavel@....cz
Subject: Re: [linux-pm] [PATCH] [suspend] pci_raw_set_power_state: replace
 msleep by udelay in resuming procedure

On Fri, 2009-07-17 at 04:33 +0200, Rafael J. Wysocki wrote:
> On Friday 17 July 2009, Wu Zhangjin wrote:
> > 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.
> 
> 'standby' is a system sleep state, while 'current_state' and 'state' refer to
> device power states.
> 

Yeap, when changing from D3 to D0, it is a procedure of resuming from a
sleep state. resuming from 'standby' is such a procedure, but resuming
from a sleep state maybe include the other situations, so, this
judgement is really wrong here.

> Anyway, the fact that schedule() did not return in your testing setup indicates
> that there were no timer interrupts delivered to the CPU during resume, which
> should not have happened.
> 
> Perhaps it's necessary to annotate your timer interrupts appropriately so that
> they are not disabled during suspend?

You are right:

I'm using an external timer(cs5536 mfgpt timer), and because this works
well in linux-2.6.27, so, I never doubted with it in 2.6.30.1, I just
using the MIPS timer instead of it, works well. so, It must be the
problem of the mfgpt timer, it maybe disabled or not enabled before
device_power_up(PMSG_RESUME) in 2.6.30.1, I will check it later.

Thanks very much!

Regards,
Wu Zhangjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists