Re: [PATCH 2/2] Fix console handling during suspend/resume

[Pavel Machek <pavel@suse.cz>]

On Wed 2006-07-05 16:03:29, David Brownell wrote:
> On Wednesday 05 July 2006 1:12 pm, Linus Torvalds wrote:
> > 
> > On Wed, 5 Jul 2006, David Brownell wrote:
> > > 
> > > I expect this is what you meant, but one issue I've observed
>                     ^ "NOT" ... omitted by editing error, sorry
> > > on at least one platform is that after swsusp resume the preempt
> > > count is goofed ... it's one too big.  Which in a recent test, meant
> > > that resume failed because pci_set_power_state() got called in a
> > > context that couldn't msleep().  And in previous tests has led to
> > > similar failures, since resume() calls all expect sleeping is OK
> > > (since that's part of that API contract).
> > 
> > Yes. 
> > 
> > I had a patch that did
> > 
> > 	system_state = SYSTEM_BOOTING;
> > 	..
> > 	system_state = SYSTEM_RUNNING;
> > 
> > around the final stages of suspend/resume, because the resume stage really 
> > _does_ end up looking like the boot: single CPU, various special code etc.
> > 
> > And that gets rid of some of the warnings, and is arguably a valid thing 
> > to do (exactly because it's "true" to some degree that we're in the bootup 
> > state).
> 
> Didn't try that.  In this case, debug diagnostics confirmed that what
> was happening was pretty strange (to me):  the preempt count was goofed.
> It was correct as the snapshot was being taken, but wrong after that
> snapshot got resumed.

I have seen that before: Atomic snapshot used fpu copy in some wrong
variants. Symptom was exactly that -- elevated preempt count --
because fpu copy routine elevated it, then copied the task struct.

But I thought we solved that problem...?
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html