LinuxLists.cc - [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi,

On 03-04-19 07:43, Kai-Heng Feng wrote:
> i2c-designware-platdrv fails to work after the system restored from
> hibernation:
> [ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type: 0xffffffff
>
> Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
> resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
> on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
> doesn't gets called by acpi_lpss_resume_early(), and this causes the
> issue.
>
> Introduce acpi_lpss_{poweroff_late,restore_early}() to make sure
> driver's own poweroff_late and restore_early get called.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202139
> Fixes: 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq")
> Signed-off-by: Kai-Heng Feng <[email protected]>

The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
so I think it would be better to do this instead to fix this problem:

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 1e2a10a06b9d..cf768608437e 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -1142,8 +1142,8 @@ static struct dev_pm_domain acpi_lpss_pm_domain = {
.thaw_noirq = acpi_subsys_thaw_noirq,
.poweroff = acpi_subsys_suspend,
.poweroff_late = acpi_lpss_suspend_late,
- .poweroff_noirq = acpi_subsys_suspend_noirq,
- .restore_noirq = acpi_subsys_resume_noirq,
+ .poweroff_noirq = acpi_lpss_suspend_noirq,
+ .restore_noirq = acpi_lpss_resume_noirq,
.restore_early = acpi_lpss_resume_early,
#endif
.runtime_suspend = acpi_lpss_runtime_suspend,

Then the i2c controllers on platforms with the resume_from_noirq
flag set for them will be ready for use while the PCI subsystem
runs the _PS0 / _PS3 methods of PCI devices which may use the
i2c controllers (which is what commit 48402cee6889 set out to fix
in the first place).

If people affected by the problem can give my version of the fix a test,
then that would be great.

Regards,

Hans

> ---
> drivers/acpi/acpi_lpss.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 1e2a10a06b9d..49aef186d73d 100644
> --- a/drivers/acpi/acpi_lpss.c
> +++ b/drivers/acpi/acpi_lpss.c
> @@ -1058,6 +1058,11 @@ static int acpi_lpss_suspend_late(struct device *dev)
> return acpi_lpss_do_suspend_late(dev);
> }
>
> +static int acpi_lpss_poweroff_late(struct device *dev)
> +{
> + return acpi_lpss_do_suspend_late(dev);
> +}
> +
> static int acpi_lpss_suspend_noirq(struct device *dev)
> {
> struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> @@ -1089,6 +1094,11 @@ static int acpi_lpss_resume_early(struct device *dev)
> return acpi_lpss_do_resume_early(dev);
> }
>
> +static int acpi_lpss_restore_early(struct device *dev)
> +{
> + return acpi_lpss_do_resume_early(dev);
> +}
> +
> static int acpi_lpss_resume_noirq(struct device *dev)
> {
> struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> @@ -1141,10 +1151,10 @@ static struct dev_pm_domain acpi_lpss_pm_domain = {
> .freeze_noirq = acpi_subsys_freeze_noirq,
> .thaw_noirq = acpi_subsys_thaw_noirq,
> .poweroff = acpi_subsys_suspend,
> - .poweroff_late = acpi_lpss_suspend_late,
> + .poweroff_late = acpi_lpss_poweroff_late,
> .poweroff_noirq = acpi_subsys_suspend_noirq,
> .restore_noirq = acpi_subsys_resume_noirq,
> - .restore_early = acpi_lpss_resume_early,
> + .restore_early = acpi_lpss_restore_early,
> #endif
> .runtime_suspend = acpi_lpss_runtime_suspend,
> .runtime_resume = acpi_lpss_runtime_resume,
>

2019-04-07 20:59:41

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On 4/3/19 2:54 AM, Hans de Goede wrote:

>
> Hi,
>
> On 03-04-19 07:43, Kai-Heng Feng wrote:
>> i2c-designware-platdrv fails to work after the system restored from
>> hibernation:
>> [ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type: 0xffffffff
>>
>> Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
>> resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
>> on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
>> doesn't gets called by acpi_lpss_resume_early(), and this causes the
>> issue.
>>
...
>
> The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
> so I think it would be better to do this instead to fix this problem:
>
> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> index 1e2a10a06b9d..cf768608437e 100644
...
> If people affected by the problem can give my version of the fix a test,
> then that would be great.
>
> Regards,
>
> Hans

I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel, instead of what I had
been doing previously, which was reverting commit 02e45646d53b. I tested it on an ASUS T100TA
and unfortunately with both kernels after resume from hibernation I still get errors like those
listed below, and sound no longer works. I also tried applying the patch from Kai-Heng Feng
(instead of Hans' patch or my revert) on both kernels and again in both cases I get these same errors.

In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem is fixed. Because
of changes in adjacent code in 5.1-rc3, I haven't yet found a way to merge the new code
and the 02e45646d53b revert without causing worse problems. But that's probably because
I don't really understand the details of that code.

[ 120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[ 120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
.....
[ 132.782634] i2c_designware 80860F41:01: controller timed out
[ 133.806538] i2c_designware 80860F41:01: controller timed out
[ 134.830991] i2c_designware 80860F41:01: controller timed out
[ 135.855183] i2c_designware 80860F41:01: controller timed out

Let me know if I can do any other testing to help.

Bob Howell

2019-04-08 03:45:20

by Kai-Heng Feng

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

at 4:58 AM, Robert R. Howell <[email protected]> wrote:

> On 4/3/19 2:54 AM, Hans de Goede wrote:
>
>> Hi,
>>
>> On 03-04-19 07:43, Kai-Heng Feng wrote:
>>> i2c-designware-platdrv fails to work after the system restored from
>>> hibernation:
>>> [ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component
>>> type: 0xffffffff
>>>
>>> Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
>>> resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
>>> on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
>>> doesn't gets called by acpi_lpss_resume_early(), and this causes the
>>> issue.
> ...
>> The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
>> so I think it would be better to do this instead to fix this problem:
>>
>> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
>> index 1e2a10a06b9d..cf768608437e 100644
> ...
>> If people affected by the problem can give my version of the fix a test,
>> then that would be great.
>>
>> Regards,
>>
>> Hans
>
> I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel,
> instead of what I had
> been doing previously, which was reverting commit 02e45646d53b. I tested
> it on an ASUS T100TA
> and unfortunately with both kernels after resume from hibernation I still
> get errors like those
> listed below, and sound no longer works. I also tried applying the patch
> from Kai-Heng Feng
> (instead of Hans' patch or my revert) on both kernels and again in both
> cases I get these same errors.

Hmm, Hans’ works for me, as acpi_lpss_resume_noirq() calls
acpi_lpss_do_resume_early() for S4.

>
> In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem
> is fixed. Because
> of changes in adjacent code in 5.1-rc3, I haven't yet found a way to
> merge the new code
> and the 02e45646d53b revert without causing worse problems. But that's
> probably because
> I don't really understand the details of that code.
>
> [ 120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
> [ 120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
> .....
> [ 132.782634] i2c_designware 80860F41:01: controller timed out
> [ 133.806538] i2c_designware 80860F41:01: controller timed out
> [ 134.830991] i2c_designware 80860F41:01: controller timed out
> [ 135.855183] i2c_designware 80860F41:01: controller timed out
>
> Let me know if I can do any other testing to help.

Is it possible to attach full dmesg? Thanks.

Kai-Heng

>
> Bob Howell

2019-04-08 08:17:19

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi,

On 07-04-19 22:58, Robert R. Howell wrote:
> On 4/3/19 2:54 AM, Hans de Goede wrote:
>
>>
>> Hi,
>>
>> On 03-04-19 07:43, Kai-Heng Feng wrote:
>>> i2c-designware-platdrv fails to work after the system restored from
>>> hibernation:
>>> [ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component type: 0xffffffff
>>>
>>> Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
>>> resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
>>> on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
>>> doesn't gets called by acpi_lpss_resume_early(), and this causes the
>>> issue.
>>>
> ...
>>
>> The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
>> so I think it would be better to do this instead to fix this problem:
>>
>> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
>> index 1e2a10a06b9d..cf768608437e 100644
> ...
>> If people affected by the problem can give my version of the fix a test,
>> then that would be great.
>>
>> Regards,
>>
>> Hans
>
> I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel, instead of what I had
> been doing previously, which was reverting commit 02e45646d53b. I tested it on an ASUS T100TA
> and unfortunately with both kernels after resume from hibernation I still get errors like those
> listed below, and sound no longer works. I also tried applying the patch from Kai-Heng Feng
> (instead of Hans' patch or my revert) on both kernels and again in both cases I get these same errors.
>
> In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem is fixed. Because
> of changes in adjacent code in 5.1-rc3, I haven't yet found a way to merge the new code
> and the 02e45646d53b revert without causing worse problems. But that's probably because
> I don't really understand the details of that code.
>
> [ 120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
> [ 120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
> [ 121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
> .....
> [ 132.782634] i2c_designware 80860F41:01: controller timed out
> [ 133.806538] i2c_designware 80860F41:01: controller timed out
> [ 134.830991] i2c_designware 80860F41:01: controller timed out
> [ 135.855183] i2c_designware 80860F41:01: controller timed out
>
> Let me know if I can do any other testing to help.

Hmm, interesting so you have hibernation working on a T100TA
(with 5.0 + 02e45646d53b reverted), right ?

I must admit I never try hibernation myself, in experience it tends to
have more issues then regular suspend/resume and there are already enough
other issues to worry about on Bay and Cherry Trail based devices.

But if it works on the T100TA and 02e45646d53b broke it then I will
try to fix this, I've a T100TA myself. Currently my T100TA is at my
local hackerspace, so I will not have access to it until coming Friday.

Regards,

Hans

2019-04-11 19:51:10

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On 4/8/19 2:16 AM, Hans de Goede wrote:>
>
> Hmm, interesting so you have hibernation working on a T100TA
> (with 5.0 + 02e45646d53b reverted), right ?
>
Hi Hans and Kai-Heng

First, apologies for how long it took me to reply to both your inquiries.
In trying to answer them I discovered some inconsistencies in how the T100TA was
behaving on different hibernation attempts and I've been trying to sort those out.
I haven't been completely successful in that, but here's a brief summary.

Yes I do have hibernation working (at least most of the time) on a T100TA,
with 5.0 + 02e45646d53b reverted (more about that below), and with a systemd
hibernate script also described below.

Trying to be more quantitative about "most of the time" is in part want I've been
testing the last few days. I just finished a cycle of 20 hibernates/resumes
which were all successful at least in the sense that after resume internal
sound was working, along with all the other critical functions I care about
(WiFi, Bluetooth, etc.). However I have occasionally (perhaps 1 in 10 times)
seen something go wrong with sound on resume and the only way to get it
working again was to a full reboot. During the successful cycles I also
sometimes see i2c_designware or intel_sst_acpi error messages but they
don't seem to indicate an unrecoverable failure. I was hoping to sort out
what errors I was seen on the occasions where sound was lost till a reboot,
but those are rare enough I haven't been able to sort out the difference
between those and the "recoverable" errors.

Regarding the revert of 02e45646d53b, there were some code changes in
adjacent lines so a simple revert wouldn't apply cleanly to 5.0.0
but the changes were small enough that I was able to manually "merge"
the revert and the 5.0.0 changes. I have posted a patch file under
Bugzilla: <https://bugzilla.kernel.org/show_bug.cgi?id=202139>
showing what I actually did to revert 02e45646d53b for 5.0.0. As I mentioned
in an earlier message, I have NOT been able to produce a working revert of
02e45646d53b for the 5.1-rc3 kernel.

To make hibernation work on the T100 I also had to create a script
/usr/lib/systemd/system-sleep/t100_hibernate.sh which unloads various drivers
(including sound) before hibernate, then restarts them afterwords. I've inserted
it below. I'm not certain all the steps in it are still necessary, but the
intermittent failures make it very difficult to determine what is absolutely essential.

-----t100_hibernate.sh systemd script-------
#!/bin/bash
echo "Hibernate script $1 $2"
[ $2 != 'hibernate' ] && exit 0

case $1 in
pre)
echo "Going to $2..."
/sbin/modprobe -r brcmfmac
/sbin/modprobe -r hci_uart
/sbin/modprobe -r battery
/sbin/modprobe -r hid_multitouch
/usr/bin/killall pulseaudio
/sbin/modprobe -r snd_soc_sst_bytcr_rt5640
/sbin/modprobe -r snd_soc_rt5640
/sbin/modprobe -r snd_soc_sst_acpi
;;
post)
echo "Waking from $2..."
/sbin/modprobe brcmfmac
/sbin/modprobe hci_uart
/sbin/modprobe battery
/sbin/modprobe hid_multitouch
# Just load the following and it will pull in other snd modules
/sbin/modprobe snd_soc_sst_acpi
/usr/sbin/service NetworkManager restart
/usr/sbin/service wpa_supplicant restart
# The above is usually enough but occasionally sound doesn't come up properly
# and doing the following seems to restore it in those cases.
/usr/bin/killall pulseaudio
/usr/sbin/rmmod snd_soc_sst_bytcr_rt5640
/usr/sbin/rmmod snd_soc_rt5640
/usr/sbin modprobe snd_soc_rt5640
/usr/sbin modprobe snd_soc_sst_bytcr_rt5640
;;
esac
-----end of script-------------------------------

I'll send a second message with the system logs which Kai-Heng requested,
with his patch applied to 5.1-rc3.

Bob Howell

> I must admit I never try hibernation myself, in experience it tends to
> have more issues then regular suspend/resume and there are already enough
> other issues to worry about on Bay and Cherry Trail based devices.
>
> But if it works on the T100TA and 02e45646d53b broke it then I will
> try to fix this, I've a T100TA myself. Currently my T100TA is at my
> local hackerspace, so I will not have access to it until coming Friday.
>
> Regards,
>
> Hans
>

2019-04-11 19:52:26

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On 4/7/19 9:44 PM, Kai Heng Feng wrote:
> at 4:58 AM, Robert R. Howell <[email protected]> wrote:
>
>>> On 03-04-19 07:43, Kai-Heng Feng wrote:
>>>> i2c-designware-platdrv fails to work after the system restored from
>>>> hibernation:
>> I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel,
>> instead of what I had
>> been doing previously, which was reverting commit 02e45646d53b. I tested
>> it on an ASUS T100TA
>> and unfortunately with both kernels after resume from hibernation I still
>> get errors like those
>> listed below, and sound no longer works. I also tried applying the patch
>> from Kai-Heng Feng
>> (instead of Hans' patch or my revert) on both kernels and again in both
>> cases I get these same errors.
>
>
> Is it possible to attach full dmesg? Thanks.
>
> Kai-Heng

As I mentioned in my reply, to Hans' message, apologies again for how
long it took me to reply to both your inquiries. Besides the
inconsistency in testing the usually successful hibernation
under 5.0.0 (with my fixes), I had some strange inconsistencies in
generating dmesg output with your patch, which I've been trying to understand.

The following was generated using the 5.1-rc3 kernel with your patch applied.

What I have attached are two versions of dmesg -- one before I hibernate
the machine, and one after I resume. The reason for attaching two
is that on resume the system log is spammed with a message which
repeats every few microseconds and causes everything before it started
to scroll out of the message buffers. Therefore I don't have a record
of the hibernation itself, and I don't have a record of what transpires on
resume before the one error starts spamming the log.

I originally thought I had recorded a version which avoided the spamming
but repeated attempts to recreate that have failed and I've slowly concluded
in that one test I must somehow have had booted a different test kernel
rather than the one with your patch. But even that is a little uncertain.

Besides the versions I've attached I've also tried using the "initcall_debug"
option but that log is MUCH longer and because of the spamming issue I don't
think it provides any more information.

Let me know if I can do any further tests.

Bob Howell

------Start of dmesg log before hibernation ------------------------
[ 0.000000] Linux version 5.1.0-rc3-rrh-t100-3 ([email protected]) (gcc version 7.4.0 (SUSE Linux)) #1 SMP PREEMPT Thu Apr 4 23:05:15 MDT 2019
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.1.0-rc3-rrh-t100-3 root=UUID=6bbccbe6-887d-402e-8f62-0b068702b0f3 resume=/dev/disk/by-id/mmc-SEM64G_0xd0225f8a-part5 reboot=pci,force clocksource=tsc modprobe.blacklist=mt9m114 systemd.gpt_auto=0 splash=silent quiet showopts no_console_suspend
[ 0.000000] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000008efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000008f000-0x000000000008ffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000000090000-0x000000000009dfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000200fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000020100000-0x0000000078cf4fff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000078cf5000-0x0000000078d24fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000078d25000-0x0000000078d53fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000078d54000-0x000000007933efff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000007933f000-0x0000000079b5cfff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079b5d000-0x0000000079badfff] type 20
[ 0.000000] BIOS-e820: [mem 0x0000000079bae000-0x0000000079bc8fff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000079bc9000-0x0000000079bc9fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079bca000-0x0000000079bcafff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000079bcb000-0x0000000079bcbfff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079bcc000-0x0000000079d40fff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000079d41000-0x0000000079ff8fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000079ff9000-0x0000000079ffffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000e00f8000-0x00000000e00f8fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffc00000-0x00000000ffffffff] reserved
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ACPI=0x78d53000 ACPI 2.0=0x78d53014 ESRT=0x78d24000 SMBIOS=0x79bcb390
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] DMI: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.307 05/09/2014
[ 0.000000] tsc: Detected 1333.000 MHz processor
[ 0.000030] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000036] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000056] last_pfn = 0x7a000 max_arch_pfn = 0x400000000
[ 0.000064] MTRR default type: uncachable
[ 0.000067] MTRR fixed ranges enabled:
[ 0.000070] 00000-9FFFF write-back
[ 0.000074] A0000-FFFFF write-protect
[ 0.000077] MTRR variable ranges enabled:
[ 0.000081] 0 base 000000000 mask FC0000000 write-back
[ 0.000085] 1 base 040000000 mask FE0000000 write-back
[ 0.000088] 2 base 060000000 mask FF0000000 write-back
[ 0.000092] 3 base 070000000 mask FF8000000 write-back
[ 0.000096] 4 base 070000000 mask FF8000000 write-back
[ 0.000099] 5 base 078000000 mask FFC000000 write-back
[ 0.000103] 6 base 07B000000 mask FFF000000 uncachable
[ 0.000107] 7 base 07AE00000 mask FFFE00000 uncachable
[ 0.000453] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
[ 0.009002] esrt: ESRT header is not in the memory map.
[ 0.009033] check: Scanning 1 areas for low memory corruption
[ 0.009051] BRK [0x03601000, 0x03601fff] PGTABLE
[ 0.009058] BRK [0x03602000, 0x03602fff] PGTABLE
[ 0.009061] BRK [0x03603000, 0x03603fff] PGTABLE
[ 0.009337] BRK [0x03604000, 0x03604fff] PGTABLE
[ 0.010501] BRK [0x03605000, 0x03605fff] PGTABLE
[ 0.011145] BRK [0x03606000, 0x03606fff] PGTABLE
[ 0.012424] Secure boot could not be determined
[ 0.012427] RAMDISK: [mem 0x36ae7000-0x3756afff]
[ 0.012439] ACPI: Early table checksum verification disabled
[ 0.012447] ACPI: RSDP 0x0000000078D53014 000024 (v02 _ASUS_)
[ 0.012457] ACPI: XSDT 0x0000000078D520E8 0000CC (v01 _ASUS_ A M I 00000003 MSFT 0100000D)
[ 0.012472] ACPI: FACP 0x0000000078D4F000 00010C (v05 _ASUS_ A M I 00000003 AMI 0100000D)
[ 0.012487] ACPI: DSDT 0x0000000078D36000 00FDEF (v02 _ASUS_ Notebook 00000003 AMI 0100000D)
[ 0.012497] ACPI: TCPA 0x0000000078D51000 000032 (v02 00000000 00000000)
[ 0.012507] ACPI: UEFI 0x00000000792D8000 000042 (v01 00000000 00000000)
[ 0.012516] ACPI: DBG2 0x0000000078D50000 000072 (v00 _ASUS_ INTLDBG2 00000003 AMI 0100000D)
[ 0.012526] ACPI: HPET 0x0000000078D4E000 000038 (v01 _ASUS_ A M I 00000003 AMI 0100000D)
[ 0.012535] ACPI: LPIT 0x0000000078D4D000 000104 (v01 _ASUS_ 00000003 AMI 0100000D)
[ 0.012545] ACPI: APIC 0x0000000078D4C000 00006C (v03 _ASUS_ 00000003 AMI 0100000D)
[ 0.012555] ACPI: MCFG 0x0000000078D4B000 00003C (v01 _ASUS_ 00000003 AMI 0100000D)
[ 0.012564] ACPI: SSDT 0x0000000078D4A000 0005FB (v01 _ASUS_ CpuDptf 00000003 AMI 0100000D)
[ 0.012574] ACPI: SSDT 0x0000000078D48000 001A07 (v01 _ASUS_ DptfTab 00000003 AMI 0100000D)
[ 0.012583] ACPI: SSDT 0x0000000078D47000 000058 (v01 _ASUS_ LowPwrM 00000003 AMI 0100000D)
[ 0.012593] ACPI: SSDT 0x0000000078D46000 0000FF (v01 _ASUS_ SoCDptf 00000003 AMI 0100000D)
[ 0.012603] ACPI: FPDT 0x0000000078D35000 000044 (v01 A M I ALASKA 01072009 AMI 00010013)
[ 0.012612] ACPI: SSDT 0x0000000078D34000 000763 (v01 PmRef CpuPm 00003000 INTL 20061109)
[ 0.012622] ACPI: SSDT 0x0000000078D33000 000290 (v01 PmRef Cpu0Tst 00003000 INTL 20061109)
[ 0.012632] ACPI: SSDT 0x0000000078D32000 00017A (v01 PmRef ApTst 00003000 INTL 20061109)
[ 0.012642] ACPI: SSDT 0x0000000078D31000 000427 (v01 Intel_ Tpm2Tabl 00001000 INTL 20061109)
[ 0.012651] ACPI: TPM2 0x0000000078D30000 000034 (v03 00000000 00000000)
[ 0.012661] ACPI: BGRT 0x0000000078D2F000 000038 (v00 _ASUS_ Notebook 01072009 AMI 00010013)
[ 0.012671] ACPI: CSRT 0x0000000078D2E000 00014C (v00 ALASKA A M I 00000005 MSFT 0100000D)
[ 0.012680] ACPI: MSDM 0x0000000078D23F90 000055 (v03 _ASUS_ Notebook 00000000 ASUS 00000001)
[ 0.012705] ACPI: Local APIC address 0xfee00000
[ 0.012760] Zone ranges:
[ 0.012763] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.012767] DMA32 [mem 0x0000000001000000-0x0000000079ffffff]
[ 0.012770] Normal empty
[ 0.012773] Movable zone start for each node
[ 0.012774] Early memory node ranges
[ 0.012777] node 0: [mem 0x0000000000001000-0x000000000008efff]
[ 0.012780] node 0: [mem 0x0000000000090000-0x000000000009dfff]
[ 0.012783] node 0: [mem 0x0000000000100000-0x000000001fffffff]
[ 0.012786] node 0: [mem 0x0000000020100000-0x0000000078cf4fff]
[ 0.012789] node 0: [mem 0x0000000079bae000-0x0000000079bc8fff]
[ 0.012791] node 0: [mem 0x0000000079bca000-0x0000000079bcafff]
[ 0.012794] node 0: [mem 0x0000000079bcc000-0x0000000079d40fff]
[ 0.012797] node 0: [mem 0x0000000079ff9000-0x0000000079ffffff]
[ 0.013095] Zeroed struct page in unavailable ranges: 4823 pages
[ 0.013100] Initmem setup node 0 [mem 0x0000000000001000-0x0000000079ffffff]
[ 0.013105] On node 0 totalpages: 494889
[ 0.013108] DMA zone: 64 pages used for memmap
[ 0.013110] DMA zone: 22 pages reserved
[ 0.013113] DMA zone: 3996 pages, LIFO batch:0
[ 0.013392] DMA32 zone: 7744 pages used for memmap
[ 0.013395] DMA32 zone: 490893 pages, LIFO batch:63
[ 0.046731] x86/hpet: Will disable the HPET for this platform because it's not reliable
[ 0.046742] Reserving Intel graphics memory at [mem 0x7af00000-0x7eefffff]
[ 0.046811] ACPI: Local APIC address 0xfee00000
[ 0.046839] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-86
[ 0.046846] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.046852] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.046857] Using ACPI (MADT) for SMP configuration information
[ 0.046862] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.046890] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.046964] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.046970] PM: Registered nosave memory: [mem 0x0008f000-0x0008ffff]
[ 0.046976] PM: Registered nosave memory: [mem 0x0009e000-0x0009ffff]
[ 0.046978] PM: Registered nosave memory: [mem 0x000a0000-0x000fffff]
[ 0.046985] PM: Registered nosave memory: [mem 0x20000000-0x200fffff]
[ 0.046991] PM: Registered nosave memory: [mem 0x78cf5000-0x78d24fff]
[ 0.046993] PM: Registered nosave memory: [mem 0x78d25000-0x78d53fff]
[ 0.046996] PM: Registered nosave memory: [mem 0x78d54000-0x7933efff]
[ 0.046998] PM: Registered nosave memory: [mem 0x7933f000-0x79b5cfff]
[ 0.047000] PM: Registered nosave memory: [mem 0x79b5d000-0x79badfff]
[ 0.047007] PM: Registered nosave memory: [mem 0x79bc9000-0x79bc9fff]
[ 0.047013] PM: Registered nosave memory: [mem 0x79bcb000-0x79bcbfff]
[ 0.047019] PM: Registered nosave memory: [mem 0x79d41000-0x79ff8fff]
[ 0.047024] [mem 0x7ef00000-0xe00f7fff] available for PCI devices
[ 0.047027] Booting paravirtualized kernel on bare hardware
[ 0.047035] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[ 0.297675] random: get_random_bytes called from start_kernel+0x8a/0x480 with crng_init=0
[ 0.297705] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[ 0.298555] percpu: Embedded 44 pages/cpu @(____ptrval____) s139736 r8192 d32296 u524288
[ 0.298581] pcpu-alloc: s139736 r8192 d32296 u524288 alloc=1*2097152
[ 0.298584] pcpu-alloc: [0] 0 1 2 3
[ 0.298657] Built 1 zonelists, mobility grouping on. Total pages: 487059
[ 0.298664] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.1.0-rc3-rrh-t100-3 root=UUID=6bbccbe6-887d-402e-8f62-0b068702b0f3 resume=/dev/disk/by-id/mmc-SEM64G_0xd0225f8a-part5 reboot=pci,force clocksource=tsc modprobe.blacklist=mt9m114 systemd.gpt_auto=0 splash=silent quiet showopts no_console_suspend
[ 0.299739] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.300079] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.320312] Memory: 1862744K/1979556K available (10243K kernel code, 1041K rwdata, 3292K rodata, 1096K init, 1724K bss, 116812K reserved, 0K cma-reserved)
[ 0.320639] Kernel/User page tables isolation: enabled
[ 0.320883] rcu: Preemptible hierarchical RCU implementation.
[ 0.320887] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[ 0.320890] Tasks RCU enabled.
[ 0.320893] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
[ 0.320895] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.321279] NR_IRQS: 4352, nr_irqs: 1024, preallocated irqs: 0
[ 0.321693] Console: colour dummy device 80x25
[ 0.321703] printk: console [tty0] enabled
[ 0.321725] ACPI: Core revision 20190215
[ 0.322249] APIC: Switch to symmetric I/O mode setup
[ 0.322304] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1336e3dbd1a, max_idle_ns: 440795236868 ns
[ 0.322335] Calibrating delay loop (skipped), value calculated using timer frequency.. 2666.00 BogoMIPS (lpj=1333000)
[ 0.322341] pid_max: default: 32768 minimum: 301
[ 0.323311] LSM: Security Framework initializing
[ 0.323311] AppArmor: AppArmor initialized
[ 0.323311] TOMOYO Linux initialized
[ 0.323311] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.323311] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.323311] *** VALIDATE proc ***
[ 0.323311] *** VALIDATE cgroup1 ***
[ 0.323311] *** VALIDATE cgroup2 ***
[ 0.323311] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.323311] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.323311] mce: CPU supports 6 MCE banks
[ 0.323311] mce: CPU0: Thermal monitoring enabled (TM1)
[ 0.323311] process: using mwait in idle threads
[ 0.323311] Last level iTLB entries: 4KB 48, 2MB 0, 4MB 0
[ 0.323311] Last level dTLB entries: 4KB 128, 2MB 16, 4MB 16, 1GB 0
[ 0.323311] Spectre V2 : Mitigation: Full generic retpoline
[ 0.323311] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[ 0.323311] Freeing SMP alternatives memory: 16K
[ 0.323311] TSC deadline timer enabled
[ 0.323311] smpboot: CPU0: Intel(R) Atom(TM) CPU Z3740 @ 1.33GHz (family: 0x6, model: 0x37, stepping: 0x3)
[ 0.328342] Performance Events: PEBS fmt2+, 8-deep LBR, Silvermont events, 8-deep LBR, full-width counters, Intel PMU driver.
[ 0.328370] ... version: 3
[ 0.328372] ... bit width: 40
[ 0.328374] ... generic registers: 2
[ 0.328377] ... value mask: 000000ffffffffff
[ 0.328379] ... max period: 0000007fffffffff
[ 0.328381] ... fixed-purpose events: 3
[ 0.328383] ... event mask: 0000000700000003
[ 0.330325] rcu: Hierarchical SRCU implementation.
[ 0.334515] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[ 0.336337] smp: Bringing up secondary CPUs ...
[ 0.344411] x86: Booting SMP configuration:
[ 0.344415] .... node #0, CPUs: #1 #2 #3
[ 0.360540] smp: Brought up 1 node, 4 CPUs
[ 0.360540] smpboot: Max logical packages: 1
[ 0.360540] smpboot: Total of 4 processors activated (10664.00 BogoMIPS)
[ 0.361897] devtmpfs: initialized
[ 0.362398] x86/mm: Memory block size: 128MB
[ 0.363562] PM: Registering ACPI NVS region [mem 0x0008f000-0x0008ffff] (4096 bytes)
[ 0.363567] PM: Registering ACPI NVS region [mem 0x78d54000-0x7933efff] (6205440 bytes)
[ 0.363936] PM: Registering ACPI NVS region [mem 0x79d41000-0x79ff8fff] (2850816 bytes)
[ 0.364382] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.364382] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.364506] pinctrl core: initialized pinctrl subsystem
[ 0.365086] NET: Registered protocol family 16
[ 0.365444] audit: initializing netlink subsys (disabled)
[ 0.365485] audit: type=2000 audit(1555008588.043:1): state=initialized audit_enabled=0 res=1
[ 0.365639] cpuidle: using governor ladder
[ 0.365659] cpuidle: using governor menu
[ 0.366355] ACPI: bus type PCI registered
[ 0.366359] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.366541] PCI: Using configuration type 1 for base access
[ 0.372439] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[ 0.373448] ACPI: Added _OSI(Module Device)
[ 0.373451] ACPI: Added _OSI(Processor Device)
[ 0.373454] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.373457] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.373461] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.373464] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 0.373468] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 0.432321] ACPI: 9 ACPI AML tables successfully acquired and loaded
[ 0.446539] ACPI: Dynamic OEM Table Load:
[ 0.446560] ACPI: SSDT 0xFFFF888076028000 000353 (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
[ 0.448334] ACPI: Dynamic OEM Table Load:
[ 0.448352] ACPI: SSDT 0xFFFF88807604E800 000442 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
[ 0.451184] ACPI: Dynamic OEM Table Load:
[ 0.451201] ACPI: SSDT 0xFFFF888076029A00 00015F (v01 PmRef ApIst 00003000 INTL 20061109)
[ 0.452400] ACPI: Dynamic OEM Table Load:
[ 0.452416] ACPI: SSDT 0xFFFF888076026840 00008D (v01 PmRef ApCst 00003000 INTL 20061109)
[ 0.459481] ACPI: Interpreter enabled
[ 0.459539] ACPI: (supports S0)
[ 0.459543] ACPI: Using IOAPIC for interrupt routing
[ 0.459676] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.469220] ACPI: Power Resource [USBC] (on)
[ 0.480999] ACPI: Power Resource [PLPE] (on)
[ 0.498807] ACPI: Power Resource [CLK0] (on)
[ 0.498983] ACPI: Power Resource [CLK1] (on)
[ 0.499469] ACPI: Power Resource [P28X] (off)
[ 0.499644] ACPI: Power Resource [P18X] (off)
[ 0.502052] ACPI: Power Resource [TCPR] (off)
[ 0.507025] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[ 0.516636] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.516655] acpi PNP0A08:00: _OSC: OS supports [ASPM ClockPM Segments MSI]
[ 0.516910] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
[ 0.518773] PCI host bridge to bus 0000:00
[ 0.518781] pci_bus 0000:00: root bus resource [io 0x0070-0x0077]
[ 0.518786] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window]
[ 0.518791] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window]
[ 0.518796] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 0.518801] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 0.518806] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window]
[ 0.518811] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff window]
[ 0.518816] pci_bus 0000:00: root bus resource [mem 0x90c00000-0x90ffffff window]
[ 0.518820] pci_bus 0000:00: root bus resource [mem 0x7af00001-0x7ef00000 window]
[ 0.518829] pci_bus 0000:00: root bus resource [mem 0x80000000-0x908ffffe window]
[ 0.518834] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed40fff window]
[ 0.518839] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.518857] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000
[ 0.519226] pci 0000:00:02.0: [8086:0f31] type 00 class 0x030000
[ 0.519249] pci 0000:00:02.0: reg 0x10: [mem 0x90000000-0x903fffff]
[ 0.519265] pci 0000:00:02.0: reg 0x18: [mem 0x80000000-0x8fffffff pref]
[ 0.519281] pci 0000:00:02.0: reg 0x20: [io 0x1000-0x1007]
[ 0.519311] pci 0000:00:02.0: BAR 2: assigned to efifb
[ 0.519663] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330
[ 0.519693] pci 0000:00:14.0: reg 0x10: [mem 0x90800000-0x9080ffff 64bit]
[ 0.519777] pci 0000:00:14.0: PME# supported from D3hot D3cold
[ 0.520106] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000
[ 0.520137] pci 0000:00:1a.0: reg 0x10: [mem 0x90700000-0x907fffff]
[ 0.520152] pci 0000:00:1a.0: reg 0x14: [mem 0x90600000-0x906fffff]
[ 0.520258] pci 0000:00:1a.0: PME# supported from D0 D3hot
[ 0.520586] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100
[ 0.520973] pci_bus 0000:00: on NUMA node 0
[ 0.522326] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.522706] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.523084] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.523465] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.523842] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.524217] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.524597] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.524980] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.528589] gpio gpiochip1: (INT33FC:01): detected irqchip that is shared with multiple gpiochips: please fix the driver.
[ 0.530359] gpio gpiochip2: (INT33FC:02): detected irqchip that is shared with multiple gpiochips: please fix the driver.
[ 0.571692] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 channels
[ 0.595668] dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 channels
[ 0.596201] pci 0000:00:02.0: vgaarb: setting as boot VGA device
[ 0.596201] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[ 0.596201] pci 0000:00:02.0: vgaarb: bridge control possible
[ 0.596201] vgaarb: loaded
[ 0.596488] SCSI subsystem initialized
[ 0.596617] libata version 3.00 loaded.
[ 0.596617] ACPI: bus type USB registered
[ 0.596617] usbcore: registered new interface driver usbfs
[ 0.596617] usbcore: registered new interface driver hub
[ 0.596617] usbcore: registered new device driver usb
[ 0.706320] random: fast init done
[ 0.877415] pps_core: LinuxPPS API ver. 1 registered
[ 0.877419] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]>
[ 0.877430] PTP clock support registered
[ 0.877459] EDAC MC: Ver: 3.0.0
[ 0.877649] Registered efivars operations
[ 0.882465] PCI: Using ACPI for IRQ routing
[ 0.882465] PCI: pci_cache_line_size set to 64 bytes
[ 0.882465] Expanded resource Reserved due to conflict with PCI Bus 0000:00
[ 0.882465] e820: reserve RAM buffer [mem 0x0008f000-0x0008ffff]
[ 0.882465] e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
[ 0.882465] e820: reserve RAM buffer [mem 0x78cf5000-0x7bffffff]
[ 0.882465] e820: reserve RAM buffer [mem 0x79bc9000-0x7bffffff]
[ 0.882465] e820: reserve RAM buffer [mem 0x79bcb000-0x7bffffff]
[ 0.882465] e820: reserve RAM buffer [mem 0x79d41000-0x7bffffff]
[ 0.882465] e820: reserve RAM buffer [mem 0x7a000000-0x7bffffff]
[ 0.882771] NetLabel: Initializing
[ 0.882774] NetLabel: domain hash size = 128
[ 0.882776] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 0.882827] NetLabel: unlabeled traffic allowed by default
[ 0.883323] clocksource: Switched to clocksource tsc-early
[ 0.907673] VFS: Disk quotas dquot_6.6.0
[ 0.907725] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.907809] *** VALIDATE hugetlbfs ***
[ 0.908136] AppArmor: AppArmor Filesystem Enabled
[ 0.908196] pnp: PnP ACPI init
[ 0.908399] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.909143] system 00:01: [io 0x0680-0x069f] has been reserved
[ 0.909150] system 00:01: [io 0x0400-0x047f] has been reserved
[ 0.909156] system 00:01: [io 0x0500-0x05fe] has been reserved
[ 0.909161] system 00:01: [io 0x0600-0x061f] has been reserved
[ 0.909167] system 00:01: [io 0x164e-0x164f] has been reserved
[ 0.909185] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.911899] system 00:02: [io 0x0240-0x0259] has been reserved
[ 0.911916] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.922868] pnp: PnP ACPI: found 3 devices
[ 0.928945] pci_bus 0000:00: resource 4 [io 0x0070-0x0077]
[ 0.928952] pci_bus 0000:00: resource 5 [io 0x0000-0x006f window]
[ 0.928957] pci_bus 0000:00: resource 6 [io 0x0078-0x0cf7 window]
[ 0.928961] pci_bus 0000:00: resource 7 [io 0x0d00-0xffff window]
[ 0.928966] pci_bus 0000:00: resource 8 [mem 0x000a0000-0x000bffff window]
[ 0.928971] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000dffff window]
[ 0.928975] pci_bus 0000:00: resource 10 [mem 0x000e0000-0x000fffff window]
[ 0.928980] pci_bus 0000:00: resource 11 [mem 0x90c00000-0x90ffffff window]
[ 0.928985] pci_bus 0000:00: resource 12 [mem 0x7af00001-0x7ef00000 window]
[ 0.928990] pci_bus 0000:00: resource 13 [mem 0x80000000-0x908ffffe window]
[ 0.928994] pci_bus 0000:00: resource 14 [mem 0xfed40000-0xfed40fff window]
[ 0.929287] NET: Registered protocol family 2
[ 0.929765] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes)
[ 0.929787] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[ 0.929861] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[ 0.929979] TCP: Hash tables configured (established 16384 bind 16384)
[ 0.930074] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[ 0.930101] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[ 0.930277] NET: Registered protocol family 1
[ 0.930357] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[ 0.930909] PCI: CLS 0 bytes, default 64
[ 0.931057] Unpacking initramfs...
[ 3.852552] Freeing initrd memory: 10768K
[ 3.852967] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1336e3dbd1a, max_idle_ns: 440795236868 ns
[ 3.853005] clocksource: Switched to clocksource tsc
[ 3.853228] check: Scanning for low memory corruption every 60 seconds
[ 3.855015] Initialise system trusted keyrings
[ 3.855144] workingset: timestamp_bits=46 max_order=19 bucket_order=0
[ 3.855289] zbud: loaded
[ 3.948925] Key type asymmetric registered
[ 3.948930] Asymmetric key parser 'x509' registered
[ 3.948932] Key type pkcs7_test registered
[ 3.948973] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[ 3.949117] io scheduler mq-deadline registered
[ 3.949121] io scheduler kyber registered
[ 3.949730] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 3.949951] efifb: probing for efifb
[ 3.949988] efifb: showing boot graphics
[ 3.952766] efifb: framebuffer at 0x80000000, using 4160k, total 4160k
[ 3.952770] efifb: mode is 1368x768x32, linelength=5504, pages=1
[ 3.952772] efifb: scrolling: redraw
[ 3.952776] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 3.952930] fbcon: Deferring console take-over
[ 3.952934] fb0: EFI VGA frame buffer device
[ 3.952963] intel_idle: MWAIT substates: 0x33000020
[ 3.952967] intel_idle: v0.4.1 model 0x37
[ 3.953633] intel_idle: lapic_timer_reliable_states 0xffffffff
[ 3.964136] Serial: 8250/16550 driver, 32 ports, IRQ sharing disabled
[ 3.984681] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 4.026932] hpet: number irqs doesn't agree with number of timers
[ 4.028564] Non-volatile memory driver v1.3
[ 4.029442] Linux agpgart interface v0.103
[ 4.060896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 4.060938] ehci-pci: EHCI PCI platform driver
[ 4.061000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 4.061051] uhci_hcd: USB Universal Host Controller Interface driver
[ 4.061360] i8042: PNP: No PS/2 controller found.
[ 4.063158] mousedev: PS/2 mouse device common for all mice
[ 4.064395] intel_pstate: Intel P-state driver initializing
[ 4.066663] ledtrig-cpu: registered to indicate activity on CPUs
[ 4.066800] EFI Variables Facility v0.08 2004-May-17
[ 4.079887] hidraw: raw HID events driver (C) Jiri Kosina
[ 4.080621] input: Asus Wireless Radio Control as /devices/LNXSYSTM:00/LNXSYBUS:00/ATK4001:00/input/input0
[ 4.086281] intel_telemetry_core Init
[ 4.087539] NET: Registered protocol family 10
[ 4.090616] Segment Routing with IPv6
[ 4.095059] microcode: sig=0x30673, pf=0x2, revision=0x31e
[ 4.096189] microcode: Microcode Update Driver: v2.2.
[ 4.096250] sched_clock: Marking stable (4095173079, 973361)->(4107253782, -11107342)
[ 4.098441] registered taskstats version 1
[ 4.098452] Loading compiled-in X.509 certificates
[ 4.098543] zswap: loaded using pool lzo/zbud
[ 4.099305] AppArmor: AppArmor sha1 policy hashing enabled
[ 4.101176] hctosys: unable to open rtc device (rtc0)
[ 4.105596] Freeing unused kernel image memory: 1096K
[ 4.112698] Write protecting the kernel read-only data: 16384k
[ 4.117461] Freeing unused kernel image memory: 2028K
[ 4.119670] Freeing unused kernel image memory: 804K
[ 4.120426] Run /init as init process
[ 4.183048] systemd[1]: systemd 234 running in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN default-hierarchy=hybrid)
[ 4.196308] systemd[1]: Detected architecture x86-64.
[ 4.196404] systemd[1]: Running in initial RAM disk.
[ 4.196600] systemd[1]: Set hostname to <elsie>.
[ 4.429250] random: systemd: uninitialized urandom read (16 bytes read)
[ 4.429354] systemd[1]: Listening on udev Kernel Socket.
[ 4.429496] random: systemd: uninitialized urandom read (16 bytes read)
[ 4.429602] systemd[1]: Listening on Journal Socket (/dev/log).
[ 4.429637] random: systemd: uninitialized urandom read (16 bytes read)
[ 4.430565] systemd[1]: Created slice System Slice.
[ 4.430715] systemd[1]: Listening on udev Control Socket.
[ 4.430766] systemd[1]: Reached target Timers.
[ 4.431090] systemd[1]: Created slice system-systemd\x2dhibernate\x2dresume.slice.
[ 4.452097] device-mapper: uevent: version 1.0.3
[ 4.454641] device-mapper: ioctl: 4.40.0-ioctl (2019-01-18) initialised: [email protected]
[ 4.466994] fbcon: Taking over console
[ 4.469498] Console: switching to colour frame buffer device 171x48
[ 5.048804] random: crng init done
[ 5.048808] random: 7 urandom warning(s) missed due to ratelimiting
[ 5.253266] sdhci: Secure Digital Host Controller Interface driver
[ 5.253270] sdhci: Copyright(c) Pierre Ossman
[ 5.257710] 80860F0A:00: ttyS4 at MMIO 0x9094d000 (irq = 17, base_baud = 2764800) is a 16550A
[ 5.257899] serial serial0: tty port ttyS4 registered
[ 5.272662] mmc0: SDHCI controller on ACPI [80860F14:01] using ADMA
[ 5.274717] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
[ 5.277214] ACPI Debug: "Method _DSM begin"
[ 5.281262] ACPI Debug: "Method _DSM Function HID"
[ 5.281354] i2c_hid i2c-ATML1000:00: i2c-ATML1000:00 supply vdd not found, using dummy regulator
[ 5.281397] i2c_hid i2c-ATML1000:00: i2c-ATML1000:00 supply vddl not found, using dummy regulator
[ 5.287340] mmc2: SDHCI controller on ACPI [80860F14:00] using ADMA
[ 5.316716] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 5.316735] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[ 5.317828] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x0000000000009810
[ 5.317835] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[ 5.318778] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.01
[ 5.318783] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 5.318786] usb usb1: Product: xHCI Host Controller
[ 5.318789] usb usb1: Manufacturer: Linux 5.1.0-rc3-rrh-t100-3 xhci-hcd
[ 5.318791] usb usb1: SerialNumber: 0000:00:14.0
[ 5.320733] hub 1-0:1.0: USB hub found
[ 5.320760] hub 1-0:1.0: 6 ports detected
[ 5.322295] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 5.322307] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[ 5.322338] xhci_hcd 0000:00:14.0: Host supports USB 3.0 SuperSpeed
[ 5.322464] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.01
[ 5.322468] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 5.322471] usb usb2: Product: xHCI Host Controller
[ 5.322474] usb usb2: Manufacturer: Linux 5.1.0-rc3-rrh-t100-3 xhci-hcd
[ 5.322477] usb usb2: SerialNumber: 0000:00:14.0
[ 5.325530] hub 2-0:1.0: USB hub found
[ 5.325557] hub 2-0:1.0: 1 port detected
[ 5.335296] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 5.336809] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 5.338353] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 5.341424] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 5.380696] mmc2: new HS200 MMC card at address 0001
[ 5.385345] checking generic (80000000 410000) vs hw (80000000 10000000)
[ 5.385350] fb0: switching to inteldrmfb from EFI VGA
[ 5.385395] Console: switching to colour dummy device 80x25
[ 5.386268] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 5.386471] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5.386474] [drm] Driver supports precise vblank timestamp query.
[ 5.387961] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 5.408977] mmc1: new ultra high speed DDR50 SDIO card at address 0001
[ 5.410209] [drm] Initialized i915 1.6.0 20190207 for 0000:00:02.0 on minor 0
[ 5.415478] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 5.418696] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input1
[ 5.418984] [drm] HDaudio controller not detected, using LPE audio instead
[ 5.421082] fbcon: inteldrmfb (fb0) is primary device
[ 5.431977] mmcblk2: mmc2:0001 SEM64G 58.2 GiB
[ 5.432651] mmcblk2boot0: mmc2:0001 SEM64G partition 1 4.00 MiB
[ 5.433300] mmcblk2boot1: mmc2:0001 SEM64G partition 2 4.00 MiB
[ 5.433660] mmcblk2rpmb: mmc2:0001 SEM64G partition 3 4.00 MiB, chardev (244:0)
[ 5.438730] mmcblk2: p1 p2 p3 p4 p5 p6
[ 5.466393] input: ATML1000:00 03EB:8C0D Touchscreen as /devices/platform/80860F41:05/i2c-5/i2c-ATML1000:00/0018:03EB:8C0D.0001/input/input2
[ 5.466950] hid-generic 0018:03EB:8C0D.0001: input,hidraw0: I2C HID v1.00 Device [ATML1000:00 03EB:8C0D] on i2c-ATML1000:00
[ 5.478797] mmc0: new high speed SDXC card at address aaaa
[ 5.481488] mmcblk0: mmc0:aaaa SL64G 59.5 GiB
[ 5.495830] mmcblk0: p1
[ 5.646565] usb 1-3: new full-speed USB device number 2 using xhci_hcd
[ 5.780895] usb 1-3: New USB device found, idVendor=0b05, idProduct=17e0, bcdDevice= 2.35
[ 5.780911] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5.780921] usb 1-3: Product: ASUS Base Station(T100)
[ 5.780929] usb 1-3: Manufacturer: ASUSTek COMPUTER INC.
[ 5.795734] input: ASUSTek COMPUTER INC. ASUS Base Station(T100) as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:0B05:17E0.0002/input/input4
[ 5.849861] hid-generic 0003:0B05:17E0.0002: input,hidraw1: USB HID v1.11 Keyboard [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input0
[ 5.853721] input: ASUSTek COMPUTER INC. ASUS Base Station(T100) Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:0B05:17E0.0003/input/input5
[ 5.907305] input: ASUSTek COMPUTER INC. ASUS Base Station(T100) System Control as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:0B05:17E0.0003/input/input6
[ 5.908068] input: ASUSTek COMPUTER INC. ASUS Base Station(T100) as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:0B05:17E0.0003/input/input7
[ 5.909385] hid-generic 0003:0B05:17E0.0003: input,hiddev96,hidraw2: USB HID v1.11 Device [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input1
[ 5.912956] input: ASUSTek COMPUTER INC. ASUS Base Station(T100) Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.2/0003:0B05:17E0.0004/input/input8
[ 5.914232] hid-generic 0003:0B05:17E0.0004: input,hiddev97,hidraw3: USB HID v1.11 Mouse [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input2
[ 5.914622] usbcore: registered new interface driver usbhid
[ 5.914628] usbhid: USB HID core driver
[ 5.942525] asus_wmi: ASUS WMI generic driver loaded
[ 6.000012] input: ASUSTek COMPUTER INC. ASUS Base Station(T100) as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:0B05:17E0.0002/input/input10
[ 6.052868] asus 0003:0B05:17E0.0002: input,hidraw0: USB HID v1.11 Keyboard [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input0
[ 6.118391] input: ATML1000:00 03EB:8C0D as /devices/platform/80860F41:05/i2c-5/i2c-ATML1000:00/0018:03EB:8C0D.0001/input/input11
[ 6.124537] hid-multitouch 0018:03EB:8C0D.0001: input,hidraw1: I2C HID v1.00 Device [ATML1000:00 03EB:8C0D] on i2c-ATML1000:00
[ 6.125477] asus 0003:0B05:17E0.0003: Fixing up Asus T100 keyb report descriptor
[ 6.126013] input: ASUSTek COMPUTER INC. ASUS Base Station(T100) as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:0B05:17E0.0003/input/input13
[ 6.145885] input: ASUSTek COMPUTER INC. ASUS Base Station(T100) as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.2/0003:0B05:17E0.0004/input/input14
[ 6.197729] asus 0003:0B05:17E0.0004: input,hiddev97,hidraw2: USB HID v1.11 Mouse [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input2
[ 6.198990] asus 0003:0B05:17E0.0003: input,hiddev96,hidraw3: USB HID v1.11 Device [ASUSTek COMPUTER INC. ASUS Base Station(T100)] on usb-0000:00:14.0-3/input1
[ 6.205416] Console: switching to colour frame buffer device 171x48
[ 6.254589] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 6.360362] PM: Image not found (code -22)
[ 6.441718] EXT4-fs (mmcblk2p6): mounted filesystem with ordered data mode. Opts: (null)
[ 7.073681] systemd-journald[131]: Received SIGTERM from PID 1 (systemd).
[ 7.148096] printk: systemd: 19 output lines suppressed due to ratelimiting
[ 8.215768] EXT4-fs (mmcblk2p6): re-mounted. Opts: acl,user_xattr
[ 8.299500] systemd-journald[326]: Received request to flush runtime journal from PID 1
[ 8.584505] audit: type=1400 audit(1555008596.261:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ping" pid=356 comm="apparmor_parser"
[ 8.667049] audit: type=1400 audit(1555008596.343:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="klogd" pid=366 comm="apparmor_parser"
[ 8.722615] audit: type=1400 audit(1555008596.399:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="syslog-ng" pid=373 comm="apparmor_parser"
[ 8.771981] audit: type=1400 audit(1555008596.448:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="syslogd" pid=380 comm="apparmor_parser"
[ 8.914625] audit: type=1400 audit(1555008596.591:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/lessopen.sh" pid=389 comm="apparmor_parser"
[ 9.152476] audit: type=1400 audit(1555008596.828:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/apache2/mpm-prefork/apache2" pid=410 comm="apparmor_parser"
[ 9.152484] audit: type=1400 audit(1555008596.828:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/apache2/mpm-prefork/apache2//DEFAULT_URI" pid=410 comm="apparmor_parser"
[ 9.152487] audit: type=1400 audit(1555008596.828:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/apache2/mpm-prefork/apache2//HANDLING_UNTRUSTED_INPUT" pid=410 comm="apparmor_parser"
[ 9.152491] audit: type=1400 audit(1555008596.828:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/apache2/mpm-prefork/apache2//phpsysinfo" pid=410 comm="apparmor_parser"
[ 9.199038] battery: ACPI: Battery Slot [BATC] (battery present)
[ 9.273934] audit: type=1400 audit(1555008596.950:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/dovecot/anvil" pid=418 comm="apparmor_parser"
[ 9.286623] ACPI: AC Adapter [ADP1] (on-line)
[ 9.431958] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input15
[ 9.432114] ACPI: Lid Switch [LID]
[ 9.432265] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input16
[ 9.432396] ACPI: Sleep Button [SLPB]
[ 9.458503] rtc_cmos 00:00: registered as rtc0
[ 9.458553] rtc_cmos 00:00: no alarms, 242 bytes nvram
[ 9.520126] [Firmware Bug]: No valid trip found
[ 9.521216] Bluetooth: Core ver 2.22
[ 9.521276] NET: Registered protocol family 31
[ 9.521278] Bluetooth: HCI device and connection manager initialized
[ 9.521287] Bluetooth: HCI socket layer initialized
[ 9.521292] Bluetooth: L2CAP socket layer initialized
[ 9.521304] Bluetooth: SCO socket layer initialized
[ 9.546571] inv-mpu6050-i2c i2c-INVN6500:00: mounting matrix not found: using identity...
[ 9.546584] inv-mpu6050-i2c i2c-INVN6500:00: i2c-INVN6500:00 supply vddio not found, using dummy regulator
[ 9.567357] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input17
[ 9.568772] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card0/input18
[ 9.700587] Bluetooth: HCI UART driver ver 2.3
[ 9.700592] Bluetooth: HCI UART protocol H4 registered
[ 9.700594] Bluetooth: HCI UART protocol BCSP registered
[ 9.700637] Bluetooth: HCI UART protocol LL registered
[ 9.700639] Bluetooth: HCI UART protocol ATH3K registered
[ 9.700665] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 9.700797] Bluetooth: HCI UART protocol Intel registered
[ 9.700933] Bluetooth: HCI UART protocol Broadcom registered
[ 9.700956] Bluetooth: HCI UART protocol QCA registered
[ 9.700959] Bluetooth: HCI UART protocol AG6XX registered
[ 9.712544] hci_uart_bcm serial0-0: ACPI Interrupt resource is active-high, this is usually wrong, treating the IRQ as active-low
[ 9.712823] hci_uart_bcm serial0-0: serial0-0 supply vbat not found, using dummy regulator
[ 9.712872] hci_uart_bcm serial0-0: serial0-0 supply vddio not found, using dummy regulator
[ 9.750726] i2c i2c-4: Added multiplexed i2c bus 14
[ 9.762042] ak8975 14-000c: mounting matrix not found: using identity...
[ 9.762053] ak8975 14-000c: 14-000c supply vdd not found, using dummy regulator
[ 9.762097] ak8975 14-000c: 14-000c supply vid not found, using dummy regulator
[ 9.763167] intel_sst_acpi 80860F28:00: BYT-CR not detected
[ 9.763374] intel_sst_acpi 80860F28:00: LPE base: 0x90a00000 size:0x200000
[ 9.763378] intel_sst_acpi 80860F28:00: IRAM base: 0x90ac0000
[ 9.763430] intel_sst_acpi 80860F28:00: DRAM base: 0x90b00000
[ 9.763440] intel_sst_acpi 80860F28:00: SHIM base: 0x90b40000
[ 9.763450] intel_sst_acpi 80860F28:00: Mailbox base: 0x90b44000
[ 9.763458] intel_sst_acpi 80860F28:00: DDR base: 0x20000000
[ 9.763618] intel_sst_acpi 80860F28:00: Got drv data max stream 25
[ 9.915419] Bluetooth: hci0: BCM: chip id 84
[ 9.916109] Bluetooth: hci0: BCM: features 0x0f
[ 9.917304] Bluetooth: hci0: BCM4324B3
[ 9.917311] Bluetooth: hci0: BCM4324B3 (002.004.006) build 0000
[ 9.925706] ------------[ cut here ]------------
[ 9.925709] Potential Error: Setting GPIO with direct_irq_en to output
[ 9.925734] WARNING: CPU: 3 PID: 406 at drivers/pinctrl/intel/pinctrl-baytrail.c:1031 byt_gpio_set_direction+0x6d/0x8b
[ 9.925736] Modules linked in: asus_nb_wmi(+) snd_intel_sst_acpi ak8975 snd_intel_sst_core snd_soc_sst_atom_hifi2_platform joydev snd_soc_acpi_intel_match hci_uart snd_soc_rt5640 snd_soc_acpi snd_soc_rl6231 btqca snd_soc_core btrtl snd_hdmi_lpe_audio btbcm snd_compress ac97_bus btintel inv_mpu6050_i2c snd_pcm thermal tpm_tis bluetooth inv_mpu6050 rtc_cmos tpm_tis_core industrialio_triggered_buffer button snd_timer tpm kfifo_buf intel_int0002_vgpio soc_button_array i2c_mux snd lpc_ich acpi_pad ac ecdh_generic cm3218x soundcore industrialio battery hid_asus asus_wmi rfkill hid_multitouch usbhid mmc_block i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops xhci_pci drm xhci_hcd wmi video i2c_hid sdhci_acpi sdhci mmc_core 8250_dw sg dm_multipath dm_mod dax efivarfs
[ 9.925790] CPU: 3 PID: 406 Comm: systemd-udevd Not tainted 5.1.0-rc3-rrh-t100-3 #1
[ 9.925792] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.307 05/09/2014
[ 9.925797] RIP: 0010:byt_gpio_set_direction+0x6d/0x8b
[ 9.925800] Code: 00 49 89 c5 41 8b 1c 24 83 e3 f9 45 84 ff 74 05 83 cb 02 eb 17 41 8b 06 0f ba e0 1b 73 0e 48 c7 c7 e3 5a e7 81 e8 73 b3 d4 ff <0f> 0b 41 89 1c 24 4c 89 ee 48 89 ef e8 62 08 34 00 31 c0 5b 5d 41
[ 9.925803] RSP: 0018:ffffc90000473520 EFLAGS: 00010096
[ 9.925805] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 9.925807] RDX: 000000024f9e5070 RSI: ffffffff8246fefa RDI: ffffffff8246da8c
[ 9.925810] RBP: ffff8880761ab208 R08: ffffffff8246fec0 R09: 000000000000003a
[ 9.925812] R10: 0000000000000008 R11: 000000056859070a R12: ffffc900000c9268
[ 9.925813] R13: 0000000000000246 R14: ffffc900000c9260 R15: 0000000000000000
[ 9.925816] FS: 00007f3703aa8d40(0000) GS:ffff888076780000(0000) knlGS:0000000000000000
[ 9.925818] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9.925820] CR2: 00007f80176162b8 CR3: 0000000074096000 CR4: 00000000001006e0
[ 9.925822] Call Trace:
[ 9.925831] pinctrl_gpio_direction+0x5c/0x8e
[ 9.925836] byt_gpio_direction_output+0x19/0x35
[ 9.925841] gpiod_direction_output_raw_commit+0x71/0x113
[ 9.925847] gpiochip_request_own_desc+0x60/0x97
[ 9.925853] acpi_gpio_adr_space_handler+0x17d/0x279
[ 9.925860] acpi_ev_address_space_dispatch+0x2d9/0x37b
[ 9.925865] ? acpi_gpiochip_alloc_event+0x256/0x256
[ 9.925870] acpi_ex_access_region+0x434/0x4d3
[ 9.925875] ? acpi_ut_trace+0x1d/0x59
[ 9.925880] acpi_ex_write_gpio+0xdd/0x113
[ 9.925885] acpi_ex_write_data_to_field+0xcf/0x34f
[ 9.925890] acpi_ex_store_object_to_node+0x2ca/0x31f
[ 9.925894] acpi_ex_store+0xab/0x444
[ 9.925898] ? acpi_ut_trace_str+0x21/0x63
[ 9.925902] acpi_ex_opcode_1A_1T_1R+0x40e/0x596
[ 9.925907] acpi_ds_exec_end_op+0x159/0x74e
[ 9.925911] acpi_ps_parse_loop+0x7ca/0x88c
[ 9.925916] acpi_ps_parse_aml+0x1a6/0x542
[ 9.925920] acpi_ps_execute_method+0x1fc/0x2b8
[ 9.925925] acpi_ns_evaluate+0x33c/0x4cf
[ 9.925929] acpi_evaluate_object+0x1c6/0x389
[ 9.925940] wmidev_evaluate_method+0xe7/0x102 [wmi]
[ 9.925947] wmi_evaluate_method+0x5e/0x79 [wmi]
[ 9.925955] asus_wmi_evaluate_method+0x5a/0xbf [asus_wmi]
[ 9.925961] asus_wmi_probe+0xfd/0xc7a [asus_wmi]
[ 9.925969] platform_drv_probe+0x2d/0x6e
[ 9.925974] really_probe+0x1a2/0x36f
[ 9.925978] driver_probe_device+0xca/0xfa
[ 9.925983] device_driver_attach+0x38/0x4f
[ 9.925987] __driver_attach+0x100/0x108
[ 9.925991] ? device_driver_attach+0x4f/0x4f
[ 9.925994] bus_for_each_dev+0x6c/0x9e
[ 9.926000] ? do_raw_spin_lock+0x2b/0x52
[ 9.926004] bus_add_driver+0x122/0x1d1
[ 9.926009] ? pwm1_enable_store+0x78/0x78 [asus_wmi]
[ 9.926013] driver_register+0x94/0xc6
[ 9.926017] __platform_driver_probe+0x4b/0xc3
[ 9.926023] ? pwm1_enable_store+0x78/0x78 [asus_wmi]
[ 9.926026] __platform_create_bundle+0x74/0xb1
[ 9.926031] ? 0xffffffffa0099000
[ 9.926036] asus_wmi_register_driver+0x50/0x63 [asus_wmi]
[ 9.926041] do_one_initcall+0x96/0x18e
[ 9.926047] ? kmem_cache_alloc_trace+0x81/0x90
[ 9.926053] do_init_module+0x56/0x1c6
[ 9.926058] load_module+0x134b/0x1951
[ 9.926064] ? vfs_read+0xa2/0xc7
[ 9.926070] ? __do_sys_finit_module+0xae/0xd4
[ 9.926074] __do_sys_finit_module+0xae/0xd4
[ 9.926079] do_syscall_64+0x49/0x56
[ 9.926085] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 9.926088] RIP: 0033:0x7f3702912269
[ 9.926091] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ff 0b 2c 00 f7 d8 64 89 01 48
[ 9.926093] RSP: 002b:00007fffa97c7658 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 9.926096] RAX: ffffffffffffffda RBX: 0000558bc4b2c760 RCX: 00007f3702912269
[ 9.926098] RDX: 0000000000000000 RSI: 00007f370324e8bd RDI: 0000000000000007
[ 9.926100] RBP: 00007f370324e8bd R08: 0000000000000000 R09: 0000558bc4b02a20
[ 9.926102] R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000020000
[ 9.926104] R13: 0000558bc4b15bf0 R14: 0000000000000000 R15: 0000000003938700
[ 9.926108] ---[ end trace 514c8a9601f10d48 ]---
[ 9.926675] asus_wmi: Initialization: 0x1
[ 9.926871] input: PC Speaker as /devices/platform/pcspkr/input/input19
[ 9.926889] asus_wmi: BIOS WMI version: 7.9
[ 9.927047] asus_wmi: SFUN value: 0x37
[ 9.960057] input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input20
[ 9.961855] asus_wmi: Number of fans: 1
[ 10.022579] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 10.029965] cryptd: max_cpu_qlen set to 1000
[ 10.048067] Adding 2110460k swap on /dev/mmcblk2p5. Priority:-2 extents:1 across:2110460k SSFS
[ 10.049353] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 10.078499] SSE version of gcm_enc/dec engaged.
[ 10.212227] iTCO_vendor_support: vendor-support=0
[ 10.224656] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 10.224809] iTCO_wdt: Found a Bay Trail SoC TCO device (Version=3, TCOBASE=0x0460)
[ 10.238947] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 10.240568] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 10.242313] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 10.246660] input: gpio-keys as /devices/platform/gpio-keys.1.auto/input/input21
[ 10.246990] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 10.250354] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 10.257671] input: gpio-keys as /devices/platform/gpio-keys.2.auto/input/input22
[ 10.294392] fuse init (API version 7.29)
[ 10.343305] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43241b4-sdio for chip BCM4324/5
[ 10.343444] usbcore: registered new interface driver brcmfmac
[ 10.357998] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43241b4-sdio.ASUSTeK COMPUTER INC.-T100TA.txt failed with error -2
[ 10.358050] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43241b4-sdio.txt failed with error -2
[ 10.358206] brcmfmac: brcmf_fw_nvram_from_efi: Using nvram EFI variable
[ 10.474981] Bluetooth: hci0: BCM4324B3 (002.004.006) build 0161
[ 10.506811] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43241b4-sdio for chip BCM4324/5
[ 10.506878] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 10.507266] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4324/5 wl0: Jul 17 2013 07:36:07 version 6.10.197.71 (r412987) FWID 01-882d2634
[ 10.525541] bytcr_rt5640 bytcr_rt5640: quirk IN1_MAP enabled
[ 10.525546] bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 3
[ 10.525549] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-threshold-microamp 2000
[ 10.525552] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-scale-factor 1
[ 10.525555] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled
[ 10.536684] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
[ 10.536752] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
[ 10.539138] bytcr_rt5640 bytcr_rt5640: rt5640-aif1 <-> ssp2-port mapping ok
[ 10.544273] input: bytcr-rt5640 Headset as /devices/platform/80860F28:00/bytcr_rt5640/sound/card1/input23
[ 12.333585] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 12.333588] Bluetooth: BNEP filters: protocol multicast
[ 12.333598] Bluetooth: BNEP socket layer initialized
[ 15.229036] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[ 16.424182] NET: Registered protocol family 17
[ 21.388280] NET: Registered protocol family 38
[ 22.615955] input: MX Anywhere 2 Keyboard as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input24
[ 22.617490] input: MX Anywhere 2 Mouse as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input25
[ 22.618237] hid-generic 0005:046D:B013.0005: input,hidraw4: BLUETOOTH HID v0.07 Keyboard [MX Anywhere 2] on 74:D0:2B:DF:77:E9
[ 28.463197] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 38.324221] intel_sst_acpi 80860F28:00: FW Version 01.0c.00.01
[ 38.784560] Bluetooth: RFCOMM TTY layer initialized
[ 38.784574] Bluetooth: RFCOMM socket layer initialized
[ 38.784590] Bluetooth: RFCOMM ver 1.11
------End of dmesg log before hibernation ------------------------

------Start of dmesg log after hibernation resume ------------------------
[ 192.650763] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.650777] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.650780] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.650794] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
... Deleted multiple identical lines
[ 192.656401] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.656405] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.656412] i2c_designware 80860F41:01: timeout in disabling adapter
[ 192.656419] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.656423] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.656437] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
... Deleted multiple identical lines
[ 192.656441] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.668256] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.668259] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.668277] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.668281] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.668301] i2c_designware 80860F41:02: Error i2c_dw_xfer call while suspended
[ 192.791685] usb usb1: root hub lost power or was reset
[ 192.791707] usb usb2: root hub lost power or was reset
[ 192.799078] ACPI: button: The lid device is not compliant to SW_LID.
[ 192.895823] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 192.901512] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 192.907632] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 192.916305] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 193.132888] usb 1-3: reset full-speed USB device number 2 using xhci_hcd
[ 193.348820] PM: Basic memory bitmaps freed
[ 193.348831] OOM killer enabled.
[ 193.348836] Restarting tasks ... done.
[ 193.354346] PM: hibernation exit
[ 193.376657] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 193.376674] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[ 193.399152] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 193.426828] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 193.449112] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 193.471731] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 193.494025] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 193.516592] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 194.008684] systemd-journald[326]: /dev/kmsg buffer overrun, some messages lost.
[ 194.652559] i2c_designware 80860F41:01: timeout in disabling adapter
[ 196.575683] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 196.577214] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 197.097993] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 197.099804] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 197.101633] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 197.105977] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 197.210341] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43241b4-sdio for chip BCM4324/5
[ 197.210510] usbcore: registered new interface driver brcmfmac
[ 197.248463] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43241b4-sdio.ASUSTeK COMPUTER INC.-T100TA.txt failed with error -2
[ 197.248523] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43241b4-sdio.txt failed with error -2
[ 197.248728] brcmfmac: brcmf_fw_nvram_from_efi: Using nvram EFI variable
[ 197.382866] Bluetooth: HCI UART driver ver 2.3
[ 197.382871] Bluetooth: HCI UART protocol H4 registered
[ 197.382873] Bluetooth: HCI UART protocol BCSP registered
[ 197.382928] Bluetooth: HCI UART protocol LL registered
[ 197.382931] Bluetooth: HCI UART protocol ATH3K registered
[ 197.383141] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 197.383268] Bluetooth: HCI UART protocol Intel registered
[ 197.383404] Bluetooth: HCI UART protocol Broadcom registered
[ 197.383429] Bluetooth: HCI UART protocol QCA registered
[ 197.383431] Bluetooth: HCI UART protocol AG6XX registered
[ 197.393969] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43241b4-sdio for chip BCM4324/5
[ 197.394067] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 197.394417] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4324/5 wl0: Jul 17 2013 07:36:07 version 6.10.197.71 (r412987) FWID 01-882d2634
[ 197.395215] hci_uart_bcm serial0-0: ACPI Interrupt resource is active-high, this is usually wrong, treating the IRQ as active-low
[ 197.395488] hci_uart_bcm serial0-0: serial0-0 supply vbat not found, using dummy regulator
[ 197.395529] hci_uart_bcm serial0-0: serial0-0 supply vddio not found, using dummy regulator
[ 197.525916] battery: ACPI: Battery Slot [BATC] (battery present)
[ 197.605088] Bluetooth: hci0: BCM: chip id 84
[ 197.605579] Bluetooth: hci0: BCM: features 0x0f
[ 197.606767] Bluetooth: hci0: BCM4324B3
[ 197.606774] Bluetooth: hci0: BCM4324B3 (002.004.006) build 0000
[ 197.780640] input: ATML1000:00 03EB:8C0D as /devices/platform/80860F41:05/i2c-5/i2c-ATML1000:00/0018:03EB:8C0D.0001/input/input29
[ 197.780914] hid-multitouch 0018:03EB:8C0D.0001: input,hidraw1: I2C HID v1.00 Device [ATML1000:00 03EB:8C0D] on i2c-ATML1000:00
[ 198.148989] Bluetooth: hci0: BCM4324B3 (002.004.006) build 0161
[ 203.133178] i2c_designware 80860F41:01: controller timed out
[ 204.156346] i2c_designware 80860F41:01: controller timed out
[ 205.180265] i2c_designware 80860F41:01: controller timed out
[ 206.204451] i2c_designware 80860F41:01: controller timed out
[ 207.228505] i2c_designware 80860F41:01: controller timed out
[ 208.252674] i2c_designware 80860F41:01: controller timed out
[ 209.277005] i2c_designware 80860F41:01: controller timed out
[ 210.300975] i2c_designware 80860F41:01: controller timed out
[ 211.325383] i2c_designware 80860F41:01: controller timed out
[ 212.349397] i2c_designware 80860F41:01: controller timed out
[ 213.373904] i2c_designware 80860F41:01: controller timed out
[ 214.397586] i2c_designware 80860F41:01: controller timed out
[ 214.652699] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 215.422593] i2c_designware 80860F41:01: controller timed out
[ 216.445688] i2c_designware 80860F41:01: controller timed out
[ 216.529562] Uhhuh. NMI received for unknown reason 2c on CPU 0.
[ 216.529564] Do you have a strange power saving mode enabled?
[ 216.529565] Dazed and confused, but trying to continue
[ 217.470338] i2c_designware 80860F41:01: controller timed out
[ 218.494410] i2c_designware 80860F41:01: controller timed out
[ 219.582142] i2c_designware 80860F41:01: controller timed out
[ 220.606616] i2c_designware 80860F41:01: controller timed out
[ 221.630722] i2c_designware 80860F41:01: controller timed out
[ 222.654869] i2c_designware 80860F41:01: controller timed out
[ 223.678964] i2c_designware 80860F41:01: controller timed out
[ 224.702816] i2c_designware 80860F41:01: controller timed out
[ 225.727177] i2c_designware 80860F41:01: controller timed out
[ 226.751266] i2c_designware 80860F41:01: controller timed out
[ 227.775371] i2c_designware 80860F41:01: controller timed out
[ 228.799471] i2c_designware 80860F41:01: controller timed out
[ 229.823552] i2c_designware 80860F41:01: controller timed out
------End of dmesg log after hibernation resume ------------------------

