Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Cheers,
Jerry
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
thanks,
greg k-h
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd, -srw
On Fri, Sep 30, 2022 at 07:11:19AM -0400, Slade Watkins wrote:
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd,
So 5.19.11 works for you, but 5.19.12 does not?
Or is it just the arch packaged kernel that does not work for you?
confused,
greg k-h
Greg,
On Sep 30, 2022, at 7:22 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 07:11:19AM -0400, Slade Watkins wrote:
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd,
So 5.19.11 works for you, but 5.19.12 does not?
Or is it just the arch packaged kernel that does not work for you?
Oh, no no no. I was saying there weren't any issues. I myself haven’t had any issues on gen 11 framework.
I tested the arch-packaged versions, as well as the kernels directly from source. Both didn’t have anything to report from bisect. (Odd? Yeah.)
I’m really sorry for the confusion, -srw
Hi,
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
On 9/30/22 07:11, Slade Watkins wrote:
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd, -srw
On Sep 30, 2022, at 8:26 AM, Jerry Ling jiling@cern.ch wrote:
Hi,
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
I just got Thorsten’s email about this [1]. Alright then.
[1] https://lore.kernel.org/all/b85bc2cf-5ea5-c5fb-465c-cd6637f6d30f@leemhuis.in...
-srw
On 30.09.22 14:26, Jerry Ling wrote:
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
FWIW, that's 3cf050762534 in mainline. Adding Ville, its author to the list of recipients.
Did anyone check if a revert on top of 5.19.12 works easily and solves the problem?
And does anybody known if mainline affected, too?
Ciao, Thorsten
On 9/30/22 07:11, Slade Watkins wrote:
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd, -srw
Hi,
On 10/1/22 12:07, Thorsten Leemhuis wrote:
On 30.09.22 14:26, Jerry Ling wrote:
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
FWIW, that's 3cf050762534 in mainline. Adding Ville, its author to the list of recipients.
Did anyone check if a revert on top of 5.19.12 works easily and solves the problem?
And does anybody known if mainline affected, too?
Sorry for jumping in the middle of the thread. I believe that this is also reported by Fedora users on a Lenovo Carbon X1 (gen 9) as:
https://bugzilla.redhat.com/show_bug.cgi?id=2130699
So it would be good to add a:
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2130699
tag to the commit which ends up fixing this.
Regards,
Hans
Ciao, Thorsten
On 9/30/22 07:11, Slade Watkins wrote:
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd, -srw
On Sat, Oct 01, 2022 at 12:07:39PM +0200, Thorsten Leemhuis wrote:
On 30.09.22 14:26, Jerry Ling wrote:
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
FWIW, that's 3cf050762534 in mainline. Adding Ville, its author to the list of recipients.
I definitely had no plans to backport any of that stuff, but I guess the automagics did it anyway.
Looks like stable is at least missing this pile of stuff: 50759c13735d drm/i915/pps: Keep VDD enabled during eDP probe 67090801489d drm/i915/pps: Reinit PPS delays after VBT has been fully parsed 8e75e8f573e1 drm/i915/pps: Split PPS init+sanitize in two 586294c3c186 drm/i915/pps: Stash away original BIOS programmed PPS delays 89fcdf430599 drm/i915/pps: Don't apply quirks/etc. to the VBT PPS delays if they haven't been initialized 60b02a09598f drm/i915/pps: Introduce pps_delays_valid()
But dunno if even that is enough.
This bug report is probably the same thing: https://gitlab.freedesktop.org/drm/intel/-/issues/7013
Did anyone check if a revert on top of 5.19.12 works easily and solves the problem?
And does anybody known if mainline affected, too?
Ciao, Thorsten
On 9/30/22 07:11, Slade Watkins wrote:
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote:
Hi,
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd, -srw
On Mon, Oct 03, 2022 at 08:45:18PM +0300, Ville Syrjälä wrote:
On Sat, Oct 01, 2022 at 12:07:39PM +0200, Thorsten Leemhuis wrote:
On 30.09.22 14:26, Jerry Ling wrote:
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
FWIW, that's 3cf050762534 in mainline. Adding Ville, its author to the list of recipients.
I definitely had no plans to backport any of that stuff, but I guess the automagics did it anyway.
Looks like stable is at least missing this pile of stuff: 50759c13735d drm/i915/pps: Keep VDD enabled during eDP probe 67090801489d drm/i915/pps: Reinit PPS delays after VBT has been fully parsed 8e75e8f573e1 drm/i915/pps: Split PPS init+sanitize in two 586294c3c186 drm/i915/pps: Stash away original BIOS programmed PPS delays 89fcdf430599 drm/i915/pps: Don't apply quirks/etc. to the VBT PPS delays if they haven't been initialized 60b02a09598f drm/i915/pps: Introduce pps_delays_valid()
But dunno if even that is enough.
This bug report is probably the same thing: https://gitlab.freedesktop.org/drm/intel/-/issues/7013
Also cc intel-gfx...
Did anyone check if a revert on top of 5.19.12 works easily and solves the problem?
And does anybody known if mainline affected, too?
Ciao, Thorsten
On 9/30/22 07:11, Slade Watkins wrote:
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote:
On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote: > Hi, > > It has been reported by multiple users across a handful of distros > that > there seems to be regression on Framework laptop (which presumably > is not > that special in terms of mobo and display) > > Ref: > https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch... Can anyone do a 'git bisect' to find the offending commit?
Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd, -srw
-- Ville Syrjälä Intel
On 03.10.22 19:48, Ville Syrjälä wrote:
On Mon, Oct 03, 2022 at 08:45:18PM +0300, Ville Syrjälä wrote:
On Sat, Oct 01, 2022 at 12:07:39PM +0200, Thorsten Leemhuis wrote:
On 30.09.22 14:26, Jerry Ling wrote:
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
FWIW, that's 3cf050762534 in mainline. Adding Ville, its author to the list of recipients.
I definitely had no plans to backport any of that stuff, but I guess the automagics did it anyway.
Looks like stable is at least missing this pile of stuff: 50759c13735d drm/i915/pps: Keep VDD enabled during eDP probe 67090801489d drm/i915/pps: Reinit PPS delays after VBT has been fully parsed 8e75e8f573e1 drm/i915/pps: Split PPS init+sanitize in two 586294c3c186 drm/i915/pps: Stash away original BIOS programmed PPS delays 89fcdf430599 drm/i915/pps: Don't apply quirks/etc. to the VBT PPS delays if they haven't been initialized 60b02a09598f drm/i915/pps: Introduce pps_delays_valid()
But dunno if even that is enough.
If you need testers: David (now CCed) apparently has a affected machine and offered to test patches in a different subthread of this thread.
This bug report is probably the same thing: https://gitlab.freedesktop.org/drm/intel/-/issues/7013
Sounds like it.
Also cc intel-gfx...
Ahh, sorry, should have done that when I CCed you.
Ciao, Thorsten
Did anyone check if a revert on top of 5.19.12 works easily and solves the problem?
And does anybody known if mainline affected, too?
Ciao, Thorsten
On 9/30/22 07:11, Slade Watkins wrote:
Hey Greg,
On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote: > On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote: >> Hi, >> >> It has been reported by multiple users across a handful of distros >> that >> there seems to be regression on Framework laptop (which presumably >> is not >> that special in terms of mobo and display) >> >> Ref: >> https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch... > Can anyone do a 'git bisect' to find the offending commit? Also, this works for me on a gen 12 framework laptop: $ uname -a Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 CEST 2022 x86_64 GNU/Linux
so there's something odd with the older hardware?
greg k-h
Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd, -srw
-- Ville Syrjälä Intel
On Mon, Oct 03, 2022 at 08:28:50PM +0200, Thorsten Leemhuis wrote:
On 03.10.22 19:48, Ville Syrjälä wrote:
On Mon, Oct 03, 2022 at 08:45:18PM +0300, Ville Syrjälä wrote:
On Sat, Oct 01, 2022 at 12:07:39PM +0200, Thorsten Leemhuis wrote:
On 30.09.22 14:26, Jerry Ling wrote:
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
FWIW, that's 3cf050762534 in mainline. Adding Ville, its author to the list of recipients.
I definitely had no plans to backport any of that stuff, but I guess the automagics did it anyway.
Looks like stable is at least missing this pile of stuff: 50759c13735d drm/i915/pps: Keep VDD enabled during eDP probe 67090801489d drm/i915/pps: Reinit PPS delays after VBT has been fully parsed 8e75e8f573e1 drm/i915/pps: Split PPS init+sanitize in two 586294c3c186 drm/i915/pps: Stash away original BIOS programmed PPS delays 89fcdf430599 drm/i915/pps: Don't apply quirks/etc. to the VBT PPS delays if they haven't been initialized 60b02a09598f drm/i915/pps: Introduce pps_delays_valid()
But dunno if even that is enough.
If you need testers: David (now CCed) apparently has a affected machine and offered to test patches in a different subthread of this thread.
This bug report is probably the same thing: https://gitlab.freedesktop.org/drm/intel/-/issues/7013
Sounds like it.
Also cc intel-gfx...
Ahh, sorry, should have done that when I CCed you.
After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel.
Greg, I recommend immediate revert of this stuff, and new stable release ASAP. Plus a recommendation that no one using laptops with Intel GPUs run 5.19.12.
Ciao, Thorsten
Did anyone check if a revert on top of 5.19.12 works easily and solves the problem?
And does anybody known if mainline affected, too?
Ciao, Thorsten
On 9/30/22 07:11, Slade Watkins wrote:
Hey Greg,
> On Sep 30, 2022, at 1:59 AM, Greg KH gregkh@linuxfoundation.org wrote: > > On Fri, Sep 30, 2022 at 06:37:48AM +0200, Greg KH wrote: >> On Thu, Sep 29, 2022 at 10:26:25PM -0400, Jerry Ling wrote: >>> Hi, >>> >>> It has been reported by multiple users across a handful of distros >>> that >>> there seems to be regression on Framework laptop (which presumably >>> is not >>> that special in terms of mobo and display) >>> >>> Ref: >>> https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch... >> Can anyone do a 'git bisect' to find the offending commit? > Also, this works for me on a gen 12 framework laptop: > $ uname -a > Linux frame 5.19.12 #68 SMP PREEMPT_DYNAMIC Fri Sep 30 07:02:33 > CEST 2022 x86_64 GNU/Linux > > so there's something odd with the older hardware? > > greg k-h Could be. Running git bisect for 5.19.11 and 5.19.12 (as suggested by the linked forum thread) returned nothing on gen 11 for me.
This is very odd, -srw
-- Ville Syrjälä Intel
On Tue, Oct 04, 2022 at 03:35:44PM +0300, Ville Syrjälä wrote:
On Mon, Oct 03, 2022 at 08:28:50PM +0200, Thorsten Leemhuis wrote:
On 03.10.22 19:48, Ville Syrjälä wrote:
On Mon, Oct 03, 2022 at 08:45:18PM +0300, Ville Syrjälä wrote:
On Sat, Oct 01, 2022 at 12:07:39PM +0200, Thorsten Leemhuis wrote:
On 30.09.22 14:26, Jerry Ling wrote:
looks like someone has done it: https://bbs.archlinux.org/viewtopic.php?pid=2059823#p2059823
and the bisect points to:
|# first bad commit: [fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c] drm/i915/bios: Split VBT data into per-panel vs. global parts Best, Jerry |
FWIW, that's 3cf050762534 in mainline. Adding Ville, its author to the list of recipients.
I definitely had no plans to backport any of that stuff, but I guess the automagics did it anyway.
Looks like stable is at least missing this pile of stuff: 50759c13735d drm/i915/pps: Keep VDD enabled during eDP probe 67090801489d drm/i915/pps: Reinit PPS delays after VBT has been fully parsed 8e75e8f573e1 drm/i915/pps: Split PPS init+sanitize in two 586294c3c186 drm/i915/pps: Stash away original BIOS programmed PPS delays 89fcdf430599 drm/i915/pps: Don't apply quirks/etc. to the VBT PPS delays if they haven't been initialized 60b02a09598f drm/i915/pps: Introduce pps_delays_valid()
But dunno if even that is enough.
If you need testers: David (now CCed) apparently has a affected machine and offered to test patches in a different subthread of this thread.
This bug report is probably the same thing: https://gitlab.freedesktop.org/drm/intel/-/issues/7013
Sounds like it.
Also cc intel-gfx...
Ahh, sorry, should have done that when I CCed you.
After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel.
Greg, I recommend immediate revert of this stuff, and new stable release ASAP. Plus a recommendation that no one using laptops with Intel GPUs run 5.19.12.
Ok, will do, I'll go do that right now, thanks and sorry for the problems.
greg k-h
Hi, this is your Linux kernel regression tracker.
On 30.09.22 04:26, Jerry Ling wrote:
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
A bisect would be good, as Greg already mentioned.
Not my area of expertise, so it's a wild guess, but display flickering made me wonder if this change is the culprit:
https://lore.kernel.org/all/20220926100814.131449678@linuxfoundation.org/
If it is, simply starting with "i915.enable_psr=0" might already help. but as I said, just a wild guess after briefly looking into the problem.
Anyway, for the rest of this mail: [TLDR: I'm adding this regression report to the list of tracked regressions; all text from me you find below is based on a few templates paragraphs you might have encountered already already in similar form.]
Thanks for the report. To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot:
#regzbot ^introduced v5.19.11..v5.19.12 #regzbot title Display flickering on Framework laptop #regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply -- ideally with also telling regzbot about it, as explained here: https://linux-regtracking.leemhuis.info/tracked-regression/
Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (the mail this one replies to), as explained for in the Linux kernel's documentation; above webpage explains why this is important for tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.
If it is, simply starting with "i915.enable_psr=0" might already help.
unfortunately this didn't help.
On 9/30/22 01:10, Thorsten Leemhuis wrote:
Hi, this is your Linux kernel regression tracker.
On 30.09.22 04:26, Jerry Ling wrote:
It has been reported by multiple users across a handful of distros that there seems to be regression on Framework laptop (which presumably is not that special in terms of mobo and display)
Ref: https://community.frame.work/t/psa-dont-upgrade-to-linux-kernel-5-19-12-arch...
A bisect would be good, as Greg already mentioned.
Not my area of expertise, so it's a wild guess, but display flickering made me wonder if this change is the culprit:
https://lore.kernel.org/all/20220926100814.131449678@linuxfoundation.org/
If it is, simply starting with "i915.enable_psr=0" might already help. but as I said, just a wild guess after briefly looking into the problem.
Anyway, for the rest of this mail: [TLDR: I'm adding this regression report to the list of tracked regressions; all text from me you find below is based on a few templates paragraphs you might have encountered already already in similar form.]
Thanks for the report. To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot:
#regzbot ^introduced v5.19.11..v5.19.12 #regzbot title Display flickering on Framework laptop #regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply -- ideally with also telling regzbot about it, as explained here: https://linux-regtracking.leemhuis.info/tracked-regression/
Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (the mail this one replies to), as explained for in the Linux kernel's documentation; above webpage explains why this is important for tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.
On Fri, Sep 30, 2022 at 09:05:31AM -0400, Jerry Ling wrote:
If it is, simply starting with "i915.enable_psr=0" might already help.
unfortunately this didn't help.
Ick. Ok, can you test your own kernel build out? If I provide a patch that reverts the what I think are offending commits, can you test it?
Also, does 6.0-rc7 also have this same problem? That should be tested first here, and if that's a problem, then we can get the i915 developers involved.
thanks,
greg k-h
Greg KH gregkh@linuxfoundation.org writes:
On Fri, Sep 30, 2022 at 09:05:31AM -0400, Jerry Ling wrote:
If it is, simply starting with "i915.enable_psr=0" might already help.
unfortunately this didn't help.
Ick. Ok, can you test your own kernel build out? If I provide a patch that reverts the what I think are offending commits, can you test it?
Also, does 6.0-rc7 also have this same problem? That should be tested first here, and if that's a problem, then we can get the i915 developers involved.
5.19.11 and 6.0 work fine on my 12th gen Framework. 5.19.12 has the flickering problem that's unaffected by "i915.enable_psr=0".
I'm also available to test patches if needed.
thanks,
greg k-h
thanks,
David Mattli
linux-stable-mirror@lists.linaro.org