| Message ID | 1237365385.3640.43.camel@localhost.localdomain (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Wed, Mar 18, 2009 at 04:36:25PM +0800, yakui_zhao wrote: > Subject: ACPI: Add the Pansonic CF51 box to the dmi check table > From: Zhao Yakui <yakui.zhao@intel.com> > > The Pansonic CF51-2L box can't be resumed if the boot option of > "acpi_sleep=old_ordering" is not added. Do we have any idea what's going on here, yet? Several of the machines on this blacklist are modern, so it's not a workaround for ancient hardware.
On Wed, 2009-03-18 at 21:41 +0800, Matthew Garrett wrote: > On Wed, Mar 18, 2009 at 04:36:25PM +0800, yakui_zhao wrote: > > Subject: ACPI: Add the Pansonic CF51 box to the dmi check table > > From: Zhao Yakui <yakui.zhao@intel.com> > > > > The Pansonic CF51-2L box can't be resumed if the boot option of > > "acpi_sleep=old_ordering" is not added. > > Do we have any idea what's going on here, yet? > Several of the machines > on this blacklist are modern, so it's not a workaround for ancient > hardware. Now we have no idea how the behaviour is changed with the boot option. In fact the boot option is useful for all the boxes that can't be resumed unless it is added. Although the machine is modern, the ACPI 1.0 is followed on this box. Without the boot option of "acpi_sleep=old_ordering", it can't be resumed from S3 correctly. But after adding the boot option, the box can be resumed. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 19, 2009 at 09:16:07AM +0800, yakui_zhao wrote: > On Wed, 2009-03-18 at 21:41 +0800, Matthew Garrett wrote: > > Do we have any idea what's going on here, yet? > > Several of the machines > > on this blacklist are modern, so it's not a workaround for ancient > > hardware. > Now we have no idea how the behaviour is changed with the boot option. > In fact the boot option is useful for all the boxes that can't be > resumed unless it is added. > > Although the machine is modern, the ACPI 1.0 is followed on this box. > Without the boot option of "acpi_sleep=old_ordering", it can't be > resumed from S3 correctly. But after adding the boot option, the box can > be resumed. Yes. So how do we tell which ordering a machine needs without having a blacklist? Windows doesn't.
On Thu, 2009-03-19 at 09:21 +0800, Matthew Garrett wrote: > On Thu, Mar 19, 2009 at 09:16:07AM +0800, yakui_zhao wrote: > > On Wed, 2009-03-18 at 21:41 +0800, Matthew Garrett wrote: > > > Do we have any idea what's going on here, yet? > > > Several of the machines > > > on this blacklist are modern, so it's not a workaround for ancient > > > hardware. > > Now we have no idea how the behaviour is changed with the boot option. > > In fact the boot option is useful for all the boxes that can't be > > resumed unless it is added. > > > > Although the machine is modern, the ACPI 1.0 is followed on this box. > > Without the boot option of "acpi_sleep=old_ordering", it can't be > > resumed from S3 correctly. But after adding the boot option, the box can > > be resumed. > > Yes. So how do we tell which ordering a machine needs without having a > blacklist? Windows doesn't. If there exists the different behaviour w/o the boot option, maybe it should be added to the blacklist. Maybe there is no such blacklist on windows. I verify this problem on windows by using KVM and find that the _PTS object is called after device suspend in course of hibernate.(No S3 is supported on KVM). In theory the _PTS is also called after device suspend in course of suspend. But it is strange that suspend/resume can work well on windows XP. Maybe more registers are saved/restored in course of suspend. But we can't know what should be saved/restored. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 19, 2009 at 10:42:02AM +0800, yakui_zhao wrote: > On Thu, 2009-03-19 at 09:21 +0800, Matthew Garrett wrote: > > Yes. So how do we tell which ordering a machine needs without having a > > blacklist? Windows doesn't. > > If there exists the different behaviour w/o the boot option, maybe it > should be added to the blacklist. > > Maybe there is no such blacklist on windows. Quite. There shouldn't be on Linux. > I verify this problem on windows by using KVM and find that the _PTS > object is called after device suspend in course of hibernate.(No S3 is > supported on KVM). In theory the _PTS is also called after device > suspend in course of suspend. What would it take to fake S3 on KVM enough that we could instrument Windows' behaviour? > But it is strange that suspend/resume can work well on windows XP. > Maybe more registers are saved/restored in course of suspend. But we > can't know what should be saved/restored. Nor can we continue adding machines to a blacklist.
On Thu, 2009-03-19 at 10:43 +0800, Matthew Garrett wrote: > On Thu, Mar 19, 2009 at 10:42:02AM +0800, yakui_zhao wrote: > > On Thu, 2009-03-19 at 09:21 +0800, Matthew Garrett wrote: > > > Yes. So how do we tell which ordering a machine needs without having a > > > blacklist? Windows doesn't. > > > > If there exists the different behaviour w/o the boot option, maybe it > > should be added to the blacklist. > > > > Maybe there is no such blacklist on windows. > > Quite. There shouldn't be on Linux. If there is no such blacklist, the suspend/resume can't wok well on some boxes. IMO this can be workaround for some boxes that can't be resumed. > > > I verify this problem on windows by using KVM and find that the _PTS > > object is called after device suspend in course of hibernate.(No S3 is > > supported on KVM). In theory the _PTS is also called after device > > suspend in course of suspend. > > What would it take to fake S3 on KVM enough that we could instrument > Windows' behaviour? The graphics simulated in KVM is too old. > > > But it is strange that suspend/resume can work well on windows XP. > > Maybe more registers are saved/restored in course of suspend. But we > > can't know what should be saved/restored. > > Nor can we continue adding machines to a blacklist. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 19, 2009 at 10:50:03AM +0800, yakui_zhao wrote: > On Thu, 2009-03-19 at 10:43 +0800, Matthew Garrett wrote: > > On Thu, Mar 19, 2009 at 10:42:02AM +0800, yakui_zhao wrote: > > > Maybe there is no such blacklist on windows. > > > > Quite. There shouldn't be on Linux. > If there is no such blacklist, the suspend/resume can't wok well on some > boxes. IMO this can be workaround for some boxes that can't be resumed. Workarounds should be temporary. Blacklists scale badly. In the long run we need to determine why this doesn't work. > > > I verify this problem on windows by using KVM and find that the _PTS > > > object is called after device suspend in course of hibernate.(No S3 is > > > supported on KVM). In theory the _PTS is also called after device > > > suspend in course of suspend. > > > > What would it take to fake S3 on KVM enough that we could instrument > > Windows' behaviour? > The graphics simulated in KVM is too old. Is this simply a matter of the driver setting a flag to indicate that it supports S3?
I agree with Matthew that we need to find the root cause. However, I've checked this into acpi-test in the interest of getting the box working w/o delay. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux-2.6/drivers/acpi/sleep.c =================================================================== --- linux-2.6.orig/drivers/acpi/sleep.c 2009-03-10 10:54:41.000000000 +0800 +++ linux-2.6/drivers/acpi/sleep.c 2009-03-10 11:39:42.000000000 +0800 @@ -378,6 +378,15 @@ DMI_MATCH(DMI_PRODUCT_NAME, "Macmini1,1"), }, }, + { + .callback = init_old_suspend_ordering, + .ident = "Pansonic CF51-2L", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, + "Matsushita Electric Industrial Co.,Ltd."), + DMI_MATCH(DMI_BOARD_NAME, "CF51-2L"), + }, + }, {}, }; #endif /* CONFIG_SUSPEND */