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

Henrique de Moraes Holschuh
2011-01-23T23:15:19Z

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