linux-kernel - Re: S2RAM and PCI quirks

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:	Wed, 8 Nov 2006 22:18:54 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, Pavel Machek <pavel@....cz>,
	pm list <linux-pm@...ts.osdl.org>
Subject: Re: S2RAM and PCI quirks

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
-
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/