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

[Robert Hancock]

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@xxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/