linux-kernel - Re: commit "radeonfb: Fix resume from D3Cold on some platforms" breaks resume from RAM on PowerBook

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Mar 2009 09:37:44 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Gaudenz Steinlin <gaudenz@...iologie.ch>
Cc:	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: commit "radeonfb: Fix resume from D3Cold on some platforms"
 breaks resume from RAM on PowerBook

On Fri, 2009-03-06 at 12:41 +0100, Gaudenz Steinlin wrote:

> > Another thing you can try in radeonfb_pci_resume():
> > 
> >         if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
> > +		pci_restore_state(pdev);
> 
> Adding this fixes the bug. Apparently the PCI core does not fully
> restore the state. Before your suggestions I also tried to find out
> which part of your commit breaks resume and I found out that if I
> reinsert the parts to save and restore the pci configuration the bug is
> fixed. It seems that somehow the PCI coniguration is not fully restored [1].  

Ok so this doesn't make sense to me at this stage... I see two
possibilities:

 1- You haven't properly done the test disabling the early resume hack
(ie, you may have done it with also CPU_FREQ disabled for example) and
got a false negative there. The platform code calls into the early
resume stuff before the PCI core gets a chance to restore things so that
would be an explanation. I'll send a patch fixing that.

or

 2- For some reason, the core call to pci_raw_set_power_state() from
pci_restore_standard_config() is returning an error. That would cause
the later not to restore the rest of the config.

So what I suggest is that while keeping your added pci_restore_state()
in there, you also add some printk's in pci_restore_standard_config() to
see anything weird happens in there or if it appears to properly call
pci_restore_state(). It would be useful for us to know.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/