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>