S2RAM and PCI quirks

S2RAM and PCI quirks

[Alan Cox]

I'm tracing down a case where suspend to ram/resume from RAM causes
horrible corruption but not immediately. From a PCI dump it appears that
we are not running the PCI quirks again on the S2RAM resume. Is this
actually the case or am I missing something scanning through the code.
If it is the case then we have multiple corruptors lurking because the
PCI config restore doesn't cover the special registers that need poking
in some cases.

Alan

Re: S2RAM and PCI quirks

[Arjan van de Ven]

On Wed, 2006-11-08 at 15:45 +0000, Alan Cox wrote:
> I'm tracing down a case where suspend to ram/resume from RAM causes
> horrible corruption but not immediately. From a PCI dump it appears that
> we are not running the PCI quirks again on the S2RAM resume. Is this
> actually the case or am I missing something scanning through the code.
> If it is the case then we have multiple corruptors lurking because the
> PCI config restore doesn't cover the special registers that need poking
> in some cases.

at the same time I'm not 100% convinced it's ok to always run all quirks
at resume, for one the difference is that there now is a driver active
owning the device... Almost sounds like having a per quirk flag stating
"run at resume" is needed ;-(

(also I think the quirks are currently __init but that's relatively easy
to fix)

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: S2RAM and PCI quirks

[Alan Cox]

Ar Mer, 2006-11-08 am 16:48 +0100, ysgrifennodd Arjan van de Ven:
> at the same time I'm not 100% convinced it's ok to always run all quirks
> at resume, for one the difference is that there now is a driver active
> owning the device... Almost sounds like having a per quirk flag stating
> "run at resume" is needed ;-(

We probably need a quirk class for resume in this situation. The kind of
things that worry me if we are not doing the quirk handling, and what I
suspect happened in the case I looked at are that chipset bug
workarounds did not get restored, and in this case the older VIA chipset
involved then corrupted DMA streams and trashed the users disk.

> (also I think the quirks are currently __init but that's relatively easy
> to fix)

Some are yes, but not others.

Alan

Re: S2RAM and PCI quirks

[Rafael J. Wysocki]

On Wednesday, 8 November 2006 17:01, Alan Cox wrote:
> Ar Mer, 2006-11-08 am 16:48 +0100, ysgrifennodd Arjan van de Ven:
> > at the same time I'm not 100% convinced it's ok to always run all quirks
> > at resume, for one the difference is that there now is a driver active
> > owning the device... Almost sounds like having a per quirk flag stating
> > "run at resume" is needed ;-(
> 
> We probably need a quirk class for resume in this situation. The kind of
> things that worry me if we are not doing the quirk handling, and what I
> suspect happened in the case I looked at are that chipset bug
> workarounds did not get restored, and in this case the older VIA chipset
> involved then corrupted DMA streams and trashed the users disk.

Now that would explain why many boxes resume from disk correctly, but don't
resume from RAM by any means.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: [linux-pm] S2RAM and PCI quirks

[Pavel Machek]

On Wed 2006-11-08 22:18:54, Rafael J. Wysocki wrote:
> On Wednesday, 8 November 2006 17:01, Alan Cox wrote:
> > Ar Mer, 2006-11-08 am 16:48 +0100, ysgrifennodd Arjan van de Ven:
> > > at the same time I'm not 100% convinced it's ok to always run all quirks
> > > at resume, for one the difference is that there now is a driver active
> > > owning the device... Almost sounds like having a per quirk flag stating
> > > "run at resume" is needed ;-(
> > 
> > We probably need a quirk class for resume in this situation. The kind of
> > things that worry me if we are not doing the quirk handling, and what I
> > suspect happened in the case I looked at are that chipset bug
> > workarounds did not get restored, and in this case the older VIA chipset
> > involved then corrupted DMA streams and trashed the users disk.
> 
> Now that would explain why many boxes resume from disk correctly, but don't
> resume from RAM by any means.

Well, there are other good reasons, too. (suspend-to-disk resume works
with hardware in mostly-initialized state, while suspend-to-ram resume
works with hardware in mostly-weird state). Yes, per-quirk "run me on
resume-from-ram" is probably the way forward.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html