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

David Brownell
2006-06-23T18:06:46Z

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