Bug 86031

Summary: [BISECTED] lpc_sch.c: hard reset required to get out of suspend since 3.13, unless acpi_enforce_resources=strict - Intel Atom Z520, Acer AO 751h
Product: Drivers Reporter: Gonzalo (gonmator)
Component: OtherAssignee: Johannes Thumshirn (jth)
Status: ASSIGNED ---    
Severity: normal CC: aaron.lu, alan, edward.sternin, jth, lee.jones, lenb, rui.zhang
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: v3.13 to v3.17 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Kernel version (from /proc/version)
Processor information (from /proc/cpuinfo)
Module information (from /proc/modules)
Loaded driver and hardware information (/proc/ioports, /proc/iomem)
PCI information ('lspci -vvv')
SCSI information (from /proc/scsi/scsi)
Environment (lsb_release)
/proc/version, /proc/modules, lspci -vvv from another AO751h/14.04.1

Description Gonzalo 2014-10-11 09:02:13 UTC
The laptop (Acer AspireOne 751h) is not able to resume from suspend anymore.

Suspending the laptop, for instance, executing "sudo pm-suspend", or closing the lid, the laptop get suspended, the screen will off, and the power button led blinks as expected. But then it is not possible to awake again neither pressing a key or pressing the power button. 

If in that state I try to power it off keeping pressed the power button, that still does not work: the blink led still blinks and nothing happens. The only way to recover the system is removing the battery (if power is unpluged) and turning on again.

First kernel version where the problem is reproducible: v3.13-rc1. (v3.12 works fine).
Doing bisect, I found the problem is reproducible since the commit 6bfd1e63de34a278d67db32e3644340838308252:
    mfd: lpc_sch: Ignore resource conflicts when adding mfd cells
    
    Currently probe of lpc_sch fails on Intel Poulsbo because of ACPI resource
    conflicts. A solution is to  set the ignore_resource_conflicts flag in the mfd cells.

I'm not sure what is the real affected component, so I've marked "drivers/others".

Reported also to Canonical: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1358921

Thanks!
Comment 1 Gonzalo 2014-10-11 09:34:34 UTC
Created attachment 153171 [details]
Kernel version (from /proc/version)
Comment 2 Gonzalo 2014-10-11 09:35:35 UTC
Created attachment 153181 [details]
Processor information (from /proc/cpuinfo)
Comment 3 Gonzalo 2014-10-11 09:35:59 UTC
Created attachment 153191 [details]
Module information (from /proc/modules)
Comment 4 Gonzalo 2014-10-11 09:36:24 UTC
Created attachment 153201 [details]
Loaded driver and hardware information (/proc/ioports, /proc/iomem)
Comment 5 Gonzalo 2014-10-11 09:36:55 UTC
Created attachment 153211 [details]
PCI information ('lspci -vvv')
Comment 6 Gonzalo 2014-10-11 09:37:21 UTC
Created attachment 153221 [details]
SCSI information (from /proc/scsi/scsi)
Comment 7 Gonzalo 2014-10-11 09:38:29 UTC
Created attachment 153231 [details]
Environment (lsb_release)
Comment 8 edward sternin 2014-10-15 01:40:40 UTC
I can confirm the bug, on a very similar 14.04 lubuntu release, on AO751h, but Gonzalo has done a fantastic job tracking this down already. Just in case, I include here the data from my system that DIFFERS from Gonzalo's.
Comment 9 edward sternin 2014-10-15 01:43:33 UTC
Created attachment 153791 [details]
/proc/version, /proc/modules, lspci -vvv from another AO751h/14.04.1
Comment 10 Gonzalo 2014-10-17 16:26:52 UTC
My last findings (thanks to J. Thumshirn for his assistance): it looks the problem is related to the new line in lpc_sch.c used to intialize the variable sch_gpio_cell (struct mfd_cell) with the field ignore_resource_conflicts = true: 

The change in the identified commit included set the field ignore_resource_conflicts = true for variables isch_smbus_cell and wdt_sch_cell too. But only setting that field in sch_gpio_cell is when the issue is reproduced.

The ignore_resource_conflicts line just tells the mfd framework to *not* check
for any acpi resource conflicts and add the drivers anyway. So it looks the real problem is in gpio sub-drivers of mfd. 

Other way to reproduce the problem with a not affected kernel versions: booting with "acpi_enforce_resources=lax" kernel parameter.
Comment 11 Alan 2014-10-23 14:27:57 UTC
+Johannes Thumshirn
Comment 12 Len Brown 2014-10-28 04:40:48 UTC
Marked as regression on Intel HW.
Comment 13 Gonzalo 2014-10-28 09:48:02 UTC
I think the new summary is confusing (sorry, because probably it also was confusing in my last comment): there are two ways to reproduce the problem:

1. boot with affected kernel (v3.13 or later)
2. boot with not affected kernel (v3.12 or sooner) BUT with "acpi_enforce_resources=lax" kernel parameter.

I wanted to note a way to reproduce the problem with the non-affected kernel version, but not a workaround.

I've changed the summary to reflect it.
Comment 14 Len Brown 2014-11-03 21:23:14 UTC
Okay, I re-worded the summary to:
[BISECTED] lpc_sch.c: hard reset required to get out of suspend since 3.13, unless acpi_enforce_resources=strict - Intel Atom Z520, Acer AO 751h

Hopefully that gets to the point.

From the description in comment #10, it appears the offending commit is this one:

Author: Johannes Thumshirn <johannes.thumshirn@men.de>  2013-10-23 07:31:00
Committer: Lee Jones <lee.jones@linaro.org>  2013-10-23 11:22:40
Follows: v3.12-rc5
Precedes: v3.13-rc1

    mfd: lpc_sch: Ignore resource conflicts when adding mfd cells
    
    Currently probe of lpc_sch fails on Intel Poulsbo because of ACPI resource
    conflicts. A solution is to  set the ignore_resource_conflicts flag in the mfd cells.
    
    Tested-by: Andreas Werner <andreas.werner@men.de>
    Signed-off-by: Johannes Thumshirn <johannes.thumshirn@men.de>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>

Unfortunately, this code has since been cleaned-up, and so a trivial
revert no longer applies upstream.

I do not see a fix for this regression in Linux-3.18-rc1
I do not see a fix for this regression in linux-next

cc: Andriy
Comment 15 Zhang Rui 2014-11-17 07:40:58 UTC
	
Johannes, any update on this one?
Comment 16 Johannes Thumshirn 2014-11-17 07:56:41 UTC
Oh sorry, haven't realized it's asigned to me.

I think it's like Gonzalo already said, it could be the gpio-sch driver.
Probably it doesn't restore the GPIO registers when comming out of resume.

I'll contact the author of gpio-sch to the list, maybe he can elaborate a bit more on this.