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

Benjamin Herrenschmidt
2006-06-22T23:31:36Z

> Why? Because if you do it the old way, STR will still happen to work. I'm
> just giving you a separate phase.
>
> But you're not interested in facts, are you? Nope.

Oh come on... you know my point, no use in repeating it again and again.
You think I'm wrong, that's your right. I'll continue making sure
powerbooks sleep and wakeup fine with whatever model is in there.
and 2- won't
> > help with the actual problems :)
>
> So you say. Have you actually ever done anything to make debugging easier?

I've implemented suspend/resume for a whole range of machiens where
everything goes down and all I have to debug on resume is ... sending
commands to a chip to blink a LED. So yes, I have. Remember things like
firescope etc ? I've hooks to wakeup the video chip earlier too, I've
done everything that is reasonably possible to make the things
debuggable as much as can be. And guess what ? None of the problems I've
had were ever related to something that would be in save_state. Most of
the problems where the driver being hit by something while asleep
(remember on powerpc I don't freeze processes, so I have a requirement
of being more "correct" than what happens on x86).

> Nope. In the years I've been frustrated with suspend, nobody has ever done
> anything to this. And now I have to push through changes, just because
> people think that "status quo" is acceptable.

In fact, most of the problem is resume, not suspend. Most of the time,
the machine goes to sleep... it just doesn't wakeup. From my experience
over the years, the main culprit for that have been

- USB (anything that bus masters while the memory controller is asleep
will trash your RAM and we had issues with USB being kicked back into
bus mastering (ignoring the command register bus master bit off) after
suspended).

- USB (again, sorry David) races and deadlocks etc... though most of
these have been fixed by now.

- CPU cache flush issues (mostly CPU erratas)

- Video (I've had to reverse engineer the POST code out of the macos
drivers for a range of radeon chips to get them back, that wasn't fun
and had issues for a while), plus problems with X and AGP that are
unrelated to the model

- cpufreq (this is a design bug with cpufreq with the "core/midlayer"
trying to get in charge instead of the driers and registering a sysdev
which is very wrong).

- occasional random drivers not properly handling getting a request
from userland after being put to sleep.

The #1 thing that helps for debugging is that hook I added to bring the
video chip back (and thus printk) very very very early (even before I
bring the L2 cache back). This is possible on machines where the video
card is not behind 3 layers of bridges (and even in this case, it's
generally possible to have a small hack that bring those bridges back
early). That's because 99% of the problems happen on resume not sleep.
When a driver crashes during sleep, debugging is easy: just do a fake
sleep (don't actually put the machine to sleep, just run through driver
suspend) and skip the video driver.

> > I've brought a real concern that you'll resume devices in a different
> > state than what was last set at suspend time and change a model that
> > isn't broken.
>
> And I've explained several times that your concerns aren't problems. You
> just ignore it.

No, I didn't ignore it. I however beleive that you are wrong and that
they are a problem :) And that the supposed benefit of splitting
save_state doesn't outweight that risk.

Ben.