2019-04-18 11:43:21

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hello Robert,

On 11-04-19 21:50, Robert R. Howell wrote:
> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>
>> Hmm, interesting so you have hibernation working on a T100TA
>> (with 5.0 + 02e45646d53b reverted), right ?
>>
> Hi Hans and Kai-Heng
>
> First, apologies for how long it took me to reply to both your inquiries.
> In trying to answer them I discovered some inconsistencies in how the T100TA was
> behaving on different hibernation attempts and I've been trying to sort those out.
> I haven't been completely successful in that, but here's a brief summary.
>
> Yes I do have hibernation working (at least most of the time) on a T100TA,
> with 5.0 + 02e45646d53b reverted (more about that below), and with a systemd
> hibernate script also described below.
>
> Trying to be more quantitative about "most of the time" is in part want I've been
> testing the last few days. I just finished a cycle of 20 hibernates/resumes
> which were all successful at least in the sense that after resume internal
> sound was working, along with all the other critical functions I care about
> (WiFi, Bluetooth, etc.). However I have occasionally (perhaps 1 in 10 times)
> seen something go wrong with sound on resume and the only way to get it
> working again was to a full reboot. During the successful cycles I also
> sometimes see i2c_designware or intel_sst_acpi error messages but they
> don't seem to indicate an unrecoverable failure. I was hoping to sort out
> what errors I was seen on the occasions where sound was lost till a reboot,
> but those are rare enough I haven't been able to sort out the difference
> between those and the "recoverable" errors.
>
> Regarding the revert of 02e45646d53b, there were some code changes in
> adjacent lines so a simple revert wouldn't apply cleanly to 5.0.0
> but the changes were small enough that I was able to manually "merge"
> the revert and the 5.0.0 changes. I have posted a patch file under
> Bugzilla: <https://bugzilla.kernel.org/show_bug.cgi?id=202139>
> showing what I actually did to revert 02e45646d53b for 5.0.0. As I mentioned
> in an earlier message, I have NOT been able to produce a working revert of
> 02e45646d53b for the 5.1-rc3 kernel.
>
> To make hibernation work on the T100 I also had to create a script
> /usr/lib/systemd/system-sleep/t100_hibernate.sh which unloads various drivers
> (including sound) before hibernate, then restarts them afterwords. I've inserted
> it below. I'm not certain all the steps in it are still necessary, but the
> intermittent failures make it very difficult to determine what is absolutely essential.
>
> -----t100_hibernate.sh systemd script-------
> #!/bin/bash
> echo "Hibernate script $1 $2"
> [ $2 != 'hibernate' ] && exit 0
>
> case $1 in
> pre)
> echo "Going to $2..."
> /sbin/modprobe -r brcmfmac
> /sbin/modprobe -r hci_uart
> /sbin/modprobe -r battery
> /sbin/modprobe -r hid_multitouch
> /usr/bin/killall pulseaudio
> /sbin/modprobe -r snd_soc_sst_bytcr_rt5640
> /sbin/modprobe -r snd_soc_rt5640
> /sbin/modprobe -r snd_soc_sst_acpi
> ;;
> post)
> echo "Waking from $2..."
> /sbin/modprobe brcmfmac
> /sbin/modprobe hci_uart
> /sbin/modprobe battery
> /sbin/modprobe hid_multitouch
> # Just load the following and it will pull in other snd modules
> /sbin/modprobe snd_soc_sst_acpi
> /usr/sbin/service NetworkManager restart
> /usr/sbin/service wpa_supplicant restart
> # The above is usually enough but occasionally sound doesn't come up properly
> # and doing the following seems to restore it in those cases.
> /usr/bin/killall pulseaudio
> /usr/sbin/rmmod snd_soc_sst_bytcr_rt5640
> /usr/sbin/rmmod snd_soc_rt5640
> /usr/sbin modprobe snd_soc_rt5640
> /usr/sbin modprobe snd_soc_sst_bytcr_rt5640
> ;;
> esac
> -----end of script-------------------------------
>
> I'll send a second message with the system logs which Kai-Heng requested,
> with his patch applied to 5.1-rc3.

Ok, so you have hibernation sort of working, with a bunch of hacks.

This is exactly why I usually do not spend any time on trying to get
hibernation to work.

Still since my patch is regressing things for you I will try to
take a look at this and see if I can reproduce and come up with
a fix. But this is not going to be a high priority thing for me to
work on.

In the mean time I've gone ahead and submitted my version of the
fix for the problem Kai-Heng was seeing, since that does not seem
to make your problem worse; and it will be good to get that problem
fixed.

Regards,

Hans

2019-04-19 22:47:06

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On 4/18/19 5:42 AM, Hans de Goede wrote:

>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>
>>> Hmm, interesting so you have hibernation working on a T100TA
>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>

> Still since my patch is regressing things for you I will try to
> take a look at this and see if I can reproduce and come up with
> a fix. But this is not going to be a high priority thing for me to
> work on.
>
> In the mean time I've gone ahead and submitted my version of the
> fix for the problem Kai-Heng was seeing, since that does not seem
> to make your problem worse; and it will be good to get that problem
> fixed.
>
> Regards,
>
> Hans
>

I've managed to find a way around the i2c_designware timeout issues
on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
which was added in the 02e45646d53b commit.

To test that I've started with a 5.1-rc5 kernel, applied your recent patch
to acpi_lpss.c, then apply the following patch of mine, removing
DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
other patches as well but those are not related to the i2c-designware or
acpi issues addressed here.)

On a resume from hibernation I still see one error:
"i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
but I no longer get the i2c_designware timeouts, and audio does now work
after the resume.

Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
hardware, but perhaps this will give you a clue as to what is going
wrong with hibernate/resume on the T100TA's.

With the above now working I've also experimented with my systemd
hibernate script and at least in limited testing I only need to
remove the brcmfmac and hci_uart drivers before hibernate.
I no longer need to remove sound drivers or the other ones shown in
my earlier script. Without more testing I'm not sure at what point
in kernel development those other driver removals stopped being necessary.

Let me know if I can do any other tests to help.

Bob Howell

---
diff -uprN linux_original/drivers/i2c/busses/i2c-designware-platdrv.c linux/drivers/i2c/busses/i2c-designware-platdrv.c
--- linux_original/drivers/i2c/busses/i2c-designware-platdrv.c 2019-04-14 16:17:41.000000000 -0600
+++ linux/drivers/i2c/busses/i2c-designware-platdrv.c 2019-04-18 22:45:58.836246889 -0600
@@ -367,7 +367,6 @@ static int dw_i2c_plat_probe(struct plat

dev_pm_set_driver_flags(&pdev->dev,
DPM_FLAG_SMART_PREPARE |
- DPM_FLAG_SMART_SUSPEND |
DPM_FLAG_LEAVE_SUSPENDED);

/* The code below assumes runtime PM to be disabled. */
---

2019-04-23 08:10:38

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
>
> On 4/18/19 5:42 AM, Hans de Goede wrote:
>
> >> On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >>>
> >>> Hmm, interesting so you have hibernation working on a T100TA
> >>> (with 5.0 + 02e45646d53b reverted), right ?
> >>>
>
> > Still since my patch is regressing things for you I will try to
> > take a look at this and see if I can reproduce and come up with
> > a fix. But this is not going to be a high priority thing for me to
> > work on.
> >
> > In the mean time I've gone ahead and submitted my version of the
> > fix for the problem Kai-Heng was seeing, since that does not seem
> > to make your problem worse; and it will be good to get that problem
> > fixed.
> >
> > Regards,
> >
> > Hans
> >
>
> I've managed to find a way around the i2c_designware timeout issues
> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> which was added in the 02e45646d53b commit.
>
> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
> to acpi_lpss.c, then apply the following patch of mine, removing
> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
> other patches as well but those are not related to the i2c-designware or
> acpi issues addressed here.)
>
> On a resume from hibernation I still see one error:
> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
> but I no longer get the i2c_designware timeouts, and audio does now work
> after the resume.
>
> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> hardware, but perhaps this will give you a clue as to what is going
> wrong with hibernate/resume on the T100TA's.

What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?

2019-04-23 20:04:45

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>
> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
>>
>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>
>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>>>
>>>>> Hmm, interesting so you have hibernation working on a T100TA
>>>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>>>
>>
>>
>> I've managed to find a way around the i2c_designware timeout issues
>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>> which was added in the 02e45646d53b commit.
>>
>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
>> to acpi_lpss.c, then apply the following patch of mine, removing
>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
>> other patches as well but those are not related to the i2c-designware or
>> acpi issues addressed here.)
>>
>> On a resume from hibernation I still see one error:
>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>> but I no longer get the i2c_designware timeouts, and audio does now work
>> after the resume.
>>
>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>> hardware, but perhaps this will give you a clue as to what is going
>> wrong with hibernate/resume on the T100TA's.
>
> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>

I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
then the timeouts go away.

Bob Howell

2019-04-24 10:10:28

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
>
> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> >
> > On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
> >>
> >> On 4/18/19 5:42 AM, Hans de Goede wrote:
> >>
> >>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >>>>>
> >>>>> Hmm, interesting so you have hibernation working on a T100TA
> >>>>> (with 5.0 + 02e45646d53b reverted), right ?
> >>>>>
> >>
> >>
> >> I've managed to find a way around the i2c_designware timeout issues
> >> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> >> which was added in the 02e45646d53b commit.
> >>
> >> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
> >> to acpi_lpss.c, then apply the following patch of mine, removing
> >> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
> >> other patches as well but those are not related to the i2c-designware or
> >> acpi issues addressed here.)
> >>
> >> On a resume from hibernation I still see one error:
> >> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
> >> but I no longer get the i2c_designware timeouts, and audio does now work
> >> after the resume.
> >>
> >> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> >> hardware, but perhaps this will give you a clue as to what is going
> >> wrong with hibernate/resume on the T100TA's.
> >
> > What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> >
>
> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
> then the timeouts go away.

OK, thanks!

Is non-hibernation system suspend affected too?

2019-04-25 16:45:12

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:

> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
>>
>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>>>
>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
>>>>
>>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>>>
>>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>>>>>
>>>>>>> Hmm, interesting so you have hibernation working on a T100TA
>>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>>>>>
>>>>
>>>>
>>>> I've managed to find a way around the i2c_designware timeout issues
>>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>>>> which was added in the 02e45646d53b commit.
>>>>
>>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
>>>> to acpi_lpss.c, then apply the following patch of mine, removing
>>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
>>>> other patches as well but those are not related to the i2c-designware or
>>>> acpi issues addressed here.)
>>>>
>>>> On a resume from hibernation I still see one error:
>>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>>>> but I no longer get the i2c_designware timeouts, and audio does now work
>>>> after the resume.
>>>>
>>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>>>> hardware, but perhaps this will give you a clue as to what is going
>>>> wrong with hibernate/resume on the T100TA's.
>>>
>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>>>
>>
>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>> then the timeouts go away.
>
> OK, thanks!
>
> Is non-hibernation system suspend affected too?

I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
but without any changes to i2c-designware-platdrv.c, so the
DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
are all set.

Suspend does work OK, and after resume I do NOT get any of the crippling
i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
"i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
intermittently on these machines, but doesn't seem related to the other issues.
I had one test run when it was absent but the rest of the messages were the
same -- but then kept getting that unknown key error on all my later tries.

I did notice the "2sidle" in the following rather than "shallow" or "deep". A
cat of /sys/power/state shows "freeze mem disk" but a
cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and deep
are not enabled for this system. I did check the input power (or really current)
as it went into suspend and the micro-usb power input drops from about
0.5 amps to 0.05 amps. But clearly a lot of devices are still active, as movement
of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend. That presumably is
why suspend doesn't trigger the same i2c_designware problems as hibernate.

Let me know if I can do any other tests.

Bob Howell

----DMESG OUTPUT ON SUSPEND------------------
[ 71.791495] NET: Registered protocol family 38
[ 73.150736] input: MX Anywhere 2 Keyboard as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input24
[ 73.156612] input: MX Anywhere 2 Mouse as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input25
[ 73.159504] hid-generic 0005:046D:B013.0005: input,hidraw4: BLUETOOTH HID v0.07 Keyboard [MX Anywhere 2] on 74:D0:2B:DF:77:E9
[ 102.719170] asus_wmi: Unknown key 79 pressed
[ 102.897214] asus_wmi: Unknown key 79 pressed
[ 104.298409] PM: suspend entry (s2idle)
[ 104.298414] PM: Syncing filesystems ... done.
[ 105.410883] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 105.413556] OOM killer disabled.
[ 105.413558] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 123.353720] i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended
[ 123.635028] ACPI: button: The lid device is not compliant to SW_LID.
[ 124.086421] OOM killer enabled.
[ 124.086491] Restarting tasks ... done.
[ 124.120647] PM: suspend exit
[ 124.939566] asus_wmi: Unknown key 79 pressed

2019-04-30 14:41:27

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi,

On 4/25/19 6:38 PM, Robert R. Howell wrote:
> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>
>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
>>>
>>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>>>>
>>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
>>>>>
>>>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>>>>
>>>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>>>>>>
>>>>>>>> Hmm, interesting so you have hibernation working on a T100TA
>>>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>>>>>>
>>>>>
>>>>>
>>>>> I've managed to find a way around the i2c_designware timeout issues
>>>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>>>>> which was added in the 02e45646d53b commit.
>>>>>
>>>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
>>>>> to acpi_lpss.c, then apply the following patch of mine, removing
>>>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
>>>>> other patches as well but those are not related to the i2c-designware or
>>>>> acpi issues addressed here.)
>>>>>
>>>>> On a resume from hibernation I still see one error:
>>>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>>>>> but I no longer get the i2c_designware timeouts, and audio does now work
>>>>> after the resume.
>>>>>
>>>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>>>>> hardware, but perhaps this will give you a clue as to what is going
>>>>> wrong with hibernate/resume on the T100TA's.
>>>>
>>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>>>>
>>>
>>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>>> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
>>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>>> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>>> then the timeouts go away.
>>
>> OK, thanks!
>>
>> Is non-hibernation system suspend affected too?
>
> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
> but without any changes to i2c-designware-platdrv.c, so the
> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
> are all set.
>
> Suspend does work OK, and after resume I do NOT get any of the crippling
> i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
> "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
> error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
> intermittently on these machines, but doesn't seem related to the other issues.
> I had one test run when it was absent but the rest of the messages were the
> same -- but then kept getting that unknown key error on all my later tries.

I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
on suspend/resume on my own T100TA and I could not reproduce this.

Can you try without the BT keyboard paired and waking up from suspend using the
tablet part's power-button ?

Also do you still have the scripts to rmmod some modules before suspend ?

> I did notice the "2sidle" in the following rather than "shallow" or "deep". A
> cat of /sys/power/state shows "freeze mem disk" but a
> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and deep
> are not enabled for this system. I did check the input power (or really current)
> as it went into suspend and the micro-usb power input drops from about
> 0.5 amps to 0.05 amps. But clearly a lot of devices are still active, as movement
> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend. That presumably is
> why suspend doesn't trigger the same i2c_designware problems as hibernate.

s2idle is the normal / expected suspend condition on these tablet devices.

As for how much energy is consumed during suspend, the device should use
S0i3 and then you should get ok (so not great, but also not too much) power
consumption during suspend:

[root@dhcp-43-189 ~]# cat /sys/kernel/debug/pmc_atom/sleep_state
S0IR Residency: 156256us
S0I1 Residency: 3968us
S0I2 Residency: 0us
S0I3 Residency: 70557440us
S0 Residency: 11826052384us

After being suspended for a couple of seconds, you should see a significant
(large) value in S0I3 like above.

Regards,

Hans

>
> Let me know if I can do any other tests.
>
> Bob Howell
>
> ----DMESG OUTPUT ON SUSPEND------------------
> [ 71.791495] NET: Registered protocol family 38
> [ 73.150736] input: MX Anywhere 2 Keyboard as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input24
> [ 73.156612] input: MX Anywhere 2 Mouse as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input25
> [ 73.159504] hid-generic 0005:046D:B013.0005: input,hidraw4: BLUETOOTH HID v0.07 Keyboard [MX Anywhere 2] on 74:D0:2B:DF:77:E9
> [ 102.719170] asus_wmi: Unknown key 79 pressed
> [ 102.897214] asus_wmi: Unknown key 79 pressed
> [ 104.298409] PM: suspend entry (s2idle)
> [ 104.298414] PM: Syncing filesystems ... done.
> [ 105.410883] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [ 105.413556] OOM killer disabled.
> [ 105.413558] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> [ 123.353720] i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended
> [ 123.635028] ACPI: button: The lid device is not compliant to SW_LID.
> [ 124.086421] OOM killer enabled.
> [ 124.086491] Restarting tasks ... done.
> [ 124.120647] PM: suspend exit
> [ 124.939566] asus_wmi: Unknown key 79 pressed
>

2019-05-09 04:26:09

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On 4/30/19 8:39 AM, Hans de Goede wrote:
>
> Hi,
>
> On 4/25/19 6:38 PM, Robert R. Howell wrote:
>> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>>
>>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
>>>>
>>>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>>>>>
>>>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
>>>>>>
>>>>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>>>>>
>>>>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>>>>>>>
>>>>>>>>> Hmm, interesting so you have hibernation working on a T100TA
>>>>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>> I've managed to find a way around the i2c_designware timeout issues
>>>>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>>>>>> which was added in the 02e45646d53b commit.
>>>>>>
>>>>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
>>>>>> to acpi_lpss.c, then apply the following patch of mine, removing
>>>>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
>>>>>> other patches as well but those are not related to the i2c-designware or
>>>>>> acpi issues addressed here.)
>>>>>>
>>>>>> On a resume from hibernation I still see one error:
>>>>>>    "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>>>>>> but I no longer get the i2c_designware timeouts, and audio does now work
>>>>>> after the resume.
>>>>>>
>>>>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>>>>>> hardware, but perhaps this will give you a clue as to what is going
>>>>>> wrong with hibernate/resume on the T100TA's.
>>>>>
>>>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>>>>>
>>>>
>>>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>>>> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
>>>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>>>> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>>>> then the timeouts go away.
>>>
>>> OK, thanks!
>>>
>>> Is non-hibernation system suspend affected too?
>>
>> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
>> but without any changes to i2c-designware-platdrv.c, so the
>> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
>> are all set.
>>
>> Suspend does work OK, and after resume I do NOT get any of the crippling
>> i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
>>    "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
>> error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
>> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
>> intermittently on these machines, but doesn't seem related to the other issues.
>> I had one test run when it was absent but the rest of the messages were the
>> same -- but then kept getting that unknown key error on all my later tries.
>
> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
> on suspend/resume on my own T100TA and I could not reproduce this.
>
> Can you try without the BT keyboard paired and waking up from suspend using the
> tablet part's power-button ?
>
> Also do you still have the scripts to rmmod some modules before suspend ?
>

The T100TA keyboard is actually a hardwired connection rather than Bluetooth but I
did physically disconnect the keyboard, and also unpaired all the actual Bluetooth
devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
When I suspend, then resume using the tablet power button, I still get the
i2c_dw_xfererror error during the resume. But whatever causes this error isn't fatal,
in the sense that after resume the sound and other i2c functions do still work OK.

While I always get this i2c_dw_xfer error on resume from suspend or hibernation on the T100TA,
I also have a T100TAM and curiously, it NEVER shows that error -- although all the
other suspend and hibernate behavior seems similar. I'm not sure if the following could
be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen controller
while the T100TAM uses an i2c connected SIS0817 touchscreen controller. Other than that
the hardware seems almost identical.

Regarding scripts, while I do still need a systemd hibernate script which removes the
brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no longer need
any script for suspend.

>> I did notice the "2sidle" in the following rather than "shallow" or "deep". A
>> cat of /sys/power/state shows "freeze mem disk" but a
>> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and deep
>> are not enabled for this system. I did check the input power (or really current)
>> as it went into suspend and the micro-usb power input drops from about
>> 0.5 amps to 0.05 amps. But clearly a lot of devices are still active, as movement
>> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend. That presumably is
>> why suspend doesn't trigger the same i2c_designware problems as hibernate.
>
> s2idle is the normal / expected suspend condition on these tablet devices.
>
> As for how much energy is consumed during suspend, the device should use
> S0i3 and then you should get ok (so not great, but also not too much) power
> consumption during suspend:
>
> [root@dhcp-43-189 ~]# cat /sys/kernel/debug/pmc_atom/sleep_state
> S0IR Residency: 156256us
> S0I1 Residency: 3968us
> S0I2 Residency: 0us
> S0I3 Residency: 70557440us
> S0   Residency: 11826052384us
>
> After being suspended for a couple of seconds, you should see a significant
> (large) value in S0I3 like above.

Thanks for this information on the suspend mode. I DO see the S0I3 Residency grow
after a suspend.

Sorry for the long response time -- I was out of town most of last week.

Let me know if I can run any more tests.

Bob

>
> Regards,
>
> Hans
>
>
>
>
>
>
>>
>> Let me know if I can do any other tests.
>>
>> Bob Howell
>>
>> ----DMESG OUTPUT ON SUSPEND------------------
>> [   71.791495] NET: Registered protocol family 38
>> [   73.150736] input: MX Anywhere 2 Keyboard as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input24
>> [   73.156612] input: MX Anywhere 2 Mouse as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input25
>> [   73.159504] hid-generic 0005:046D:B013.0005: input,hidraw4: BLUETOOTH HID v0.07 Keyboard [MX Anywhere 2] on 74:D0:2B:DF:77:E9
>> [ 102.719170] asus_wmi: Unknown key 79 pressed
>> [ 102.897214] asus_wmi: Unknown key 79 pressed
>> [ 104.298409] PM: suspend entry (s2idle)
>> [ 104.298414] PM: Syncing filesystems ... done.
>> [ 105.410883] Freezing user space processes ... (elapsed 0.002 seconds) done.
>> [ 105.413556] OOM killer disabled.
>> [ 105.413558] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>> [ 123.353720] i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended
>> [ 123.635028] ACPI: button: The lid device is not compliant to SW_LID.
>> [ 124.086421] OOM killer enabled.
>> [ 124.086491] Restarting tasks ... done.
>> [ 124.120647] PM: suspend exit
>> [ 124.939566] asus_wmi: Unknown key 79 pressed
>>

2019-05-09 08:51:53

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi,

On 09-05-19 06:24, Robert R. Howell wrote:
> On 4/30/19 8:39 AM, Hans de Goede wrote:
>>
>> Hi,
>>
>> On 4/25/19 6:38 PM, Robert R. Howell wrote:
>>> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>>>
>>>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
>>>>>
>>>>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>>>>>>
>>>>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
>>>>>>>
>>>>>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>>>>>>
>>>>>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>>>>>>>>
>>>>>>>>>> Hmm, interesting so you have hibernation working on a T100TA
>>>>>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I've managed to find a way around the i2c_designware timeout issues
>>>>>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>>>>>>> which was added in the 02e45646d53b commit.
>>>>>>>
>>>>>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
>>>>>>> to acpi_lpss.c, then apply the following patch of mine, removing
>>>>>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
>>>>>>> other patches as well but those are not related to the i2c-designware or
>>>>>>> acpi issues addressed here.)
>>>>>>>
>>>>>>> On a resume from hibernation I still see one error:
>>>>>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>>>>>>> but I no longer get the i2c_designware timeouts, and audio does now work
>>>>>>> after the resume.
>>>>>>>
>>>>>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>>>>>>> hardware, but perhaps this will give you a clue as to what is going
>>>>>>> wrong with hibernate/resume on the T100TA's.
>>>>>>
>>>>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>>>>>>
>>>>>
>>>>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>>>>> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
>>>>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>>>>> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>>>>> then the timeouts go away.
>>>>
>>>> OK, thanks!
>>>>
>>>> Is non-hibernation system suspend affected too?
>>>
>>> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
>>> but without any changes to i2c-designware-platdrv.c, so the
>>> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
>>> are all set.
>>>
>>> Suspend does work OK, and after resume I do NOT get any of the crippling
>>> i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
>>> error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
>>> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
>>> intermittently on these machines, but doesn't seem related to the other issues.
>>> I had one test run when it was absent but the rest of the messages were the
>>> same -- but then kept getting that unknown key error on all my later tries.
>>
>> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
>> on suspend/resume on my own T100TA and I could not reproduce this.
>>
>> Can you try without the BT keyboard paired and waking up from suspend using the
>> tablet part's power-button ?
>>
>> Also do you still have the scripts to rmmod some modules before suspend ?
>>
>
> The T100TA keyboard is actually a hardwired connection rather than Bluetooth but I
> did physically disconnect the keyboard, and also unpaired all the actual Bluetooth
> devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
> When I suspend, then resume using the tablet power button, I still get the
> i2c_dw_xfererror error during the resume. But whatever causes this error isn't fatal,
> in the sense that after resume the sound and other i2c functions do still work OK.
>
> While I always get this i2c_dw_xfer error on resume from suspend or hibernation on the T100TA,
> I also have a T100TAM and curiously, it NEVER shows that error -- although all the
> other suspend and hibernate behavior seems similar. I'm not sure if the following could
> be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen controller
> while the T100TAM uses an i2c connected SIS0817 touchscreen controller. Other than that
> the hardware seems almost identical.

I've been testing on an actual T100TA, with the ATML1000 touchscreen controller.

Maybe it is a difference in BIOS version, my T100TA is running the latest BIOS, what
is the output of:

cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date

?

Also do you perhaps have a microsd card inserted? (I'm trying to figure out the
different between our setups so that I can hopefully reproduce the issue myself).

> Regarding scripts, while I do still need a systemd hibernate script which removes the
> brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no longer need
> any script for suspend.

Ok, so you are not doing any rmmod-s on suspend, right?

Regards,

Hans

2019-05-09 18:13:37

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi Hans

On 5/9/19 2:50 AM, Hans de Goede wrote:

>
> Hi,
>
> On 09-05-19 06:24, Robert R. Howell wrote:
>> On 4/30/19 8:39 AM, Hans de Goede wrote:
>>>

>>>
>>> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
>>> on suspend/resume on my own T100TA and I could not reproduce this.
>>>
>>> Can you try without the BT keyboard paired and waking up from suspend using the
>>> tablet part's power-button ?
>>>
>>> Also do you still have the scripts to rmmod some modules before suspend ?
>>>
>>
>> The T100TA keyboard is actually a hardwired connection rather than Bluetooth but I
>> did physically disconnect the keyboard, and also unpaired all the actual Bluetooth
>> devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
>> When I suspend, then resume using the tablet power button, I still get the
>> i2c_dw_xfererror error during the resume. But whatever causes this error isn't fatal,
>> in the sense that after resume the sound and other i2c functions do still work OK.
>>
>> While I always get this i2c_dw_xfer error on resume from suspend or hibernation on the T100TA,
>> I also have a T100TAM and curiously, it NEVER shows that error -- although all the
>> other suspend and hibernate behavior seems similar. I'm not sure if the following could
>> be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen controller
>> while the T100TAM uses an i2c connected SIS0817 touchscreen controller. Other than that
>> the hardware seems almost identical.
>
> I've been testing on an actual T100TA, with the ATML1000 touchscreen controller.
>
> Maybe it is a difference in BIOS version, my T100TA is running the latest BIOS, what
> is the output of:
>
> cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date
>
On the T100TA which shows the i2c_dw_xfer error the above cat reports:
T100TA.307
05/09/2014

while the T100TA which does NOT show the i2c_dw_xfer error reports:
T100TAM.205
07/25/2014
>
> Also do you perhaps have a microsd card inserted? (I'm trying to figure out the
> different between our setups so that I can hopefully reproduce the issue myself).
>
I do have a microsd card inserted in both the T100TA and the T100TAM.
>
>> Regarding scripts, while I do still need a systemd hibernate script which removes the
>> brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no longer need
>> any script for suspend.
>
> Ok, so you are not doing any rmmod-s on suspend, right?
>
Correct -- I am NOT using a script and am not doing any explicit rmmod's on suspend, just on hibernate.
> Regards,
>
> Hans

All my previous tests were done using a 5.1.0-rc5, 5.1.0-rc3, or earlier kernel.
But I just compiled the released 5.1.0 kernel and the behavior has changed for the T100TA,
resulting in a different i2c error and a call trace. (I still continue to NOT see any
suspend/resume errors on the T100TAM.)

Note that for all the tests described in this message I'm applying your patch
regarding .poweroff_noirq and .restore_noirq, and I'm applying my own patch removing the
DPM_FLAG_SMART_SUSPEND flag. I haven't yet tried to explore varying those patches
for the 5.1.0 release as I did for the earlier rc's, as described in previous messages.

On the 5.1.0-rc5 and earlier kernels running on the T100TA I consistently get the
"i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
error on every resume from suspend, but I've never seen the errors I'm about
to report for the new release kernel. I've rebooted my T100TA using 5.1.0-rc5
several times to confirm that old behavior is still true.

With my newly compiled 5.1.0 release on the T100TA I now see a different i2c error on
the very first suspend/resume cycle after booting. However subsequent suspend/resume
cycles do not show any errors, neither the one seen on the first cycle, nor the
i2c_dw_xfer errors seen under 5.1.0-rc5. I've rebooted a number of times to see if the
behavior is consistent, and it always seems to follow the pattern of the error and
call trace on just the first suspend/resume cycle.

Obviously something has changed in the relevant code between 5.1.0-rc5 and 5.1.0 release.
Since the behavior it is consistent, if the following dmesg output isn't enough to sort
that out I can try building the intermediate rc6 and rc7, or run a more detailed bisect.
But because this new error results in a call trace, perhaps that will be enough to determine
what is going wrong.

Once again, let me know if I can do any further tests, or if you want a full copy of
the (earlier parts of the) dmesg output.

Bob

--- dmesg output from a T100TA running 5.1.0 (released) where the first suspend/resume cycle results ----
--- in an "i2c_designware 80860F41:00: Transfer while suspended" error but subsequent cycles work OK. ----

[ 35.818537] Bluetooth: RFCOMM ver 1.11
[ 54.556518] NET: Registered protocol family 38
[ 55.276584] input: MX Anywhere 2 Keyboard as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input24
[ 55.276825] input: MX Anywhere 2 Mouse as /devices/virtual/misc/uhid/0005:046D:B013.0005/input/input25
[ 55.277710] hid-generic 0005:046D:B013.0005: input,hidraw4: BLUETOOTH HID v0.07 Keyboard [MX Anywhere 2] on 74:D0:2B:DF:77:E9
[ 78.837456] PM: suspend entry (s2idle)
[ 78.837460] PM: Syncing filesystems ... done.
[ 79.771859] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 79.774610] OOM killer disabled.
[ 79.774611] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
[ 85.811298] ------------[ cut here ]------------
[ 85.811310] i2c_designware 80860F41:00: Transfer while suspended
[ 85.811382] WARNING: CPU: 1 PID: 7 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x95/0x277
[ 85.811387] Modules linked in: uhid algif_hash algif_skcipher af_alg rfcomm xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c af_packet ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_raw ip6table_security iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables cmac bnep msr snd_soc_sst_bytcr_rt5640 fuse iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp gpio_keys kvm_intel kvm brcmfmac irqbypass brcmutil crc32_pclmul cfg80211 crc32c_intel aesni_intel aes_x86_64 snd_intel_sst_acpi crypto_simd snd_intel_sst_core cryptd glue_helper snd_soc_sst_atom_hifi2_platform hci_uart asus_nb_wmi pcspkr snd_soc_acpi_intel_match snd_soc_rt5640 snd_soc_acpi joydev snd_soc_rl6231 btqca ak8975 snd_soc_core btrtl btbcm snd_hdmi_lpe_audio btintel snd_compress lpc_ich bluetooth ac97_bus snd_pcm
[ 85.811559] inv_mpu6050_i2c inv_mpu6050 tpm_tis snd_timer tpm_tis_core industrialio_triggered_buffer thermal snd kfifo_buf tpm ecdh_generic cm3218x i2c_mux rtc_cmos intel_int0002_vgpio soc_button_array button industrialio acpi_pad ac soundcore battery hid_asus asus_wmi rfkill usbhid hid_multitouch mmc_block i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops xhci_pci drm xhci_hcd wmi video i2c_hid sdhci_acpi sdhci mmc_core 8250_dw sg dm_multipath dm_mod dax efivarfs
[ 85.811674] CPU: 1 PID: 7 Comm: kworker/u8:0 Tainted: G W 5.1.0-rrh-t100-1 #1
[ 85.811680] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.307 05/09/2014
[ 85.811695] Workqueue: events_unbound async_run_entry_fn
[ 85.811712] RIP: 0010:i2c_dw_xfer+0x95/0x277
[ 85.811723] Code: 05 fa c1 c0 00 01 48 8b 6f 50 48 85 ed 75 04 48 8b 6f 10 e8 c9 13 f4 ff 48 89 ea 48 89 c6 48 c7 c7 a5 0b ec 81 e8 74 19 b8 ff <0f> 0b bd 94 ff ff ff e9 ae 01 00 00 48 89 6b 68 c7 43 18 00 00 00
[ 85.811731] RSP: 0000:ffffc9000007f778 EFLAGS: 00010282
[ 85.811741] RAX: 0000000000000000 RBX: ffff8880761f4818 RCX: 0000000000000007
[ 85.811748] RDX: 0000000000000000 RSI: ffff8880766954f0 RDI: ffff8880766954f0
[ 85.811755] RBP: ffff8880761b49e0 R08: 00000000000002c9 R09: 0000000000000001
[ 85.811761] R10: 0000000000000000 R11: 0000001cd45f1266 R12: 0000000000000002
[ 85.811768] R13: ffff8880761f48c8 R14: 0000000000000000 R15: 00000000fffca615
[ 85.811778] FS: 0000000000000000(0000) GS:ffff888076680000(0000) knlGS:0000000000000000
[ 85.811785] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 85.811792] CR2: 0000561e75e8bee6 CR3: 0000000067bfa000 CR4: 00000000001006e0
[ 85.811797] Call Trace:
[ 85.811820] __i2c_transfer+0x289/0x393
[ 85.811836] i2c_smbus_xfer_emulated+0x3f0/0x58b
[ 85.811851] ? __i2c_transfer+0x289/0x393
[ 85.811868] ? acpi_ut_trace+0x1d/0x59
[ 85.811882] ? __i2c_smbus_xfer+0x162/0x2e3
[ 85.811894] __i2c_smbus_xfer+0x162/0x2e3
[ 85.811910] i2c_smbus_xfer+0x51/0x79
[ 85.811924] i2c_smbus_read_byte_data+0x3b/0x5f
[ 85.811940] i2c_acpi_space_handler+0x127/0x3ef
[ 85.811957] ? up+0x28/0x35
[ 85.811976] ? acpi_ev_address_space_dispatch+0x2d9/0x37b
[ 85.811989] acpi_ev_address_space_dispatch+0x2d9/0x37b
[ 85.812003] ? kzalloc.constprop.8+0xa/0xa
[ 85.812018] acpi_ex_access_region+0x434/0x4d3
[ 85.812032] ? acpi_ut_create_buffer_object+0x75/0xf3
[ 85.812045] ? acpi_ut_trace+0x1d/0x59
[ 85.812059] acpi_ex_read_serial_bus+0x1a2/0x1f7
[ 85.812075] acpi_ex_read_data_from_field+0xef/0x32b
[ 85.812090] acpi_ex_resolve_node_to_value+0x394/0x4c9
[ 85.812105] acpi_ex_resolve_to_value+0x3b4/0x461
[ 85.812121] acpi_ds_evaluate_name_path+0xa8/0x161
[ 85.812136] ? acpi_db_single_step+0x15/0x251
[ 85.812150] acpi_ds_exec_end_op+0x118/0x74e
[ 85.812165] acpi_ps_parse_loop+0x7ca/0x88c
[ 85.812180] acpi_ps_parse_aml+0x1a6/0x542
[ 85.812195] acpi_ps_execute_method+0x1fc/0x2b8
[ 85.812211] acpi_ns_evaluate+0x33c/0x4cf
[ 85.812224] acpi_evaluate_object+0x1c6/0x389
[ 85.812243] acpi_dev_pm_explicit_set+0x51/0x75
[ 85.812258] acpi_device_set_power+0x1a8/0x257
[ 85.812276] acpi_pci_set_power_state+0x81/0xc3
[ 85.812294] pci_power_up+0x27/0x3c
[ 85.812310] pci_pm_default_resume_early+0x9/0x27
[ 85.812325] pci_pm_resume_noirq+0x40/0xa5
[ 85.812340] ? pci_pm_thaw_noirq+0x9a/0x9a
[ 85.812353] dpm_run_callback+0x5e/0xb6
[ 85.812369] ? pci_pm_thaw_noirq+0x9a/0x9a
[ 85.812381] device_resume_noirq+0x142/0x198
[ 85.812396] async_resume_noirq+0x14/0x38
[ 85.812410] async_run_entry_fn+0x68/0x126
[ 85.812427] process_one_work+0x19b/0x298
[ 85.812443] ? create_worker+0x16d/0x16d
[ 85.812455] worker_thread+0x18c/0x237
[ 85.812470] kthread+0xe6/0xeb
[ 85.812484] ? kthread_create_worker_on_cpu+0x61/0x61
[ 85.812498] ret_from_fork+0x35/0x40
[ 85.812514] ---[ end trace a3057465d1745352 ]---
[ 86.088989] ACPI: button: The lid device is not compliant to SW_LID.
[ 86.544221] OOM killer enabled.
[ 86.544258] Restarting tasks ... done.
[ 86.584199] PM: suspend exit
[ 94.039596] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 112.693492] PM: suspend entry (s2idle)
[ 112.693496] PM: Syncing filesystems ... done.
[ 114.076883] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 114.079637] OOM killer disabled.
[ 114.079639] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 115.681852] OOM killer enabled.
[ 115.681857] Restarting tasks ... done.
[ 115.714314] PM: suspend exit
[ 123.010931] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 138.483287] PM: suspend entry (s2idle)
[ 138.483292] PM: Syncing filesystems ... done.
[ 139.690315] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 139.693025] OOM killer disabled.
[ 139.693027] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
[ 144.796368] OOM killer enabled.
[ 144.796385] Restarting tasks ... done.
[ 144.831840] PM: suspend exit
[ 152.112181] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 162.780110] PM: suspend entry (s2idle)
[ 162.780115] PM: Syncing filesystems ... done.
[ 163.456370] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 163.458911] OOM killer disabled.
[ 163.458913] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 165.434909] OOM killer enabled.
[ 165.434917] Restarting tasks ... done.
[ 165.472053] PM: suspend exit
[ 172.702385] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

