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

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

On Thursday 22 June 2006 12:23 pm, Linus Torvalds wrote:
> 
> On Thu, 22 Jun 2006, David Brownell wrote:
> 
> > On Thursday 22 June 2006 9:10 am, Linus Torvalds wrote:
> > > 
> > > The fact that worries me is that suspend-to-ram DOES NOT WORK FOR PEOPLE. 
> > > I have never _ever_ met a laptop or machine of mine that "just worked". 
> > > I've always had to fix something, and people always end up having to do 
> > > something ridiculous like unlink all modules etc.
> > 
> > And when I've looked at the causes of such problems, they've been
> > either (a) driver bugs, or (b) ACPI bugs.  As you know, both of
> > them are hard to debug, especially when the symptom is on resume
> > paths with no console.  (Oooh, see $SUBJECT, this isn't offtopic!!)
> 
> EXACTLY.
> 
> We're back to square one.
> 
> The #1 problem _by_far_ with suspend has absolutely ZERO to do with 
> suspend being "hard", block device queues, or how to save driver state per 
> se.
> 
> Each individual driver tends to be fairly easy to fix, I'd say. I suspect 
> that even USB in the end is just a "Small Matter Of Programming", but it's 
> a total bitch to debug.

Actually, testing is more of a problem, given the 2^(about 8) different
configurations, with different fault paths in each.  That one is never
going away, while the "is printk available" issue has at least had some
system-specific workarounds.


> Our problem is that it's damn hard to debug the mess, AND A LARGE PART OF 
> THAT IS THAT STUPID INTERFACE!

Specifically, that the interface de-facto includes "printk unavailable"
during interesting sequence like resume, so there's no way to see what
broke and when.


> Let's revisit why I want to do as much _independently_ of actually calling 
> suspend() on a device again:
> 
>  - debugging is basically impossible during the _actual_ suspend sequence.
> 
> This is why we want to (nay, NEED) to split that "suspend()" function up, 
> so that it doesn't do five different things. The more we can do _outside_ 
> of suspend(), the better. Exactly because suspend() is a total bitch to 
> debug, and because in order to actually do things like printk() and use 
> netconsole, we want to minimize the amount of code that gets run in that 
> state.

Seriously, suspend() tends to be less of a problem than resume().  Which
is why I'm lukewarm to notions of refactoring suspend().

Going from a first-principles model based approach, the conceptual issue
is that providing a console has to date been purely a side effect of the
driver model suspend and resume sequences.  There are multiple sequences
of driver suspend/resume calls which observe the parent/child constraints,
but there's no effort to keep a consoles maximally active.

- Dave