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

Pavel Machek
2006-07-06T01:15:10Z

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