2019-05-13 09:57:37

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi Robert,

On 09-05-19 20:09, Robert R. Howell wrote:
> Hi Hans
>
> On 5/9/19 2:50 AM, Hans de Goede wrote:
>
>>
>> Hi,
>>
>> On 09-05-19 06:24, Robert R. Howell wrote:
>>> On 4/30/19 8:39 AM, Hans de Goede wrote:
>>>>
>
>>>>
>>>> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
>>>> on suspend/resume on my own T100TA and I could not reproduce this.
>>>>
>>>> Can you try without the BT keyboard paired and waking up from suspend using the
>>>> tablet part's power-button ?
>>>>
>>>> Also do you still have the scripts to rmmod some modules before suspend ?
>>>>
>>>
>>> The T100TA keyboard is actually a hardwired connection rather than Bluetooth but I
>>> did physically disconnect the keyboard, and also unpaired all the actual Bluetooth
>>> devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
>>> When I suspend, then resume using the tablet power button, I still get the
>>> i2c_dw_xfererror error during the resume. But whatever causes this error isn't fatal,
>>> in the sense that after resume the sound and other i2c functions do still work OK.
>>>
>>> While I always get this i2c_dw_xfer error on resume from suspend or hibernation on the T100TA,
>>> I also have a T100TAM and curiously, it NEVER shows that error -- although all the
>>> other suspend and hibernate behavior seems similar. I'm not sure if the following could
>>> be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen controller
>>> while the T100TAM uses an i2c connected SIS0817 touchscreen controller. Other than that
>>> the hardware seems almost identical.
>>
>> I've been testing on an actual T100TA, with the ATML1000 touchscreen controller.
>>
>> Maybe it is a difference in BIOS version, my T100TA is running the latest BIOS, what
>> is the output of:
>>
>> cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date
>>
> On the T100TA which shows the i2c_dw_xfer error the above cat reports:
> T100TA.307
> 05/09/2014
>
> while the T100TA which does NOT show the i2c_dw_xfer error reports:
> T100TAM.205
> 07/25/2014
>>
>> Also do you perhaps have a microsd card inserted? (I'm trying to figure out the
>> different between our setups so that I can hopefully reproduce the issue myself).
>>
> I do have a microsd card inserted in both the T100TA and the T100TAM.

Ah, ok I already suspected that and I think that is the difference between our
2 setups. I will try to reproduce the suspend/resume problem again with a microsd
card inserted and mounted.

>>> Regarding scripts, while I do still need a systemd hibernate script which removes the
>>> brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no longer need
>>> any script for suspend.
>>
>> Ok, so you are not doing any rmmod-s on suspend, right?
>>
> Correct -- I am NOT using a script and am not doing any explicit rmmod's on suspend, just on hibernate.
>> Regards,
>>
>> Hans
>
> All my previous tests were done using a 5.1.0-rc5, 5.1.0-rc3, or earlier kernel.
> But I just compiled the released 5.1.0 kernel and the behavior has changed for the T100TA,
> resulting in a different i2c error and a call trace. (I still continue to NOT see any
> suspend/resume errors on the T100TAM.)

This is expected we changed / improved the code generating the:
"i2c_designware 80860F41:00: Transfer while suspended"

Warning to include a trace, so that we know which code initiated the transfer,
which, as more or less expected, is the ACPI subsystem, like some power_on (_PS0)
or off (_PS3) method.

> Note that for all the tests described in this message I'm applying your patch
> regarding .poweroff_noirq and .restore_noirq, and I'm applying my own patch removing the
> DPM_FLAG_SMART_SUSPEND flag. I haven't yet tried to explore varying those patches
> for the 5.1.0 release as I did for the earlier rc's, as described in previous messages.

Hmm, for future testing please leave out the patch removing the DPM_FLAG_SMART_SUSPEND
flag. Usually when asking you to test something we assume you are using a pristine kernel.
What does that patch attempt to fix and what happens during suspend/resume without it ?

Regards,

Hans

2019-05-14 10:12:28

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi,

On 5/9/19 8:09 PM, Robert R. Howell wrote:
> Hi Hans
>
> On 5/9/19 2:50 AM, Hans de Goede wrote:
>
>>
>> Hi,
>>
>> On 09-05-19 06:24, Robert R. Howell wrote:
>>> On 4/30/19 8:39 AM, Hans de Goede wrote:
>>>>
>
>>>>
>>>> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
>>>> on suspend/resume on my own T100TA and I could not reproduce this.
>>>>
>>>> Can you try without the BT keyboard paired and waking up from suspend using the
>>>> tablet part's power-button ?
>>>>
>>>> Also do you still have the scripts to rmmod some modules before suspend ?
>>>>
>>>
>>> The T100TA keyboard is actually a hardwired connection rather than Bluetooth but I
>>> did physically disconnect the keyboard, and also unpaired all the actual Bluetooth
>>> devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
>>> When I suspend, then resume using the tablet power button, I still get the
>>> i2c_dw_xfererror error during the resume. But whatever causes this error isn't fatal,
>>> in the sense that after resume the sound and other i2c functions do still work OK.
>>>
>>> While I always get this i2c_dw_xfer error on resume from suspend or hibernation on the T100TA,
>>> I also have a T100TAM and curiously, it NEVER shows that error -- although all the
>>> other suspend and hibernate behavior seems similar. I'm not sure if the following could
>>> be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen controller
>>> while the T100TAM uses an i2c connected SIS0817 touchscreen controller. Other than that
>>> the hardware seems almost identical.
>>
>> I've been testing on an actual T100TA, with the ATML1000 touchscreen controller.
>>
>> Maybe it is a difference in BIOS version, my T100TA is running the latest BIOS, what
>> is the output of:
>>
>> cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date
>>
> On the T100TA which shows the i2c_dw_xfer error the above cat reports:
> T100TA.307
> 05/09/2014

My T100TA has version T100TA.314, date 08/13/2015

> while the T100TA which does NOT show the i2c_dw_xfer error reports:
> T100TAM.205
> 07/25/2014
>>
>> Also do you perhaps have a microsd card inserted? (I'm trying to figure out the
>> different between our setups so that I can hopefully reproduce the issue myself).
>>
> I do have a microsd card inserted in both the T100TA and the T100TAM.

Ok, so I tried reproducing the suspend/resume problem on my T100TA with a microsd
inserted and mounted and I still cannot reproduce the problem. So either you are
hitting a BIOS bug which since has been fixed, or the suspend/resume
problem is caused by you removing the DPM_FLAG_SMART_SUSPEND flag.

Regards,

Hans

2019-05-16 11:13:25

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>
> > On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
> >>
> >> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> >>>
> >>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
> >>>>
> >>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
> >>>>
> >>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >>>>>>>
> >>>>>>> Hmm, interesting so you have hibernation working on a T100TA
> >>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
> >>>>>>>
> >>>>
> >>>>
> >>>> I've managed to find a way around the i2c_designware timeout issues
> >>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> >>>> which was added in the 02e45646d53b commit.
> >>>>
> >>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
> >>>> to acpi_lpss.c, then apply the following patch of mine, removing
> >>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
> >>>> other patches as well but those are not related to the i2c-designware or
> >>>> acpi issues addressed here.)
> >>>>
> >>>> On a resume from hibernation I still see one error:
> >>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
> >>>> but I no longer get the i2c_designware timeouts, and audio does now work
> >>>> after the resume.
> >>>>
> >>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> >>>> hardware, but perhaps this will give you a clue as to what is going
> >>>> wrong with hibernate/resume on the T100TA's.
> >>>
> >>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> >>>
> >>
> >> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
> >> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
> >> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
> >> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
> >> then the timeouts go away.
> >
> > OK, thanks!
> >
> > Is non-hibernation system suspend affected too?
>
> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
> but without any changes to i2c-designware-platdrv.c, so the
> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
> are all set.
>
> Suspend does work OK, and after resume I do NOT get any of the crippling
> i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
> "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
> error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
> intermittently on these machines, but doesn't seem related to the other issues.
> I had one test run when it was absent but the rest of the messages were the
> same -- but then kept getting that unknown key error on all my later tries.
>
> I did notice the "2sidle" in the following rather than "shallow" or "deep". A
> cat of /sys/power/state shows "freeze mem disk" but a
> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and deep
> are not enabled for this system. I did check the input power (or really current)
> as it went into suspend and the micro-usb power input drops from about
> 0.5 amps to 0.05 amps. But clearly a lot of devices are still active, as movement
> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend. That presumably is
> why suspend doesn't trigger the same i2c_designware problems as hibernate.
>
> Let me know if I can do any other tests.

Can you please check if the appended patch makes the hibernate issue go away for you, without any other changes?

---
drivers/pci/pci-driver.c | 36 ++++++++++--------------------------
1 file changed, 10 insertions(+), 26 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===================================================================
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
}

/*
- * This used to be done in pci_pm_prepare() for all devices and some
- * drivers may depend on it, so do it here. Ideally, runtime-suspended
- * devices should not be touched during freeze/thaw transitions,
- * however.
+ * Resume all runtime-suspended devices before creating a snapshot
+ * image of system memory, because the restore kernel generally cannot
+ * be expected to always handle them consistently and pci_pm_restore()
+ * always leaves them as "active", so ensure that the state saved in the
+ * image will always be consistent with that.
*/
- if (!dev_pm_smart_suspend_and_suspended(dev)) {
- pm_runtime_resume(dev);
- pci_dev->state_saved = false;
- }
+ pm_runtime_resume(dev);
+ pci_dev->state_saved = false;

