From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jesse Barnes <jesse.barnes@intel.com>,
Andreas Schwab <schwab@suse.de>, Len Brown <lenb@kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: PCI PM: Restore standard config registers of all devices early
Date: Wed, 4 Feb 2009 00:23:02 +0100 [thread overview]
Message-ID: <200902040023.03843.rjw@sisk.pl> (raw)
In-Reply-To: <1233701977.16867.104.camel@pasglop>
On Tuesday 03 February 2009, Benjamin Herrenschmidt wrote:
>
> > You've found a bug somewhere.
>
> Yup :-)
>
> > We _should_ be saving things, the legacy code does something like this:
> >
> > if (drv && drv->suspend) {
> > pci_dev->state_saved = false;
> >
> > i = drv->suspend(pci_dev, state);
> > suspend_report_result(drv->suspend, i);
> > if (i)
> > return i;
> >
> > if (pci_dev->state_saved)
> > goto Fixup;
> >
> > if (WARN_ON_ONCE(pci_dev->current_state != PCI_D0))
> > goto Fixup;
>
> It looks like the above is what breaks. Looks like current_state is
> UNKNOWN. The device is an old mach64 that has no PCI PM capability, thus
> the driver doesn't call any PCI PM stuff, the state basically stays set
> to what the core set it to at probe time which appears to be
> PCI_UNKNOWN.
Overlooked, sorry.
> Thus we don't call pci_save_state().
>
> Then ...
>
> > }
> >
> > pci_save_state(pci_dev);
> >
> > ie if your ->suspend function doesn't use pci_save_state() itself (which
> > sets that "state_saved" flag to true), then the generic code will do it
> > for you.
> >
> > Also, on the resume path, we actually have
> >
> > if (pci_dev->state_saved)
> > pci_restore_standard_config(pci_dev);
> >
> > so I wonder how the heck you got that blast of all zeroes - because we
> > clearly shouldn't be trying to restore any unsaved state!
>
> Well, that's it ... we don't actually test pci_dev->state_saved in
> whatever is currently upstream. The code is:
>
> static void pci_pm_default_resume_noirq(struct pci_dev *pci_dev)
> {
> pci_restore_standard_config(pci_dev);
> pci_fixup_device(pci_fixup_resume_early, pci_dev);
> }
>
> Oops...
The assumption here is that the state will be saved either by the driver
or by the core, so the bug here is a consequence of the previous one.
I'll add a check.
> Rafael, the second one is trivial to fix, but what about the first one ?
> Should we not count UNKNOWN in that goto or should we set legacy stuff
> that don't do PCI PM to PCI_D0 somewhere ? Or both ? :-)
Well, if the state is UNKNOWN, I think it's safe to save the config, so the
WARN_ON should really catch the low power states only. I'll fix that.
Thanks for debugging it!
Rafael
next prev parent reply other threads:[~2009-02-03 23:23 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200901261904.n0QJ4Q9c016709@hera.kernel.org>
2009-02-02 9:54 ` PCI PM: Restore standard config registers of all devices early Benjamin Herrenschmidt
2009-02-02 17:06 ` Linus Torvalds
2009-02-02 20:29 ` Benjamin Herrenschmidt
2009-02-02 20:41 ` Linus Torvalds
2009-02-02 21:00 ` Benjamin Herrenschmidt
2009-02-02 21:32 ` Rafael J. Wysocki
2009-02-02 20:33 ` Benjamin Herrenschmidt
2009-02-02 20:50 ` Linus Torvalds
2009-02-02 20:55 ` Linus Torvalds
2009-02-02 21:19 ` Benjamin Herrenschmidt
2009-02-02 21:39 ` Rafael J. Wysocki
2009-02-02 22:05 ` Linus Torvalds
2009-02-02 22:09 ` Linus Torvalds
2009-02-02 22:31 ` Rafael J. Wysocki
2009-02-02 23:18 ` Linus Torvalds
2009-02-02 23:45 ` Rafael J. Wysocki
2009-02-02 23:59 ` Linus Torvalds
2009-02-03 0:15 ` Rafael J. Wysocki
2009-02-03 0:28 ` Linus Torvalds
2009-02-03 1:12 ` Benjamin Herrenschmidt
2009-02-03 1:32 ` Linus Torvalds
2009-02-03 1:46 ` Benjamin Herrenschmidt
2009-02-03 3:30 ` Benjamin Herrenschmidt
2009-02-03 3:47 ` Linus Torvalds
2009-02-03 4:03 ` Benjamin Herrenschmidt
2009-02-03 6:07 ` Benjamin Herrenschmidt
2009-02-03 15:48 ` Linus Torvalds
2009-02-03 22:59 ` Benjamin Herrenschmidt
2009-02-03 23:23 ` Rafael J. Wysocki [this message]
2009-02-03 16:33 ` Jesse Barnes
2009-02-03 0:15 ` Linus Torvalds
2009-02-03 0:58 ` Benjamin Herrenschmidt
2009-02-03 3:51 ` Benjamin Herrenschmidt
2009-02-03 3:55 ` Benjamin Herrenschmidt
2009-02-03 4:09 ` Linus Torvalds
2009-02-03 4:21 ` Benjamin Herrenschmidt
2009-02-03 9:26 ` Rafael J. Wysocki
2009-02-03 17:04 ` Reworking suspend-resume sequence (was: Re: PCI PM: Restore standard config registers of all devices early) Rafael J. Wysocki
2009-02-03 17:59 ` Linus Torvalds
2009-02-03 18:31 ` Linus Torvalds
2009-02-03 18:41 ` Ingo Molnar
2009-02-03 18:32 ` Jesse Barnes
2009-02-03 18:46 ` Linus Torvalds
2009-02-03 19:03 ` Linus Torvalds
2009-02-03 19:13 ` Ingo Molnar
2009-02-03 19:38 ` Linus Torvalds
2009-02-03 19:53 ` Ingo Molnar
2009-02-03 20:04 ` Ingo Molnar
2009-02-03 20:18 ` Linus Torvalds
2009-02-03 20:57 ` Ingo Molnar
2009-02-03 21:04 ` Ingo Molnar
2009-02-03 21:12 ` Thomas Gleixner
2009-02-04 10:07 ` Russell King
2009-02-03 21:18 ` Linus Torvalds
2009-02-03 19:19 ` Linus Torvalds
2009-02-03 21:11 ` Benjamin Herrenschmidt
2009-02-03 21:53 ` Rafael J. Wysocki
2009-02-03 22:33 ` Benjamin Herrenschmidt
2009-02-03 22:44 ` Rafael J. Wysocki
2009-02-03 23:05 ` Benjamin Herrenschmidt
2009-02-03 23:18 ` Linus Torvalds
2009-02-04 0:27 ` Benjamin Herrenschmidt
2009-03-04 8:02 ` Pavel Machek
2009-03-04 23:25 ` Benjamin Herrenschmidt
2009-03-05 8:19 ` Pavel Machek
2009-03-05 19:09 ` Rafael J. Wysocki
2009-02-03 23:25 ` Rafael J. Wysocki
2009-02-04 0:46 ` Linus Torvalds
2009-02-03 21:02 ` Benjamin Herrenschmidt
2009-02-03 21:56 ` Rafael J. Wysocki
2009-02-03 17:53 ` PCI PM: Restore standard config registers of all devices early Linus Torvalds
2009-02-03 21:57 ` Rafael J. Wysocki
2009-02-02 22:48 ` Benjamin Herrenschmidt
2009-02-02 23:00 ` Rafael J. Wysocki
2009-02-03 0:23 ` Benjamin Herrenschmidt
2009-02-03 0:29 ` Rafael J. Wysocki
2009-02-03 0:44 ` Linus Torvalds
2009-02-03 1:32 ` Benjamin Herrenschmidt
2009-02-03 5:06 ` Ingo Molnar
2009-02-03 11:06 ` Peter Zijlstra
2009-02-03 12:09 ` Ingo Molnar
2009-02-02 23:49 ` Ingo Molnar
2009-02-03 22:09 ` Rafael J. Wysocki
2009-02-03 23:13 ` Linus Torvalds
2009-02-02 22:28 ` Benjamin Herrenschmidt
2009-02-02 21:07 ` Benjamin Herrenschmidt
2009-02-02 21:49 ` Rafael J. Wysocki
2009-02-02 22:15 ` Linus Torvalds
2009-02-02 22:33 ` Rafael J. Wysocki
2009-02-02 22:56 ` Rafael J. Wysocki
2009-02-03 0:11 ` Benjamin Herrenschmidt
2009-02-03 0:21 ` Linus Torvalds
2009-02-10 20:25 ` Pavel Machek
2009-02-02 22:57 ` Benjamin Herrenschmidt
2009-02-02 23:22 ` Rafael J. Wysocki
2009-02-03 1:03 ` Benjamin Herrenschmidt
2009-02-10 20:25 ` kmalloc during suspend, was " Pavel Machek
2009-02-02 17:20 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200902040023.03843.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=benh@kernel.crashing.org \
--cc=jesse.barnes@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=schwab@suse.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox