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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f6db39bc-b8d1-fda8-ad37-a8b050ef0027@redhat.com>
Date:   Thu, 18 Apr 2019 13:42:02 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     "Robert R. Howell" <RHowell@...o.edu>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>
Cc:     "lenb@...nel.org" <lenb@...nel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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