if (pm->freeze) {
int error;
@@ -992,9 +991,6 @@ static int pci_pm_freeze_noirq(struct de
struct pci_dev *pci_dev = to_pci_dev(dev);
struct device_driver *drv = dev->driver;

- if (dev_pm_smart_suspend_and_suspended(dev))
- return 0;
-
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_suspend_late(dev, PMSG_FREEZE);

@@ -1024,16 +1020,6 @@ static int pci_pm_thaw_noirq(struct devi
struct device_driver *drv = dev->driver;
int error = 0;

- /*
- * If the device is in runtime suspend, the code below may not work
- * correctly with it, so skip that code and make the PM core skip all of
- * the subsequent "thaw" callbacks for the device.
- */
- if (dev_pm_smart_suspend_and_suspended(dev)) {
- dev_pm_skip_next_resume_phases(dev);
- return 0;
- }
-
if (pcibios_pm_ops.thaw_noirq) {
error = pcibios_pm_ops.thaw_noirq(dev);
if (error)
@@ -1093,8 +1079,10 @@ static int pci_pm_poweroff(struct device

/* The reason to do that is the same as in pci_pm_suspend(). */
if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
- !pci_dev_keep_suspended(pci_dev))
+ !pci_dev_keep_suspended(pci_dev)) {
pm_runtime_resume(dev);
+ pci_dev->state_saved = false;
+ }

pci_dev->state_saved = false;
if (pm->poweroff) {
@@ -1168,10 +1156,6 @@ static int pci_pm_restore_noirq(struct d
struct device_driver *drv = dev->driver;
int error = 0;

- /* This is analogous to the pci_pm_resume_noirq() case. */
- if (dev_pm_smart_suspend_and_suspended(dev))
- pm_runtime_set_active(dev);
-
if (pcibios_pm_ops.restore_noirq) {
error = pcibios_pm_ops.restore_noirq(dev);
if (error)

2019-05-16 16:35:54

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi Hans

On 5/13/19 2:41 AM, Hans de Goede wrote:

>
> Hi Robert,
>
> On 09-05-19 20:09, Robert R. Howell wrote:
>> Hi Hans
>>
>> On 5/9/19 2:50 AM, Hans de Goede wrote:
>>
>>>
>>> Hi,
>>>
>>> On 09-05-19 06:24, Robert R. Howell wrote:
>>>> On 4/30/19 8:39 AM, Hans de Goede wrote:
>>>>>
>>
>>>>>
>>>>> I've just tried to reproduce the "Error i2c_dw_xfer call while suspended" error
>>>>> on suspend/resume on my own T100TA and I could not reproduce this.
>>>>>
>>>>> Can you try without the BT keyboard paired and waking up from suspend using the
>>>>> tablet part's power-button ?
>>>>>
>>>>> Also do you still have the scripts to rmmod some modules before suspend ?
>>>>>
>>>>
>>>> The T100TA keyboard is actually a hardwired connection rather than Bluetooth but I
>>>> did physically disconnect the keyboard, and also unpaired all the actual Bluetooth
>>>> devices (such as the mouse) and then powered down the T100TA bluetooth adapter.
>>>> When I suspend, then resume using the tablet power button, I still get the
>>>> i2c_dw_xfererror error during the resume. But whatever causes this error isn't fatal,
>>>> in the sense that after resume the sound and other i2c functions do still work OK.
>>>>
>>>> While I always get this i2c_dw_xfer error on resume from suspend or hibernation on the T100TA,
>>>> I also have a T100TAM and curiously, it NEVER shows that error -- although all the
>>>> other suspend and hibernate behavior seems similar. I'm not sure if the following could
>>>> be the difference, but the T100TA uses an i2c connected ATML1000 touchscreen controller
>>>> while the T100TAM uses an i2c connected SIS0817 touchscreen controller. Other than that
>>>> the hardware seems almost identical.
>>>
>>> I've been testing on an actual T100TA, with the ATML1000 touchscreen controller.
>>>
>>> Maybe it is a difference in BIOS version, my T100TA is running the latest BIOS, what
>>> is the output of:
>>>
>>> cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date
>>>
>> On the T100TA which shows the i2c_dw_xfer error the above cat reports:
>> T100TA.307
>> 05/09/2014
>>
>> while the T100TA which does NOT show the i2c_dw_xfer error reports:
>> T100TAM.205
>> 07/25/2014
>>>
>>> Also do you perhaps have a microsd card inserted? (I'm trying to figure out the
>>> different between our setups so that I can hopefully reproduce the issue myself).
>>>
>> I do have a microsd card inserted in both the T100TA and the T100TAM.
>
> Ah, ok I already suspected that and I think that is the difference between our
> 2 setups. I will try to reproduce the suspend/resume problem again with a microsd
> card inserted and mounted.
>
>>>> Regarding scripts, while I do still need a systemd hibernate script which removes the
>>>> brcmfmac and the hci_uart (bluetooth related) drivers, I've found that I no longer need
>>>> any script for suspend.
>>>
>>> Ok, so you are not doing any rmmod-s on suspend, right?
>>>
>> Correct -- I am NOT using a script and am not doing any explicit rmmod's on suspend, just on hibernate.
>>> Regards,
>>>
>>> Hans
>>
>> All my previous tests were done using a 5.1.0-rc5, 5.1.0-rc3, or earlier kernel.
>> But I just compiled the released 5.1.0 kernel and the behavior has changed for the T100TA,
>> resulting in a different i2c error and a call trace. (I still continue to NOT see any
>> suspend/resume errors on the T100TAM.)
>
> This is expected we changed / improved the code generating the:
> "i2c_designware 80860F41:00: Transfer while suspended"
>
> Warning to include a trace, so that we know which code initiated the transfer,
> which, as more or less expected, is the ACPI subsystem, like some power_on (_PS0)
> or off (_PS3) method.
>
>> Note that for all the tests described in this message I'm applying your patch
>> regarding .poweroff_noirq and .restore_noirq, and I'm applying my own patch removing the
>> DPM_FLAG_SMART_SUSPEND flag. I haven't yet tried to explore varying those patches
>> for the 5.1.0 release as I did for the earlier rc's, as described in previous messages.
>
> Hmm, for future testing please leave out the patch removing the DPM_FLAG_SMART_SUSPEND
> flag. Usually when asking you to test something we assume you are using a pristine kernel.
> What does that patch attempt to fix and what happens during suspend/resume without it ?
>
Removing the DPM_FLAG_SMART_SUSPEND fixes an i2c_designware timeout on the T100TA and TAM systems
when resuming from hibernation. That's detailed in an earlier message of mine in this thread, and also
is quoted more completely in a reply I'm about to send to Rafael. From a usability perspective the
resume-from-hibernate i2c_designware timeout errors were more serious, since they disabled sound
till I rebooted, while the suspend/resume "Transfer while suspended" error was just a minor
annoyance in the log, since it didn't SEEM to cause subsequent problems.

If the patch that Rafael just provided doesn't fix these issues (I'm traveling again so it will be a
couple days before I'm home and can test it) I'll try some further experiments and I might have a
T100TA where I can install a more recent BIOS and see what affect that has.

> Regards,
>
> Hans
>

Thanks again for testing this on your machine.

Bob Howell

2019-05-16 20:03:16

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi Rafael

On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:

> On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
>> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>>
>>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
>>>>
>>>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>>>>>
>>>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
>>>>>>
>>>>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>>>>>
>>>>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>>>>>>>
>>>>>>>>> Hmm, interesting so you have hibernation working on a T100TA
>>>>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>> I've managed to find a way around the i2c_designware timeout issues
>>>>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>>>>>> which was added in the 02e45646d53b commit.
>>>>>>
>>>>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
>>>>>> to acpi_lpss.c, then apply the following patch of mine, removing
>>>>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
>>>>>> other patches as well but those are not related to the i2c-designware or
>>>>>> acpi issues addressed here.)
>>>>>>
>>>>>> On a resume from hibernation I still see one error:
>>>>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>>>>>> but I no longer get the i2c_designware timeouts, and audio does now work
>>>>>> after the resume.
>>>>>>
>>>>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>>>>>> hardware, but perhaps this will give you a clue as to what is going
>>>>>> wrong with hibernate/resume on the T100TA's.
>>>>>
>>>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>>>>>
>>>>
>>>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>>>> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
>>>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>>>> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>>>> then the timeouts go away.
>>>
>>> OK, thanks!
>>>
>>> Is non-hibernation system suspend affected too?
>>
>> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
>> but without any changes to i2c-designware-platdrv.c, so the
>> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
>> are all set.
>>
>> Suspend does work OK, and after resume I do NOT get any of the crippling
>> i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
>> "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
>> error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
>> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
>> intermittently on these machines, but doesn't seem related to the other issues.
>> I had one test run when it was absent but the rest of the messages were the
>> same -- but then kept getting that unknown key error on all my later tries.
>>
>> I did notice the "2sidle" in the following rather than "shallow" or "deep". A
>> cat of /sys/power/state shows "freeze mem disk" but a
>> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and deep
>> are not enabled for this system. I did check the input power (or really current)
>> as it went into suspend and the micro-usb power input drops from about
>> 0.5 amps to 0.05 amps. But clearly a lot of devices are still active, as movement
>> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend. That presumably is
>> why suspend doesn't trigger the same i2c_designware problems as hibernate.
>>
>> Let me know if I can do any other tests.
>
> Can you please check if the appended patch makes the hibernate issue go away for you, without any other changes?
>
> ---
> drivers/pci/pci-driver.c | 36 ++++++++++--------------------------
> 1 file changed, 10 insertions(+), 26 deletions(-)
>
> Index: linux-pm/drivers/pci/pci-driver.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci-driver.c
> +++ linux-pm/drivers/pci/pci-driver.c
> @@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
> }
>
> /*
> - * This used to be done in pci_pm_prepare() for all devices and some
> - * drivers may depend on it, so do it here. Ideally, runtime-suspended
> - * devices should not be touched during freeze/thaw transitions,
> - * however.
> + * Resume all runtime-suspended devices before creating a snapshot
> + * image of system memory, because the restore kernel generally cannot
> + * be expected to always handle them consistently and pci_pm_restore()
> + * always leaves them as "active", so ensure that the state saved in the
> + * image will always be consistent with that.
> */
> - if (!dev_pm_smart_suspend_and_suspended(dev)) {
> - pm_runtime_resume(dev);
> - pci_dev->state_saved = false;
> - }
> + pm_runtime_resume(dev);
> + pci_dev->state_saved = false;
>
> if (pm->freeze) {
> int error;
> @@ -992,9 +991,6 @@ static int pci_pm_freeze_noirq(struct de
> struct pci_dev *pci_dev = to_pci_dev(dev);
> struct device_driver *drv = dev->driver;
>
> - if (dev_pm_smart_suspend_and_suspended(dev))
> - return 0;
> -
> if (pci_has_legacy_pm_support(pci_dev))
> return pci_legacy_suspend_late(dev, PMSG_FREEZE);
>
> @@ -1024,16 +1020,6 @@ static int pci_pm_thaw_noirq(struct devi
> struct device_driver *drv = dev->driver;
> int error = 0;
>
> - /*
> - * If the device is in runtime suspend, the code below may not work
> - * correctly with it, so skip that code and make the PM core skip all of
> - * the subsequent "thaw" callbacks for the device.
> - */
> - if (dev_pm_smart_suspend_and_suspended(dev)) {
> - dev_pm_skip_next_resume_phases(dev);
> - return 0;
> - }
> -
> if (pcibios_pm_ops.thaw_noirq) {
> error = pcibios_pm_ops.thaw_noirq(dev);
> if (error)
> @@ -1093,8 +1079,10 @@ static int pci_pm_poweroff(struct device
>
> /* The reason to do that is the same as in pci_pm_suspend(). */
> if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
> - !pci_dev_keep_suspended(pci_dev))
> + !pci_dev_keep_suspended(pci_dev)) {
> pm_runtime_resume(dev);
> + pci_dev->state_saved = false;
> + }
>
> pci_dev->state_saved = false;
> if (pm->poweroff) {
> @@ -1168,10 +1156,6 @@ static int pci_pm_restore_noirq(struct d
> struct device_driver *drv = dev->driver;
> int error = 0;
>
> - /* This is analogous to the pci_pm_resume_noirq() case. */
> - if (dev_pm_smart_suspend_and_suspended(dev))
> - pm_runtime_set_active(dev);
> -
> if (pcibios_pm_ops.restore_noirq) {
> error = pcibios_pm_ops.restore_noirq(dev);
> if (error)
>
>
>

Thanks for the patch. I'm traveling right now so I'm away from the machines I need to test this,
but I'll be back home by the end of the week and will test the patch then.

Bob Howell

2019-05-16 23:01:31

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On Thursday, May 16, 2019 6:35:40 PM CEST Robert R. Howell wrote:
> Hi Rafael
>
>
> On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:
>
> > On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
> >> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
> >>
> >>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
> >>>>
> >>>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> >>>>>
> >>>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
> >>>>>>
> >>>>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
> >>>>>>
> >>>>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >>>>>>>>>
> >>>>>>>>> Hmm, interesting so you have hibernation working on a T100TA
> >>>>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I've managed to find a way around the i2c_designware timeout issues
> >>>>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> >>>>>> which was added in the 02e45646d53b commit.
> >>>>>>
> >>>>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
> >>>>>> to acpi_lpss.c, then apply the following patch of mine, removing
> >>>>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
> >>>>>> other patches as well but those are not related to the i2c-designware or
> >>>>>> acpi issues addressed here.)
> >>>>>>
> >>>>>> On a resume from hibernation I still see one error:
> >>>>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
> >>>>>> but I no longer get the i2c_designware timeouts, and audio does now work
> >>>>>> after the resume.
> >>>>>>
> >>>>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> >>>>>> hardware, but perhaps this will give you a clue as to what is going
> >>>>>> wrong with hibernate/resume on the T100TA's.
> >>>>>
> >>>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> >>>>>
> >>>>
> >>>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
> >>>> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
> >>>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
> >>>> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
> >>>> then the timeouts go away.
> >>>
> >>> OK, thanks!
> >>>
> >>> Is non-hibernation system suspend affected too?
> >>
> >> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
> >> but without any changes to i2c-designware-platdrv.c, so the
> >> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
> >> are all set.
> >>
> >> Suspend does work OK, and after resume I do NOT get any of the crippling
> >> i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
> >> "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
> >> error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
> >> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
> >> intermittently on these machines, but doesn't seem related to the other issues.
> >> I had one test run when it was absent but the rest of the messages were the
> >> same -- but then kept getting that unknown key error on all my later tries.
> >>
> >> I did notice the "2sidle" in the following rather than "shallow" or "deep". A
> >> cat of /sys/power/state shows "freeze mem disk" but a
> >> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and deep
> >> are not enabled for this system. I did check the input power (or really current)
> >> as it went into suspend and the micro-usb power input drops from about
> >> 0.5 amps to 0.05 amps. But clearly a lot of devices are still active, as movement
> >> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend. That presumably is
> >> why suspend doesn't trigger the same i2c_designware problems as hibernate.
> >>
> >> Let me know if I can do any other tests.
> >
> > Can you please check if the appended patch makes the hibernate issue go away for you, without any other changes?
> >
> > ---
> > drivers/pci/pci-driver.c | 36 ++++++++++--------------------------
> > 1 file changed, 10 insertions(+), 26 deletions(-)
> >
> > Index: linux-pm/drivers/pci/pci-driver.c
> > ===================================================================
> > --- linux-pm.orig/drivers/pci/pci-driver.c
> > +++ linux-pm/drivers/pci/pci-driver.c
> > @@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
> > }
> >
> > /*
> > - * This used to be done in pci_pm_prepare() for all devices and some
> > - * drivers may depend on it, so do it here. Ideally, runtime-suspended
> > - * devices should not be touched during freeze/thaw transitions,
> > - * however.
> > + * Resume all runtime-suspended devices before creating a snapshot
> > + * image of system memory, because the restore kernel generally cannot
> > + * be expected to always handle them consistently and pci_pm_restore()
> > + * always leaves them as "active", so ensure that the state saved in the
> > + * image will always be consistent with that.
> > */
> > - if (!dev_pm_smart_suspend_and_suspended(dev)) {
> > - pm_runtime_resume(dev);
> > - pci_dev->state_saved = false;
> > - }
> > + pm_runtime_resume(dev);
> > + pci_dev->state_saved = false;
> >
> > if (pm->freeze) {
> > int error;
> > @@ -992,9 +991,6 @@ static int pci_pm_freeze_noirq(struct de
> > struct pci_dev *pci_dev = to_pci_dev(dev);
> > struct device_driver *drv = dev->driver;
> >
> > - if (dev_pm_smart_suspend_and_suspended(dev))
> > - return 0;
> > -
> > if (pci_has_legacy_pm_support(pci_dev))
> > return pci_legacy_suspend_late(dev, PMSG_FREEZE);
> >
> > @@ -1024,16 +1020,6 @@ static int pci_pm_thaw_noirq(struct devi
> > struct device_driver *drv = dev->driver;
> > int error = 0;
> >
> > - /*
> > - * If the device is in runtime suspend, the code below may not work
> > - * correctly with it, so skip that code and make the PM core skip all of
> > - * the subsequent "thaw" callbacks for the device.
> > - */
> > - if (dev_pm_smart_suspend_and_suspended(dev)) {
> > - dev_pm_skip_next_resume_phases(dev);
> > - return 0;
> > - }
> > -
> > if (pcibios_pm_ops.thaw_noirq) {
> > error = pcibios_pm_ops.thaw_noirq(dev);
> > if (error)
> > @@ -1093,8 +1079,10 @@ static int pci_pm_poweroff(struct device
> >
> > /* The reason to do that is the same as in pci_pm_suspend(). */
> > if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
> > - !pci_dev_keep_suspended(pci_dev))
> > + !pci_dev_keep_suspended(pci_dev)) {
> > pm_runtime_resume(dev);
> > + pci_dev->state_saved = false;
> > + }
> >
> > pci_dev->state_saved = false;
> > if (pm->poweroff) {
> > @@ -1168,10 +1156,6 @@ static int pci_pm_restore_noirq(struct d
> > struct device_driver *drv = dev->driver;
> > int error = 0;
> >
> > - /* This is analogous to the pci_pm_resume_noirq() case. */
> > - if (dev_pm_smart_suspend_and_suspended(dev))
> > - pm_runtime_set_active(dev);
> > -
> > if (pcibios_pm_ops.restore_noirq) {
> > error = pcibios_pm_ops.restore_noirq(dev);
> > if (error)
> >
> >
> >
>
> Thanks for the patch. I'm traveling right now so I'm away from the machines I need to test this,
> but I'll be back home by the end of the week and will test the patch then.

Thanks!

It would be better to test the one appended below instead, though, so please do that.

---
drivers/acpi/device_pm.c | 9 +--------
drivers/pci/pci-driver.c | 12 ++----------
2 files changed, 3 insertions(+), 18 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===================================================================
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -1119,14 +1119,7 @@ EXPORT_SYMBOL_GPL(acpi_subsys_resume_ear
*/
int acpi_subsys_freeze(struct device *dev)
{
- /*
- * This used to be done in acpi_subsys_prepare() for all devices and
- * some drivers may depend on it, so do it here. Ideally, however,
- * runtime-suspended devices should not be touched during freeze/thaw
- * transitions.
- */
- if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND))
- pm_runtime_resume(dev);
+ pm_runtime_resume(dev);

return pm_generic_freeze(dev);
}
Index: linux-pm/drivers/pci/pci-driver.c
===================================================================
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -956,16 +956,8 @@ static int pci_pm_freeze(struct device *
return 0;
}

- /*
- * This used to be done in pci_pm_prepare() for all devices and some
- * drivers may depend on it, so do it here. Ideally, runtime-suspended
- * devices should not be touched during freeze/thaw transitions,
- * however.
- */
- if (!dev_pm_smart_suspend_and_suspended(dev)) {
- pm_runtime_resume(dev);
- pci_dev->state_saved = false;
- }
+ pm_runtime_resume(dev);
+ pci_dev->state_saved = false;

if (pm->freeze) {
int error;

2019-05-25 05:35:48

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:
>
> On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
>> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
>>
>>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
>>>>
>>>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
>>>>>
>>>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
>>>>>>
>>>>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
>>>>>>
>>>>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
>>>>>>>>>
>>>>>>>>> Hmm, interesting so you have hibernation working on a T100TA
>>>>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>> I've managed to find a way around the i2c_designware timeout issues
>>>>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
>>>>>> which was added in the 02e45646d53b commit.
>>>>>>
>>>>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
>>>>>> to acpi_lpss.c, then apply the following patch of mine, removing
>>>>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
>>>>>> other patches as well but those are not related to the i2c-designware or
>>>>>> acpi issues addressed here.)
>>>>>>
>>>>>> On a resume from hibernation I still see one error:
>>>>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
>>>>>> but I no longer get the i2c_designware timeouts, and audio does now work
>>>>>> after the resume.
>>>>>>
>>>>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
>>>>>> hardware, but perhaps this will give you a clue as to what is going
>>>>>> wrong with hibernate/resume on the T100TA's.
>>>>>
>>>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
>>>>>
>>>>
>>>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
>>>> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
>>>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
>>>> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
>>>> then the timeouts go away.
>>>
>>> OK, thanks!
>>>
>>> Is non-hibernation system suspend affected too?
>>
>> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
>> but without any changes to i2c-designware-platdrv.c, so the
>> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
>> are all set.
>>
>> Suspend does work OK, and after resume I do NOT get any of the crippling
>> i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
>> "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
>> error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
>> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
>> intermittently on these machines, but doesn't seem related to the other issues.
>> I had one test run when it was absent but the rest of the messages were the
>> same -- but then kept getting that unknown key error on all my later tries.
>>
>> I did notice the "2sidle" in the following rather than "shallow" or "deep". A
>> cat of /sys/power/state shows "freeze mem disk" but a
>> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and deep
>> are not enabled for this system. I did check the input power (or really current)
>> as it went into suspend and the micro-usb power input drops from about
>> 0.5 amps to 0.05 amps. But clearly a lot of devices are still active, as movement
>> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend. That presumably is
>> why suspend doesn't trigger the same i2c_designware problems as hibernate.
>>
>> Let me know if I can do any other tests.
>
> Can you please check if the appended patch makes the hibernate issue go away for you, without any other changes?
>
> ---
> drivers/pci/pci-driver.c | 36 ++++++++++--------------------------
> 1 file changed, 10 insertions(+), 26 deletions(-)
>
> Index: linux-pm/drivers/pci/pci-driver.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci-driver.c
> +++ linux-pm/drivers/pci/pci-driver.c
> @@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
> }
>
> /*
> - * This used to be done in pci_pm_prepare() for all devices and some
> - * drivers may depend on it, so do it here. Ideally, runtime-suspended
> - * devices should not be touched during freeze/thaw transitions,
> - * however.
> + * Resume all runtime-suspended devices before creating a snapshot
> + * image of system memory, because the restore kernel generally cannot
> + * be expected to always handle them consistently and pci_pm_restore()
> + * always leaves them as "active", so ensure that the state saved in the
> + * image will always be consistent with that.
> */
> - if (!dev_pm_smart_suspend_and_suspended(dev)) {
> - pm_runtime_resume(dev);
> - pci_dev->state_saved = false;
> - }
> + pm_runtime_resume(dev);
> + pci_dev->state_saved = false;
>
> if (pm->freeze) {
> int error;
> @@ -992,9 +991,6 @@ static int pci_pm_freeze_noirq(struct de
> struct pci_dev *pci_dev = to_pci_dev(dev);
> struct device_driver *drv = dev->driver;
>
> - if (dev_pm_smart_suspend_and_suspended(dev))
> - return 0;
> -
> if (pci_has_legacy_pm_support(pci_dev))
> return pci_legacy_suspend_late(dev, PMSG_FREEZE);
>
> @@ -1024,16 +1020,6 @@ static int pci_pm_thaw_noirq(struct devi
> struct device_driver *drv = dev->driver;
> int error = 0;
>
> - /*
> - * If the device is in runtime suspend, the code below may not work
> - * correctly with it, so skip that code and make the PM core skip all of
> - * the subsequent "thaw" callbacks for the device.
> - */
> - if (dev_pm_smart_suspend_and_suspended(dev)) {
> - dev_pm_skip_next_resume_phases(dev);
> - return 0;
> - }
> -
> if (pcibios_pm_ops.thaw_noirq) {
> error = pcibios_pm_ops.thaw_noirq(dev);
> if (error)
> @@ -1093,8 +1079,10 @@ static int pci_pm_poweroff(struct device
>
> /* The reason to do that is the same as in pci_pm_suspend(). */
> if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
> - !pci_dev_keep_suspended(pci_dev))
> + !pci_dev_keep_suspended(pci_dev)) {
> pm_runtime_resume(dev);
> + pci_dev->state_saved = false;
> + }
>
> pci_dev->state_saved = false;
> if (pm->poweroff) {
> @@ -1168,10 +1156,6 @@ static int pci_pm_restore_noirq(struct d
> struct device_driver *drv = dev->driver;
> int error = 0;
>
> - /* This is analogous to the pci_pm_resume_noirq() case. */
> - if (dev_pm_smart_suspend_and_suspended(dev))
> - pm_runtime_set_active(dev);
> -
> if (pcibios_pm_ops.restore_noirq) {
> error = pcibios_pm_ops.restore_noirq(dev);
> if (error)
>
>
>

I've finally managed to complete a reasonable set of tests on my T100TA using your
2nd patch from above, and on a 5.1.4 based kernel with ONLY this patch applied I can
successfully suspend and hibernate the system. On resume the i2c devices (in particular the sound)
do still work OK. On the first resume from suspend or hibernate I DO still see
the "i2c_designware 80860F41:00: Transfer while suspended" error, followed by a
stack trace. However as before that error doesn't seem to cause any permanent problems.
and with your patch applied I do NOT get the subsequent i2c timeout errors
that prevent further use of the sound system. I don't see any other reported errors.
As usual I need to have a systemd script which removes the brcmfmac and hci_uart drivers
before hibernate, then installs them on resume, or those drivers fail to work after resume.

I had initially tried testing your patch with the 5.1.0 kernel that I had been
using for testing a few weeks ago, and also the just released 5.2-rc1 kernel.
I think your patch is also fixing the i2c timeout errors with those, but with both of those
other kernels I have a lot of other issues which have confused the results. I've been trying
to sort out exactly what causes or avoids those issues over the last several days.
However that has turned into enough of a can of worms that unless you really want
to know those details, I'll avoid that "noise" here except a VERY brief summary.

With 5.1.0 and ONLY your patch, resume from hibernate does seem to work, and I DO NOT
get i2c_timeout errors, but I do see a number of errors and stack traces reported
from other i2c devices such as the ATML1000 touchscreen controller. However the devices
all do seem to work once the resume is completed. The just released 5.2-rc1 kernel
seems to have introduced problems with at least one other device, brcmfmac, with
or without your patch. I have to blacklist it or the system hangs on either suspend
or hibernate. (And working wifi never did come up even on the initial boot.)
But with brcmfmac blacklisted your patch seems to fix the i2c_designware SOUND timeouts.

Let me know if I can do any further testing.

Bob Howell

2019-06-24 10:24:59

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On Saturday, May 25, 2019 7:31:20 AM CEST Robert R. Howell wrote:
> On 5/16/19 5:11 AM, Rafael J. Wysocki wrote:
> >
> > On Thursday, April 25, 2019 6:38:34 PM CEST Robert R. Howell wrote:
> >> On 4/24/19 1:20 AM, Rafael J. Wysocki wrote:
> >>
> >>> On Tue, Apr 23, 2019 at 10:03 PM Robert R. Howell <[email protected]> wrote:
> >>>>
> >>>> On 4/23/19 2:07 AM, Rafael J. Wysocki wrote:
> >>>>>
> >>>>> On Sat, Apr 20, 2019 at 12:44 AM Robert R. Howell <[email protected]> wrote:
> >>>>>>
> >>>>>> On 4/18/19 5:42 AM, Hans de Goede wrote:
> >>>>>>
> >>>>>>>> On 4/8/19 2:16 AM, Hans de Goede wrote:>
> >>>>>>>>>
> >>>>>>>>> Hmm, interesting so you have hibernation working on a T100TA
> >>>>>>>>> (with 5.0 + 02e45646d53b reverted), right ?
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I've managed to find a way around the i2c_designware timeout issues
> >>>>>> on the T100TA's. The key is to NOT set DPM_FLAG_SMART_SUSPEND,
> >>>>>> which was added in the 02e45646d53b commit.
> >>>>>>
> >>>>>> To test that I've started with a 5.1-rc5 kernel, applied your recent patch
> >>>>>> to acpi_lpss.c, then apply the following patch of mine, removing
> >>>>>> DPM_FLAG_SMART_SUSPEND. (For the T100 hardware I need to apply some
> >>>>>> other patches as well but those are not related to the i2c-designware or
> >>>>>> acpi issues addressed here.)
> >>>>>>
> >>>>>> On a resume from hibernation I still see one error:
> >>>>>> "i2c_designware 80860F41:00: Error i2c_dw_xfer called while suspended"
> >>>>>> but I no longer get the i2c_designware timeouts, and audio does now work
> >>>>>> after the resume.
> >>>>>>
> >>>>>> Removing DPM_FLAG_SMART_SUSPEND may not be what you want for other
> >>>>>> hardware, but perhaps this will give you a clue as to what is going
> >>>>>> wrong with hibernate/resume on the T100TA's.
> >>>>>
> >>>>> What if you drop DPM_FLAG_LEAVE_SUSPENDED alone instead?
> >>>>>
> >>>>
> >>>> I did try dropping just DPM_FLAG_LEAVE_SUSPENDED, dropping just
> >>>> DPM_FLAG_SMART_SUSPEND, and dropping both flags. When I just drop
> >>>> DPM_FLAG_LEAVE_SUSPENDED I still get the i2c_designware timeouts
> >>>> after the resume. If I drop just DPM_FLAG_SMART_SUSPEND or drop both,
> >>>> then the timeouts go away.
> >>>
> >>> OK, thanks!
> >>>
> >>> Is non-hibernation system suspend affected too?
> >>
> >> I just ran some tests on a T100TA, using the 5.1-rc5 code with Hans' patch applied
> >> but without any changes to i2c-designware-platdrv.c, so the
> >> DPM_FLAG_SMART_PREPARE, DPM_FLAG_SMART_SUSPEND, and DPM_FLAG_LEAVE_SUSPENDED flags
> >> are all set.
> >>
> >> Suspend does work OK, and after resume I do NOT get any of the crippling
> >> i2c_designware timeout errors which cause sound to fail after hibernate. I DO see one
> >> "i2c_designware 80860F41:00: Error i2c_dw_xfer call while suspended"
> >> error on resume, just as I do on hibernate. I've attached a portion of dmesg below.
> >> The "asus_wmi: Unknown key 79 pressed" error is a glitch which occurs
> >> intermittently on these machines, but doesn't seem related to the other issues.
> >> I had one test run when it was absent but the rest of the messages were the
> >> same -- but then kept getting that unknown key error on all my later tries.
> >>
> >> I did notice the "2sidle" in the following rather than "shallow" or "deep". A
> >> cat of /sys/power/state shows "freeze mem disk" but a
> >> cat of /sys/power/mem_sleep" shows only "[s2idle] so it looks like shallow and deep
> >> are not enabled for this system. I did check the input power (or really current)
> >> as it went into suspend and the micro-usb power input drops from about
> >> 0.5 amps to 0.05 amps. But clearly a lot of devices are still active, as movement
> >> of a bluetooth mouse (the MX Anywhere 2) will wake it from suspend. That presumably is
> >> why suspend doesn't trigger the same i2c_designware problems as hibernate.
> >>
> >> Let me know if I can do any other tests.
> >
> > Can you please check if the appended patch makes the hibernate issue go away for you, without any other changes?
> >
> > ---
> > drivers/pci/pci-driver.c | 36 ++++++++++--------------------------
> > 1 file changed, 10 insertions(+), 26 deletions(-)
> >
> > Index: linux-pm/drivers/pci/pci-driver.c
> > ===================================================================
> > --- linux-pm.orig/drivers/pci/pci-driver.c
> > +++ linux-pm/drivers/pci/pci-driver.c
> > @@ -957,15 +957,14 @@ static int pci_pm_freeze(struct device *
> > }
> >
> > /*
> > - * This used to be done in pci_pm_prepare() for all devices and some
> > - * drivers may depend on it, so do it here. Ideally, runtime-suspended
> > - * devices should not be touched during freeze/thaw transitions,
> > - * however.
> > + * Resume all runtime-suspended devices before creating a snapshot
> > + * image of system memory, because the restore kernel generally cannot
> > + * be expected to always handle them consistently and pci_pm_restore()
> > + * always leaves them as "active", so ensure that the state saved in the
> > + * image will always be consistent with that.
> > */
> > - if (!dev_pm_smart_suspend_and_suspended(dev)) {
> > - pm_runtime_resume(dev);
> > - pci_dev->state_saved = false;
> > - }
> > + pm_runtime_resume(dev);
> > + pci_dev->state_saved = false;
> >
> > if (pm->freeze) {
> > int error;
> > @@ -992,9 +991,6 @@ static int pci_pm_freeze_noirq(struct de
> > struct pci_dev *pci_dev = to_pci_dev(dev);
> > struct device_driver *drv = dev->driver;
> >
> > - if (dev_pm_smart_suspend_and_suspended(dev))
> > - return 0;
> > -
> > if (pci_has_legacy_pm_support(pci_dev))
> > return pci_legacy_suspend_late(dev, PMSG_FREEZE);
> >
> > @@ -1024,16 +1020,6 @@ static int pci_pm_thaw_noirq(struct devi
> > struct device_driver *drv = dev->driver;
> > int error = 0;
> >
> > - /*
> > - * If the device is in runtime suspend, the code below may not work
> > - * correctly with it, so skip that code and make the PM core skip all of
> > - * the subsequent "thaw" callbacks for the device.
> > - */
> > - if (dev_pm_smart_suspend_and_suspended(dev)) {
> > - dev_pm_skip_next_resume_phases(dev);
> > - return 0;
> > - }
> > -
> > if (pcibios_pm_ops.thaw_noirq) {
> > error = pcibios_pm_ops.thaw_noirq(dev);
> > if (error)
> > @@ -1093,8 +1079,10 @@ static int pci_pm_poweroff(struct device
> >
> > /* The reason to do that is the same as in pci_pm_suspend(). */
> > if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
> > - !pci_dev_keep_suspended(pci_dev))
> > + !pci_dev_keep_suspended(pci_dev)) {
> > pm_runtime_resume(dev);
> > + pci_dev->state_saved = false;
> > + }
> >
> > pci_dev->state_saved = false;
> > if (pm->poweroff) {
> > @@ -1168,10 +1156,6 @@ static int pci_pm_restore_noirq(struct d
> > struct device_driver *drv = dev->driver;
> > int error = 0;
> >
> > - /* This is analogous to the pci_pm_resume_noirq() case. */
> > - if (dev_pm_smart_suspend_and_suspended(dev))
> > - pm_runtime_set_active(dev);
> > -
> > if (pcibios_pm_ops.restore_noirq) {
> > error = pcibios_pm_ops.restore_noirq(dev);
> > if (error)
> >
> >
> >
>
> I've finally managed to complete a reasonable set of tests on my T100TA using your
> 2nd patch from above, and on a 5.1.4 based kernel with ONLY this patch applied I can
> successfully suspend and hibernate the system.

Sorry for the long delay.

I haven't dropped this issue on the floor, I hope that you are still able to follow up here.

Can you please test the appended patch instead of the previous one?

I have found some inconsistencies in the handling of hibernation in the ACPI PM domain
and the LPSS driver that should be covered by this patch.

---
drivers/acpi/acpi_lpss.c | 63 +++++++++++++++++++++++++++++++++++------------
drivers/acpi/device_pm.c | 30 ++++++++++++++++++++--
include/linux/acpi.h | 4 ++
3 files changed, 79 insertions(+), 18 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===================================================================
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -1171,6 +1171,32 @@ int acpi_subsys_thaw_noirq(struct device
return pm_generic_thaw_noirq(dev);
}
EXPORT_SYMBOL_GPL(acpi_subsys_thaw_noirq);
+
+/**
+ * acpi_subsys_restore_noirq - Run the device driver's "noirq" restore callback.
+ * @dev: Device to handle.
+ */
+int acpi_subsys_restore_noirq(struct device *dev)
+{
+ /* This is analogous to what acpi_subsys_resune_noirq() does. */
+ if (dev_pm_smart_suspend_and_suspended(dev))
+ pm_runtime_set_active(dev);
+
+ return pm_generic_restore_noirq(dev);
+}
+EXPORT_SYMBOL_GPL(acpi_subsys_restore_noirq);
+
+/**
+ * acpi_subsys_restore_early - Restore device using ACPI.
+ * @dev: Device to restore.
+ */
+int acpi_subsys_restore_early(struct device *dev)
+{
+ int ret = acpi_dev_resume(dev);
+ return ret ? ret : pm_generic_restore_early(dev);
+}
+EXPORT_SYMBOL_GPL(acpi_subsys_restore_early);
+
#endif /* CONFIG_PM_SLEEP */

static struct dev_pm_domain acpi_general_pm_domain = {
@@ -1192,8 +1218,8 @@ static struct dev_pm_domain acpi_general
.poweroff = acpi_subsys_suspend,
.poweroff_late = acpi_subsys_suspend_late,
.poweroff_noirq = acpi_subsys_suspend_noirq,
- .restore_noirq = acpi_subsys_resume_noirq,
- .restore_early = acpi_subsys_resume_early,
+ .restore_noirq = acpi_subsys_restore_noirq,
+ .restore_early = acpi_subsys_restore_early,
#endif
},
};
Index: linux-pm/drivers/acpi/acpi_lpss.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -1069,36 +1069,67 @@ static int acpi_lpss_suspend_noirq(struc
return acpi_subsys_suspend_noirq(dev);
}

-static int acpi_lpss_do_resume_early(struct device *dev)
+static int acpi_lpss_resume_noirq(struct device *dev)
{
- int ret = acpi_lpss_resume(dev);
+ struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+
+ /* Follow acpi_subsys_resune_noirq(). */
+ if (dev_pm_may_skip_resume(dev))
+ return 0;
+
+ if (dev_pm_smart_suspend_and_suspended(dev))
+ pm_runtime_set_active(dev);

- return ret ? ret : pm_generic_resume_early(dev);
+ if (pdata->dev_desc->resume_from_noirq) {
+ int ret = acpi_lpss_resume(dev);
+ if (ret)
+ return ret;
+ }
+
+ return pm_generic_resume_noirq(dev);
}

static int acpi_lpss_resume_early(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));

- if (pdata->dev_desc->resume_from_noirq)
- return 0;
+ if (!pdata->dev_desc->resume_from_noirq) {
+ int ret = acpi_lpss_resume(dev);
+ if (ret)
+ return ret;
+ }

- return acpi_lpss_do_resume_early(dev);
+ return pm_generic_resume_early(dev);
}

-static int acpi_lpss_resume_noirq(struct device *dev)
+static int acpi_lpss_restore_noirq(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
- int ret;

- ret = acpi_subsys_resume_noirq(dev);
- if (ret)
- return ret;
+ /* Follow acpi_subsys_restore_noirq(). */
+ if (dev_pm_smart_suspend_and_suspended(dev))
+ pm_runtime_set_active(dev);
+
+ if (pdata->dev_desc->resume_from_noirq) {
+ int ret = acpi_lpss_resume(dev);
+ if (ret)
+ return ret;
+ }
+
+ return pm_generic_restore_noirq(dev);
+}
+
+static int acpi_lpss_restore_early(struct device *dev)
+{
+ struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));

- if (!dev_pm_may_skip_resume(dev) && pdata->dev_desc->resume_from_noirq)
- ret = acpi_lpss_do_resume_early(dev);
+ if (!pdata->dev_desc->resume_from_noirq) {
+ int ret = acpi_lpss_resume(dev);
+ if (ret)
+ return ret;
+ }

- return ret;
+ return pm_generic_restore_early(dev);
}

#endif /* CONFIG_PM_SLEEP */
@@ -1140,8 +1171,8 @@ static struct dev_pm_domain acpi_lpss_pm
.poweroff = acpi_subsys_suspend,
.poweroff_late = acpi_lpss_suspend_late,
.poweroff_noirq = acpi_lpss_suspend_noirq,
- .restore_noirq = acpi_lpss_resume_noirq,
- .restore_early = acpi_lpss_resume_early,
+ .restore_noirq = acpi_lpss_restore_noirq,
+ .restore_early = acpi_lpss_restore_early,
#endif
.runtime_suspend = acpi_lpss_runtime_suspend,
.runtime_resume = acpi_lpss_runtime_resume,
Index: linux-pm/include/linux/acpi.h
===================================================================
--- linux-pm.orig/include/linux/acpi.h
+++ linux-pm/include/linux/acpi.h
@@ -925,6 +925,8 @@ int acpi_subsys_freeze(struct device *de
int acpi_subsys_freeze_late(struct device *dev);
int acpi_subsys_freeze_noirq(struct device *dev);
int acpi_subsys_thaw_noirq(struct device *dev);
+int acpi_subsys_restore_noirq(struct device *dev);
+int acpi_subsys_restore_early(struct device *dev);
#else
static inline int acpi_dev_resume_early(struct device *dev) { return 0; }
static inline int acpi_subsys_prepare(struct device *dev) { return 0; }
@@ -938,6 +940,8 @@ static inline int acpi_subsys_freeze(str
static inline int acpi_subsys_freeze_late(struct device *dev) { return 0; }
static inline int acpi_subsys_freeze_noirq(struct device *dev) { return 0; }
static inline int acpi_subsys_thaw_noirq(struct device *dev) { return 0; }
+static inline int acpi_subsys_restore_noirq(struct device *dev) { return 0; }
+static inline int acpi_subsys_restore_early(struct device *dev) { return 0; }
#endif

#ifdef CONFIG_ACPI

2019-06-24 10:52:00

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

Hi Rafael,

<snip>

> Sorry for the long delay.
>
> I haven't dropped this issue on the floor, I hope that you are still able to follow up here.
>
> Can you please test the appended patch instead of the previous one?
>
> I have found some inconsistencies in the handling of hibernation in the ACPI PM domain
> and the LPSS driver that should be covered by this patch.

I know this is just a testing patch for now, but still I've given it
a quick look, some comments inline.

> ---
> drivers/acpi/acpi_lpss.c | 63 +++++++++++++++++++++++++++++++++++------------
> drivers/acpi/device_pm.c | 30 ++++++++++++++++++++--
> include/linux/acpi.h | 4 ++
> 3 files changed, 79 insertions(+), 18 deletions(-)
>
> Index: linux-pm/drivers/acpi/device_pm.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/device_pm.c
> +++ linux-pm/drivers/acpi/device_pm.c
> @@ -1171,6 +1171,32 @@ int acpi_subsys_thaw_noirq(struct device
> return pm_generic_thaw_noirq(dev);
> }
> EXPORT_SYMBOL_GPL(acpi_subsys_thaw_noirq);
> +
> +/**
> + * acpi_subsys_restore_noirq - Run the device driver's "noirq" restore callback.
> + * @dev: Device to handle.
> + */
> +int acpi_subsys_restore_noirq(struct device *dev)
> +{
> + /* This is analogous to what acpi_subsys_resune_noirq() does. */
> + if (dev_pm_smart_suspend_and_suspended(dev))
> + pm_runtime_set_active(dev);
> +
> + return pm_generic_restore_noirq(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_subsys_restore_noirq);
> +
> +/**
> + * acpi_subsys_restore_early - Restore device using ACPI.
> + * @dev: Device to restore.
> + */
> +int acpi_subsys_restore_early(struct device *dev)
> +{
> + int ret = acpi_dev_resume(dev);
> + return ret ? ret : pm_generic_restore_early(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_subsys_restore_early);
> +
> #endif /* CONFIG_PM_SLEEP */
>
> static struct dev_pm_domain acpi_general_pm_domain = {
> @@ -1192,8 +1218,8 @@ static struct dev_pm_domain acpi_general
> .poweroff = acpi_subsys_suspend,
> .poweroff_late = acpi_subsys_suspend_late,
> .poweroff_noirq = acpi_subsys_suspend_noirq,
> - .restore_noirq = acpi_subsys_resume_noirq,
> - .restore_early = acpi_subsys_resume_early,
> + .restore_noirq = acpi_subsys_restore_noirq,
> + .restore_early = acpi_subsys_restore_early,
> #endif
> },
> };
> Index: linux-pm/drivers/acpi/acpi_lpss.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/acpi_lpss.c
> +++ linux-pm/drivers/acpi/acpi_lpss.c
> @@ -1069,36 +1069,67 @@ static int acpi_lpss_suspend_noirq(struc
> return acpi_subsys_suspend_noirq(dev);
> }
>
> -static int acpi_lpss_do_resume_early(struct device *dev)
> +static int acpi_lpss_resume_noirq(struct device *dev)
> {
> - int ret = acpi_lpss_resume(dev);
> + struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> +
> + /* Follow acpi_subsys_resune_noirq(). */
> + if (dev_pm_may_skip_resume(dev))
> + return 0;
> +
> + if (dev_pm_smart_suspend_and_suspended(dev))
> + pm_runtime_set_active(dev);
>
> - return ret ? ret : pm_generic_resume_early(dev);
> + if (pdata->dev_desc->resume_from_noirq) {
> + int ret = acpi_lpss_resume(dev);
> + if (ret)
> + return ret;
> + }
> +
> + return pm_generic_resume_noirq(dev);
> }

Hmm, normally acpi_lpss_resume runs at resume_early time, AFAIK
the order of resume callbacks calling is: resume_noirq, resume_early, resume

So normally our call order is:

---noirq-phase---
pm_generic_resume_noirq()
---early-phase---
acpi_lpss_resume()
pm_generic_resume_early()

My patch adding the resume_from_noirq flag, move the calling of
acpi_lpss_resume() to the resume_noirq phase (if the flag is
set) but kept the generic order, so the call order with the
flag set currently is:

---noirq-phase---
pm_generic_resume_noirq()
acpi_lpss_resume()
---early-phase---
pm_generic_resume_early()

So the order of the 3 calls relative to each other did not change.

You are changing this to:

---noirq-phase---
acpi_lpss_resume()
pm_generic_resume_noirq()
---early-phase---
pm_generic_resume_early()

So now when the flag is set acpi_lpss_resume() runs before
pm_generic_resume_noirq(). Is this intentional ?

Regards,

Hans

>
> static int acpi_lpss_resume_early(struct device *dev)
> {
> struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
>
> - if (pdata->dev_desc->resume_from_noirq)
> - return 0;
> + if (!pdata->dev_desc->resume_from_noirq) {
> + int ret = acpi_lpss_resume(dev);
> + if (ret)
> + return ret;
> + }
>
> - return acpi_lpss_do_resume_early(dev);
> + return pm_generic_resume_early(dev);
> }
>
> -static int acpi_lpss_resume_noirq(struct device *dev)
> +static int acpi_lpss_restore_noirq(struct device *dev)
> {
> struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> - int ret;
>
> - ret = acpi_subsys_resume_noirq(dev);
> - if (ret)
> - return ret;
> + /* Follow acpi_subsys_restore_noirq(). */
> + if (dev_pm_smart_suspend_and_suspended(dev))
> + pm_runtime_set_active(dev);
> +
> + if (pdata->dev_desc->resume_from_noirq) {
> + int ret = acpi_lpss_resume(dev);
> + if (ret)
> + return ret;
> + }
> +
> + return pm_generic_restore_noirq(dev);
> +}
> +
> +static int acpi_lpss_restore_early(struct device *dev)
> +{
> + struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
>
> - if (!dev_pm_may_skip_resume(dev) && pdata->dev_desc->resume_from_noirq)
> - ret = acpi_lpss_do_resume_early(dev);
> + if (!pdata->dev_desc->resume_from_noirq) {
> + int ret = acpi_lpss_resume(dev);
> + if (ret)
> + return ret;
> + }
>
> - return ret;
> + return pm_generic_restore_early(dev);
> }
>
> #endif /* CONFIG_PM_SLEEP */
> @@ -1140,8 +1171,8 @@ static struct dev_pm_domain acpi_lpss_pm
> .poweroff = acpi_subsys_suspend,
> .poweroff_late = acpi_lpss_suspend_late,
> .poweroff_noirq = acpi_lpss_suspend_noirq,
> - .restore_noirq = acpi_lpss_resume_noirq,
> - .restore_early = acpi_lpss_resume_early,
> + .restore_noirq = acpi_lpss_restore_noirq,
> + .restore_early = acpi_lpss_restore_early,
> #endif
> .runtime_suspend = acpi_lpss_runtime_suspend,
> .runtime_resume = acpi_lpss_runtime_resume,
> Index: linux-pm/include/linux/acpi.h
> ===================================================================
> --- linux-pm.orig/include/linux/acpi.h
> +++ linux-pm/include/linux/acpi.h
> @@ -925,6 +925,8 @@ int acpi_subsys_freeze(struct device *de
> int acpi_subsys_freeze_late(struct device *dev);
> int acpi_subsys_freeze_noirq(struct device *dev);
> int acpi_subsys_thaw_noirq(struct device *dev);
> +int acpi_subsys_restore_noirq(struct device *dev);
> +int acpi_subsys_restore_early(struct device *dev);
> #else
> static inline int acpi_dev_resume_early(struct device *dev) { return 0; }
> static inline int acpi_subsys_prepare(struct device *dev) { return 0; }
> @@ -938,6 +940,8 @@ static inline int acpi_subsys_freeze(str
> static inline int acpi_subsys_freeze_late(struct device *dev) { return 0; }
> static inline int acpi_subsys_freeze_noirq(struct device *dev) { return 0; }
> static inline int acpi_subsys_thaw_noirq(struct device *dev) { return 0; }
> +static inline int acpi_subsys_restore_noirq(struct device *dev) { return 0; }
> +static inline int acpi_subsys_restore_early(struct device *dev) { return 0; }
> #endif
>
> #ifdef CONFIG_ACPI
>
>
>

2019-06-25 03:53:50

[permalink] [raw]

Subject: Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

On Monday, June 24, 2019 12:51:33 PM CEST Hans de Goede wrote:
> Hi Rafael,
>
> <snip>
>
> > Sorry for the long delay.
> >
> > I haven't dropped this issue on the floor, I hope that you are still able to follow up here.
> >
> > Can you please test the appended patch instead of the previous one?
> >
> > I have found some inconsistencies in the handling of hibernation in the ACPI PM domain
> > and the LPSS driver that should be covered by this patch.
>
> I know this is just a testing patch for now, but still I've given it
> a quick look, some comments inline.
>
> > ---
> > drivers/acpi/acpi_lpss.c | 63 +++++++++++++++++++++++++++++++++++------------
> > drivers/acpi/device_pm.c | 30 ++++++++++++++++++++--
> > include/linux/acpi.h | 4 ++
> > 3 files changed, 79 insertions(+), 18 deletions(-)
> >
> > Index: linux-pm/drivers/acpi/device_pm.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/device_pm.c
> > +++ linux-pm/drivers/acpi/device_pm.c
> > @@ -1171,6 +1171,32 @@ int acpi_subsys_thaw_noirq(struct device
> > return pm_generic_thaw_noirq(dev);
> > }
> > EXPORT_SYMBOL_GPL(acpi_subsys_thaw_noirq);
> > +
> > +/**
> > + * acpi_subsys_restore_noirq - Run the device driver's "noirq" restore callback.
> > + * @dev: Device to handle.
> > + */
> > +int acpi_subsys_restore_noirq(struct device *dev)
> > +{
> > + /* This is analogous to what acpi_subsys_resune_noirq() does. */
> > + if (dev_pm_smart_suspend_and_suspended(dev))
> > + pm_runtime_set_active(dev);
> > +
> > + return pm_generic_restore_noirq(dev);
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_subsys_restore_noirq);
> > +
> > +/**
> > + * acpi_subsys_restore_early - Restore device using ACPI.
> > + * @dev: Device to restore.
> > + */
> > +int acpi_subsys_restore_early(struct device *dev)
> > +{
> > + int ret = acpi_dev_resume(dev);
> > + return ret ? ret : pm_generic_restore_early(dev);
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_subsys_restore_early);
> > +
> > #endif /* CONFIG_PM_SLEEP */
> >
> > static struct dev_pm_domain acpi_general_pm_domain = {
> > @@ -1192,8 +1218,8 @@ static struct dev_pm_domain acpi_general
> > .poweroff = acpi_subsys_suspend,
> > .poweroff_late = acpi_subsys_suspend_late,
> > .poweroff_noirq = acpi_subsys_suspend_noirq,
> > - .restore_noirq = acpi_subsys_resume_noirq,
> > - .restore_early = acpi_subsys_resume_early,
> > + .restore_noirq = acpi_subsys_restore_noirq,
> > + .restore_early = acpi_subsys_restore_early,
> > #endif
> > },
> > };
> > Index: linux-pm/drivers/acpi/acpi_lpss.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/acpi_lpss.c
> > +++ linux-pm/drivers/acpi/acpi_lpss.c
> > @@ -1069,36 +1069,67 @@ static int acpi_lpss_suspend_noirq(struc
> > return acpi_subsys_suspend_noirq(dev);
> > }
> >
> > -static int acpi_lpss_do_resume_early(struct device *dev)
> > +static int acpi_lpss_resume_noirq(struct device *dev)
> > {
> > - int ret = acpi_lpss_resume(dev);
> > + struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
> > +
> > + /* Follow acpi_subsys_resune_noirq(). */
> > + if (dev_pm_may_skip_resume(dev))
> > + return 0;
> > +
> > + if (dev_pm_smart_suspend_and_suspended(dev))
> > + pm_runtime_set_active(dev);
> >
> > - return ret ? ret : pm_generic_resume_early(dev);
> > + if (pdata->dev_desc->resume_from_noirq) {
> > + int ret = acpi_lpss_resume(dev);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return pm_generic_resume_noirq(dev);
> > }
>
> Hmm, normally acpi_lpss_resume runs at resume_early time, AFAIK
> the order of resume callbacks calling is: resume_noirq, resume_early, resume
>
> So normally our call order is:
>
> ---noirq-phase---
> pm_generic_resume_noirq()
> ---early-phase---
> acpi_lpss_resume()
> pm_generic_resume_early()
>
> My patch adding the resume_from_noirq flag, move the calling of
> acpi_lpss_resume() to the resume_noirq phase (if the flag is
> set) but kept the generic order, so the call order with the
> flag set currently is:
>
> ---noirq-phase---
> pm_generic_resume_noirq()
> acpi_lpss_resume()
> ---early-phase---
> pm_generic_resume_early()
>
> So the order of the 3 calls relative to each other did not change.
>
> You are changing this to:
>
> ---noirq-phase---
> acpi_lpss_resume()
> pm_generic_resume_noirq()
> ---early-phase---
> pm_generic_resume_early()
>
> So now when the flag is set acpi_lpss_resume() runs before
> pm_generic_resume_noirq(). Is this intentional ?

Kind of yes, but this is two patches in one. :-)

The ordering change should really be a separate patch IMO.

2019-06-26 18:43:38