linux-kernel - Re: [linux-pm] [PATCH] [suspend] pci_raw_set_power_state: replace msleep by udelay in resuming procedure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1247797085.19112.82.camel@falcon>
Date:	Fri, 17 Jul 2009 10:18:05 +0800
From:	Wu Zhangjin <wuzhangjin@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	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 10:10 +0800, 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;

traced the dev_name(dev) via serial port, and found it with lspci, it
is:

00:09.0 USB Controller: NEC Corporation USB (rev 44)

and the state here is D0, the current_sate is PCI_D3hot.

>                         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

--
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/