linux-kernel - Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM

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, 25 Dec 2007 20:29:02 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Robert Hancock <hancockr@...w.ca>,
	Carlos Corbacho <carlos@...angeworlds.co.uk>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	"H. Peter Anvin" <hpa@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Len Brown <lenb@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4
 suspend-to-RAM

On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
> >
> > Correct me if I'm wrong, but it appears ACPI 1.0 wants _PTS called 
> > before any devices are suspended, ACPI 2.0 is contradictory, and ACPI 
> > 3.0 says that you can't assume anything about device state. My guess is 
> > that unless Windows has different behavior depending on ACPI version, it 
> > probably has called _PTS before suspending devices all along. Therefore 
> > it would likely be safest to emulate that behavior, no?
> 
> Well, I don't think so.

It would *definitely* always be safest to emulate what Windows does. 

> In fact ACPI 3.0 repeats the 2.0 wording in section 9.1.6 (so the current
> requirement seems to be to put devices into low power states before calling
> _PTS) and I _guess_ there was a change in the default behavior of Windows that
> caused the specification to be modified (I'd bet that was between 2000 and XP
> or something like this).

You seem to put a lot of trust in a piece of documentation.

Do you realize how those pieces of paper are written? They are written by 
people who have absolutely *nothing* to do with the actual implementation, 
and whose job it is to write documentation. And while the people who 
actually do the programming etc are supposed to help them, the two parties 
generally detest each other.

Technical writers hate the "real engineers" for not helping them, and the 
"real engineers" tend to dislike having to be pestered to explain their 
stuff and have to read through some document that isn't meant for them, 
but that they need to sign off on.

In other words: please do *not* expect that the documentation actually 
matches reality. You seem to think that the documentation came first 
and/or is quite accurate. That's not at all likely to be true.

> IMO, we should check which version of the specification we're supposed to
> follow, on the basis of FADT contents, for example, and follow this one.

No, we should try to figure out what Windows does. *If* windows checks the 
version, we should do that too. But we should absolutely *not* just assume 
that the documentation is an accurate picture of reality.

Does anybody know how we could find out? 

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