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

[David Brownell <david-b@pacbell.net>]

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.


> At the same time, it's certainly equally arguable (or more so) that the 
> warnings are actually valid, even during bootup, and the code that causes 
> them should be fixed.

In this case, the warnings were clearly valid, and I'm perplexed at
what was making the preempt count go bad.


> > The last time I saw this problem I threw in a hack to drop that
> > count before starting the device resume calls, but I'm rather
> > curious why it happens at all.  Does this ring bells for anyone?
> 
> Some of the warnings will trigger for doing things like taking a semaphore 
> with interrupts disabled, or with a spinlock held (which will raise the 
> preemption count).

Preempt count corruption.  :(

Unfortunately right now I don't have a clue as to what did that, only
a workaround of forcing it to a sane value (decrement before resuming
the devices).  I'm kind of hoping someone else has noticed similar bugs,
and gotten beyond them.

- Dave