Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Nov 2020 05:16:33 +0800
From:      Li-Wen Hsu <lwhsu@freebsd.org>
To:        =?UTF-8?Q?Eirik_=C3=98verby?= <ltning@anduin.net>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)
Message-ID:  <CAKBkRUyQpiKUSMfjjGBKz7ygu6Hnb3o7JoqQY8t76yZHb4SR_A@mail.gmail.com>
In-Reply-To: <2162563.mfXeX5GmMH@carbon8.weirdr.net>
References:  <0b2f0f19-490b-4bb5-52b3-201e24ebeaee@anduin.net> <39ceba1e-3e9e-a861-ab71-d376969990c4@FreeBSD.org> <CANCZdfpuKvs0hfA%2BP_zQ%2Btaok3k22RU77Sb7m1L2qG4-SXK-Bw@mail.gmail.com> <2162563.mfXeX5GmMH@carbon8.weirdr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 12, 2020 at 5:22 PM Eirik =C3=98verby <ltning@anduin.net> wrote=
:
>
> On Wednesday, September 16, 2020 9:05:43 AM CEST Warner Losh wrote:
> > I too can report this for my Lenovo Yoga running code as of September 1=
3,
> > but with manu's latest drm...  It used to work fine, but my last build =
on
> > the system was from May. Most likely a new panic in that code path, but
> > I've not chased down further...
>
> So I got a gen8 to play with, and the list of grievances is long - but I =
have
> one observation that may be of interest:
> The gen8 would be usable (at least seemingly so) with a 13-kernel from la=
t
> 2019 or very early 2020. Then around the end of January - I've bisected i=
t
> down to around Jan 24, give or take, it would start wedging _hard_ after =
a
> minute or two of heavy load (compiling, cat /dev/random, that sort of thi=
ng).
> It was a problem prior to that too but it was _much_ harder to trigger, a=
t
> least based on my tests this weekend.
>
> The "solution" is to add
>   hint.hwpstate_intel.0.disabled=3D"1"
> to /boot/loader.conf. This obviously has disastrous impact on battery lif=
e.
> The emt module takes over, so power management is a lot more rudimentary
> (powerd now does nearly nothing, while powerd++ kills interactivity). Bat=
tery
> life is much shorter than on my gen6, and it gets hotter.
>
> BUT: This thing - gen8 - would get stuck in the acpi_beep before adding t=
his
> to loader.conf. After adding the hint, I have not had a single failure wh=
en
> resuming. It's behaving much better than my gen6.

Recently I got an interesting observation: if I suspend with `zzz`,
(which is basically doing `acpiconf -s S3`), and resuming by pushing
the power button, there is 95% chance of resuming failure.
However, if I use close/open the lid to suspend/resume, I haven't hit
any failure since last week.

I suppose that these 2 suspend/resume methods are basically doing the
same thing?  My hw.acpi.lid_switch_state sysctl is S3.

I have tried suspending with `zzz` then closing the lid, there is
about 50% failure rate, but the sample number is very small.

Is there any idea about what makes the difference between these 2
suspend/resume methods?

I'm running 13.0-CURRENT r367582, with drm-devel-kmod-5.4.62.g20201109
and gpu-firmware-kmod-g20200920. My /boot/loader.conf has
hw.i915kms.enable_psr=3D0 but no hint.hwpstate_intel.0.disabled=3D1

Best,
Li-Wen



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKBkRUyQpiKUSMfjjGBKz7ygu6Hnb3o7JoqQY8t76yZHb4SR_A>