On Wed, 13 Oct 2010 15:38:13 +0900, MyungJoo Ham wrote: > On Wed, Oct 13, 2010 at 3:26 PM, Greg KH <gregkh@xxxxxxx> wrote: > > On Wed, Oct 13, 2010 at 02:58:06PM +0900, MyungJoo Ham wrote: > > Is this a regression? If so, from what working kernel? Or has this > > always been this way? > > I don't think this is a regression to the previous version. Logically, > it's matching the console_stop()-console_start() pair. This disparity appeared deliberately in 4547be78. If you need no_console_suspend and the hardware lets the device in an undefined state after resume (i. e. PXA270), you need to call subset of the resume, even if the suspend counterpart was not called. Yes, I can imagine that it may be a source of problems. Did you try the latest patches from Jason Wang from linux-serial list? > Such hang in serial and its mitigation is observed in 2.6.36 at > arch/arm/mach-s5pv310 machines. In these machines, it hanged with > console_suspend_enabled == 0 every time. It seems that support for no_console_suspend for all devices is becoming more complicated. I guess that a new driver calls (maybe "save_state" and "resume_state") or support for no_console_suspend directly in drivers may be useful. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@xxxxxxx Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
