From owner-freebsd-current@freebsd.org Fri Nov 27 21:16:46 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0AADC468FDB for ; Fri, 27 Nov 2020 21:16:46 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjS9n6tSxz4SvT for ; Fri, 27 Nov 2020 21:16:45 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: lwhsu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D848D5BC for ; Fri, 27 Nov 2020 21:16:45 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by mail-yb1-f169.google.com with SMTP id x17so5621396ybr.8 for ; Fri, 27 Nov 2020 13:16:45 -0800 (PST) X-Gm-Message-State: AOAM530G7uzCTmMmrmROWXbvbQFhFe0rGP3GDp8vzgyh/Q+ev7GTMSmm cfwTll2uy7FlPINZCgDFV8zm+X0v75LaCHC4dWU= X-Google-Smtp-Source: ABdhPJzPGjTtzDGfTDJTn3l/AgD9YJ39VzEJ/+sl06khzk9bWMoM/OUiTHzCXGWIqd/EA1p7kBNCpShW0HJijJq3wcI= X-Received: by 2002:a25:209:: with SMTP id 9mr15992417ybc.127.1606511805145; Fri, 27 Nov 2020 13:16:45 -0800 (PST) MIME-Version: 1.0 References: <0b2f0f19-490b-4bb5-52b3-201e24ebeaee@anduin.net> <39ceba1e-3e9e-a861-ab71-d376969990c4@FreeBSD.org> <2162563.mfXeX5GmMH@carbon8.weirdr.net> In-Reply-To: <2162563.mfXeX5GmMH@carbon8.weirdr.net> From: Li-Wen Hsu Date: Sat, 28 Nov 2020 05:16:33 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen) To: =?UTF-8?Q?Eirik_=C3=98verby?= Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 21:16:46 -0000 On Mon, Oct 12, 2020 at 5:22 PM Eirik =C3=98verby 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