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-next>] [day] [month] [year] [list]

Date:	Mon, 24 Dec 2007 16:40:46 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Carlos Corbacho <carlos@...angeworlds.co.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"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>,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4
 suspend-to-RAM

Carlos Corbacho wrote:
> On Monday 24 December 2007 18:34:21 Linus Torvalds wrote:
>> On Mon, 24 Dec 2007, Rafael J. Wysocki wrote:
>>> Well, having considered that for a longer while, I think the AML code is
>>> referring to a device that we have suspended already, and since it's in a
>>> low power state, it just can't handle the reference.
>>>
>>> If that is the case, we'll have to find the device (that should be
>>> possible using some code instrumentation) and move the suspending of it
>>> into the late stage.
>> Yes.
> 
> My own experimentation (in device_suspend(), calling _PTS() in the AML after 
> each suspend_device() runs, until one device causes it to hang) points to 
> ohci_hcd being the culprit here (with or without any devices attached). With 
> the ohci_hcd module unloaded, the machine suspends just fine[1].
> 
> Of course, I'm at a complete loss as to why suspending OHCI would cause a 
> problem for an IO port write.

The name of the operation region, SMIP, suggests that the BIOS has an 
SMI trap on that port. In that case, writing to that port will result in 
the BIOS taking control. We have little idea what it could be doing. 
Could be it's trying to access the OHCI controller which has been 
suspended already.

This sounds kind of like the Toshiba laptops that go nuts somewhere if 
the AHCI SATA controller gets put into suspend state before the system 
suspends..

The ACPI spec has the following to say about the _PTS method:

"The platform must not make any assumptions about the state of the 
machine when _PTS is called. For example, operation region accesses that 
require devices to be configured and enabled may not succeed, as these 
devices may be in a non-decoding state due to plug and play or power 
management operations."

I would guess some BIOS writers failed to heed this..

> 
>> NOTE! This following patch is just for discussion, and while I think it's
>> conceptually a good thing to try, I don't think it will help Carlos'
>> problem. But removing the "pci_set_power_state()" in agp_nvidia_suspend()
>> might.
> 
> nvidia-agp cannot be built on x86-64, so it's not the culprit in this case.

Yeah, and this is a PCI Express system not AGP, so it wouldn't load anyway.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

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