[linux-pm] [Suspend-devel] [PATCH -mm 1/2]: PM: Fix handling of stopped tasks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Friday, 8 December 2006 12:49, Rafael J. Wysocki wrote:
> On Friday, 8 December 2006 12:21, Pavel Machek wrote:
> > Hi!
> > 
> > > > > > > ...after resume.
> > > > > > 
> > > > > > This is because of how signal_wake_up() works, I think..
> > > > > > 
> > > > > > > But I think it is right approach.
> > > > > 
> > > > > Okay, with the appended patch applied everything seems to work and I don't
> > > > > see any undesirable side-effects.
> > > > 
> > > > I promise to try it... tommorow. Looks very good to me.
> > > 
> > > Unfortunately there's one problem with it.
> > 
> > Well, IIRC it still had the 'bash reports vi stopped twice' problem.
> 
> It doesn't do that for me, but ...
> 
> > > To reproduce it I run "gdb /bin/cat", execute "run" in gdb and press ^Z twice
> > > to stop both processes.  Next I suspend and resume and run "fg" to get the gdb
> > > back.and press "Enter" to get the prompt.  Then, it turns out that the
> > > terminal echo doesn't work and "Enter" doesn't make it go to the next line.
> > > I can recover from this state by typing "fg+Enter" (with no echo) so that
> > > /bin/cat gets the continuation signal and it restores the terminal settings,
> > > apparently.
> > 
> > I wonder if we should start a test suite ;-).
> > 
> > > This means, however, that with this patch the behavior of a process (gdb)
> > > after the resume may be different to its normal behavior, which is wrong.
> > 
> > Yep.
> > 
> > > With my original [1/2] this problem doesn't appear (ie. after the resume gdb
> > > behaves normally).  Thus I think that, although this patch is much more
> > > elegant, my original [1/2] is a safer solution, because we can say exactly
> > > what it does.
> > 
> > Original 1/2 indeed is 'safer'... but it is also too ugly to live.
> 
> Well, I don't agree with that. :-)
> 
> > Getting this to work should not be that hard,
> 
> But it would involve messing up with the scheduler, no?
> 
> > and I'd prefer not to add more tricky code to already-tricky process.c.

BTW, I think the alternative is even more tricky than [1/2] itself, although
the trickiness is not clearly visible in this case.

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux