Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jul 2021 18:07:55 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 255745] resume on T490 Thinkpad often broken after upgrade 12 -> 13
Message-ID:  <bug-255745-227-C2FDyOBJDj@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-255745-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-255745-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255745

--- Comment #19 from John Grafton <john.grafton@runbox.com> ---
After more testing, I was able to get 6abe97c0140d54d3520c30517b2bdebc3de92=
a62
to fail (making my previous comment incorrect).  Thus I went back to the
beginning of 13-CURRENT to find the where the issue made its way into the c=
ode
base.  Instead of November 2020, it appears to have been added in July 2020.

I've spent the past week `git bisecting` my way through CURRENT looking for=
 the
beginning of the suspend/resume issue.

Here's a brief description of my testing methodology:
1) Build world / kernel on 12 core system in a 12.2 jail (takes ~ 1/2 hour)
2) Install world / kernel on laptop from NFS to new boot environment on lap=
top
3) Boot laptop into new boot environment
4) Compile DRM driver for current kernel
5) kldload i915kms driver
6) Close lid and leave closed for 5 seconds
7) Open lid and wait to see if the system fails to resume
8) Repeat lid close and open in console 15 times and in X 5 times
9) If resume fails, mark bisect fail, if all resumes succeed, mark bisect g=
ood

Usually, resumes would fail after 5 or so tries.  I never had a resume fail=
 in
X that didn't first fail in the console.  It did not seem to make a differe=
nce
if I was on the console or in X.org.

I found that before 12b2f3daaa597f346a4b0065bf7f75378524ef88 the X1 Carbon =
Gen
6 resumes all 20 times without issue.  The main flaw in my methodology is
assuming 20 suspend and resumes are enough to accurately test for the issue=
.=20=20

I'm currently using src commit e7677232d6eed5f5cae80c1d5968eea5b9266b59 with
graphics/drm-current-kmod from ports commit
d9b8d3b2b3b5ffcf4b83572098d64803fe237b90 as my daily laptop to test the
assumption that 20 suspend and resumes are enough to make a generalization
about whether my tests were valid.

Oddly, commit 12b2f3daaa597f346a4b0065bf7f75378524ef88 being flagged as the
issue is very strange to me because that commit appears to be essentially a
NOOP as it's just cleaning up #ifdef statements for older systems.  12.2 wh=
ich
does not fail at all seems to have similar patches in place.

My next steps are to continue testing this older commit as my daily laptop =
and
see if I can get it to fail.  Then attempt to build a version of 13-RELEASE
with what appears to be the offending patch removed and see if it fails.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



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