Re: [PATCH 0/11] ACPI: Fixes and cleanups related to iomaps management

Re: [PATCH 0/11] ACPI: Fixes and cleanups related to iomaps management

[Rafael J. Wysocki]

On Saturday, January 22, 2011, Jeff Chua wrote:
> 2011/1/22 Rafael J. Wysocki <rjw@sisk.pl>:
> > On Friday, January 21, 2011, Jeff Chua wrote:
> >> 2011/1/21 Rafael J. Wysocki <rjw@sisk.pl>:
> >> > Thanks, but unfortunately this wasn't conclusive.  Please apply the patch below
> >> > instead of the previous one (on top of [1/11] - [11/11]) and collect dmesg
> > So, below is a replacement for [11/11].  Please test it on top of
> > [1/11] - [10/11] (the current Linus' tree already contains [1/11] and [2/11])
> > and let me know if it works for you (in either case, please attach dmesg
> > output containing a suspend attempt).
> >
> > If it works, I'll remove the diagnostic messages and submit along with the
> > rest of the patchset.
> 
> Rafael,
> 
> dmesg attached. This time, it worked!

Great, thanks a lot!

> I discovered CONFIG_THINKPAD_ACPI caused suspend-to-disk to hang. I
> need the Thinkpad ACPI to control the fan and bluetooth. It looks like
> the thinkpad acpi is trying acquire locks while suspending.  Disabling
> cmos, light, led and hotkeys makes suspend-to-disk works again.

Well, we should tell the thinkpad_acpi maintainer about that, then (CCed).

It also would be good to file a Bugzilla report about that, if poss.

Rafael

Re: [PATCH 0/11] ACPI: Fixes and cleanups related to iomaps management

[Henrique de Moraes Holschuh]

On Sat, 22 Jan 2011, Rafael J. Wysocki wrote:
> > I discovered CONFIG_THINKPAD_ACPI caused suspend-to-disk to hang. I
> > need the Thinkpad ACPI to control the fan and bluetooth. It looks like
> > the thinkpad acpi is trying acquire locks while suspending.  Disabling
> > cmos, light, led and hotkeys makes suspend-to-disk works again.
> 
> Well, we should tell the thinkpad_acpi maintainer about that, then (CCed).

What are the requirements re. mutexes for sleep-to-disk versus sleep-to-ram?

Did something change in that area that caused the driver to hang?  A pointer
to the ML threads, documentation, or patchset/git commit with those changes
would be enough answer, and I will pursue it from there.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH 0/11] ACPI: Fixes and cleanups related to iomaps management

[Rafael J. Wysocki]

On Sunday, January 23, 2011, Henrique de Moraes Holschuh wrote:
> On Sat, 22 Jan 2011, Rafael J. Wysocki wrote:
> > > I discovered CONFIG_THINKPAD_ACPI caused suspend-to-disk to hang. I
> > > need the Thinkpad ACPI to control the fan and bluetooth. It looks like
> > > the thinkpad acpi is trying acquire locks while suspending.  Disabling
> > > cmos, light, led and hotkeys makes suspend-to-disk works again.
> > 
> > Well, we should tell the thinkpad_acpi maintainer about that, then (CCed).
> 
> What are the requirements re. mutexes for sleep-to-disk versus sleep-to-ram?

No difference.  Basically, there are two differences between suspend and
hibernation, as far as drivers are concerned:
(1) It's better to use the ->freeze()/->thaw() and ->poweroff()/->restore()
    callbacks for hibernation.
(2) It may be _much_ more difficult to get free memory during hibernation
    (so theoretically attempts to get memory during hibernation are more likely
    to block).

> Did something change in that area that caused the driver to hang?  A pointer
> to the ML threads, documentation, or patchset/git commit with those changes
> would be enough answer, and I will pursue it from there.

I'm not aware of any such changes.

Besides, the problem reported by Jeff seems to be caused by CPU hotplug.

Thanks,
Rafael

Re: [PATCH 0/11] ACPI: Fixes and cleanups related to iomaps management

[Henrique de Moraes Holschuh]

On Sun, 23 Jan 2011, Rafael J. Wysocki wrote:
> On Sunday, January 23, 2011, Henrique de Moraes Holschuh wrote:
> > On Sat, 22 Jan 2011, Rafael J. Wysocki wrote:
> > > > I discovered CONFIG_THINKPAD_ACPI caused suspend-to-disk to hang. I
> > > > need the Thinkpad ACPI to control the fan and bluetooth. It looks like
> > > > the thinkpad acpi is trying acquire locks while suspending.  Disabling
> > > > cmos, light, led and hotkeys makes suspend-to-disk works again.
> > > 
> > > Well, we should tell the thinkpad_acpi maintainer about that, then (CCed).
> > 
> > What are the requirements re. mutexes for sleep-to-disk versus sleep-to-ram?
> 
> No difference.  Basically, there are two differences between suspend and
> hibernation, as far as drivers are concerned:
> (1) It's better to use the ->freeze()/->thaw() and ->poweroff()/->restore()
>     callbacks for hibernation.
> (2) It may be _much_ more difficult to get free memory during hibernation
>     (so theoretically attempts to get memory during hibernation are more likely
>     to block).

So, if there is nothing wrong with mutex use by itself...

Thinkpad-acpi calls the thinkpad firmware (using normal ACPI method calls),
which does SMI traps into the SMBIOS to do whatever it wants done.  And that
includes writing to the NVS (both the peecee RTC CMOS, and ACPI-backed
"NVS").

> Besides, the problem reported by Jeff seems to be caused by CPU hotplug.

Something weird going on with CPU hotplug could throw Lenovo's
way-too-complex-for-comfort SMM firmware out of wack alright.

That can be checked.  Lobotomize the driver so that it does not do the acpi
calls in the suspend path (but keep everything else).  If it still locks, it
is not the firmware.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH 0/11] ACPI: Fixes and cleanups related to iomaps management

[Rafael J. Wysocki]

On Monday, January 24, 2011, Henrique de Moraes Holschuh wrote:
> On Sun, 23 Jan 2011, Rafael J. Wysocki wrote:
> > On Sunday, January 23, 2011, Henrique de Moraes Holschuh wrote:
> > > On Sat, 22 Jan 2011, Rafael J. Wysocki wrote:
> > > > > I discovered CONFIG_THINKPAD_ACPI caused suspend-to-disk to hang. I
> > > > > need the Thinkpad ACPI to control the fan and bluetooth. It looks like
> > > > > the thinkpad acpi is trying acquire locks while suspending.  Disabling
> > > > > cmos, light, led and hotkeys makes suspend-to-disk works again.
> > > > 
> > > > Well, we should tell the thinkpad_acpi maintainer about that, then (CCed).
> > > 
> > > What are the requirements re. mutexes for sleep-to-disk versus sleep-to-ram?
> > 
> > No difference.  Basically, there are two differences between suspend and
> > hibernation, as far as drivers are concerned:
> > (1) It's better to use the ->freeze()/->thaw() and ->poweroff()/->restore()
> >     callbacks for hibernation.
> > (2) It may be _much_ more difficult to get free memory during hibernation
> >     (so theoretically attempts to get memory during hibernation are more likely
> >     to block).
> 
> So, if there is nothing wrong with mutex use by itself...
> 
> Thinkpad-acpi calls the thinkpad firmware (using normal ACPI method calls),
> which does SMI traps into the SMBIOS to do whatever it wants done.  And that
> includes writing to the NVS (both the peecee RTC CMOS, and ACPI-backed
> "NVS").
> 
> > Besides, the problem reported by Jeff seems to be caused by CPU hotplug.
> 
> Something weird going on with CPU hotplug could throw Lenovo's
> way-too-complex-for-comfort SMM firmware out of wack alright.
> 
> That can be checked.  Lobotomize the driver so that it does not do the acpi
> calls in the suspend path (but keep everything else).  If it still locks, it
> is not the firmware.

It turns out there's a bug in intel_idle causing people a lot of pain with CPU
hotplugging.  Should be fixed now it the Linus' tree.

Thanks,
Rafael

Re: [PATCH 0/11] ACPI: Fixes and cleanups related to iomaps management

[Jeff Chua]

On Tue, Jan 25, 2011 at 5:37 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday, January 24, 2011, Henrique de Moraes Holschuh wrote:
> It turns out there's a bug in intel_idle causing people a lot of pain 
> with CPU hotplugging.  Should be fixed now it the Linus' tree.

Uh, I see the git fix now. Thanks. The workaround I did was to manually 
offline all CPUs before suspend and that fixed it too.

As for the thinkpad-acpi, here a little patch to disable all hotkeys so 
that Fn-F4 works natively to suspend-to-memory when 
CONFIG_THINKPAD_ACPI_HOTKEY_POLL is not set.

Thanks,
Jeff

--- lx/drivers/platform/x86/thinkpad_acpi.c.org	2011-01-22 21:48:05.000000000 +0800
+++ lx/drivers/platform/x86/thinkpad_acpi.c	2011-01-22 21:55:14.000000000 +0800
@@ -8776,10 +8776,12 @@
  	{
  		.data = &thinkpad_acpi_driver_data,
  	},
+#ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
  	{
  		.init = hotkey_init,
  		.data = &hotkey_driver_data,
  	},
+#endif
  	{
  		.init = bluetooth_init,