public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
* Re: S2RAM and PCI quirks
       [not found]   ` <1163001711.23956.30.camel@localhost.localdomain>
@ 2006-11-08 21:18     ` Rafael J. Wysocki
  2006-11-08 23:47       ` Pavel Machek
  0 siblings, 1 reply; 2+ messages in thread
From: Rafael J. Wysocki @ 2006-11-08 21:18 UTC (permalink / raw)
  To: Alan Cox; +Cc: Arjan van de Ven, linux-kernel, Pavel Machek, pm list

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: S2RAM and PCI quirks
  2006-11-08 21:18     ` S2RAM and PCI quirks Rafael J. Wysocki
@ 2006-11-08 23:47       ` Pavel Machek
  0 siblings, 0 replies; 2+ messages in thread
From: Pavel Machek @ 2006-11-08 23:47 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: pm list, linux-kernel, Alan Cox, Arjan van de Ven

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-11-08 23:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1163000705.23956.18.camel@localhost.localdomain>
     [not found] ` <1163000924.3138.342.camel@laptopd505.fenrus.org>
     [not found]   ` <1163001711.23956.30.camel@localhost.localdomain>
2006-11-08 21:18     ` S2RAM and PCI quirks Rafael J. Wysocki
2006-11-08 23:47       ` Pavel Machek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox