Bug 1965645 - F34 kernel 5.12.5 and above screen flicker / wobble / shaking / jitter / wiggling problem
Summary: F34 kernel 5.12.5 and above screen flicker / wobble / shaking / jitter / wigg...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 34
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL: https://www.youtube.com/watch?v=0u_CA...
Whiteboard:
: 1971071 (view as bug list)
Depends On: [iwl3945], Kernel, oops
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-28 17:34 UTC by Fer Sosa
Modified: 2021-08-20 13:19 UTC (History)
26 users (show)

Fixed In Version: kernel-5.13.9-100.fc33 kernel-5.13.9-200.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-13 01:09:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Zip file with separate files for the dmesg outputs of the 5.11.21, 5.12.6, and 5.12.7 kernels as well as an lshw file with the lshw file output. (67.92 KB, application/zip)
2021-05-28 17:34 UTC, Fer Sosa
no flags Details
Zip file with three dmesg text files for kernels 5.11.21+debug_f34, 5.12.9+debug_f34 and 5.12.9_ubuntu_20.14, all with the "debug --verbose" parameters added and the "quite" parameter erased. (86.41 KB, text/plain)
2021-06-09 19:26 UTC, Fer Sosa
no flags Details
dmesg files for kernels 5.12.4, 5.12.4+debug+"debug --verbose", 5.13.0-0.rc6.45.fc35, 5.13.0-0.rc6.45.fc35+debug+"debug --verbose", 5.12.10, 5.12.10+debug+"debug --verbose" (156.04 KB, application/zip)
2021-06-15 16:05 UTC, Fer Sosa
no flags Details

Description Fer Sosa 2021-05-28 17:34:22 UTC
Created attachment 1787888 [details]
Zip file with separate files for the dmesg outputs of the 5.11.21, 5.12.6, and 5.12.7 kernels as well as an lshw file with the lshw file output.

Created attachment 1787888 [details]
Zip file with separate files for the dmesg outputs of the 5.11.21, 5.12.6, and 5.12.7 kernels as well as an lshw file with the lshw file output.

Created attachment 1787888 [details]
Zip file with separate files for the dmesg outputs of the 5.11.21, 5.12.6, and 5.12.7 kernels as well as an lshw file with the lshw file output.

1. Please describe the problem:

After update to kernel 5.12.5 a screen flicker o wobble was introduced. This flicker/wobble starts at the luks password prompt (root, home and swap are luks2 encrypted) and continues on all the way to the gnome user password prompt and also once gnome is in use. Initially I reverted to kernel 5.11.21 and waited to see if the next kernel updated fixed the problem. Once kernel 5.12.6 came out the problem persisted. I installed kernel 5.12.7 and the problem persisted. I installed kernel 5.13.0 for f35 just to see if I would get lucky but no joy. For other reasons/problems that were easier to fix with a reinstall I went ahead and reinstall f34 workstation, by which I mean root (and boot) was reformatted. After this at no point did I use any non official fedora repository (i.e. rpmfusion, etc.). This time it started with kernel 5.11.12 and everything was fine. I upgraded everything including to kernel 5.12.6 and the problem reappeared. At this point I lost it a little and had a bit and clean installed (again formatted root and boot) f34 kde spin. Again updated kernels. Again the flicker/wobble appeared. After that I reinstalled normal (gnome) f34 workstation and again tried to update to kernels 5.12.6 and 5.12.7 and with both the problem persists (this is when I got the kernel logs, I don't have them for 5.13.0, but I could get them if you need them, though I am thinking of reverting to f33 and seeing if I get the problem there too). Every time I boot into those kernels the flicker/wobble reappears. Only in 5.11.21 or earlier is the screen stable (I don't think I missed any kernel updates from 5.11.12 to 5.11.21). While in kernel 5.12.6 I tried changing the screen refresh rate, from 60.01 Hz to 59.96 Hz, again, no joy. 

I posted a video on youtube that shows the problem at: https://youtu.be/0u_CA6saNFc

I attached the lshw file but a quick review of the specs of the laptop is as follows:
MSI GE72VR Apache Pro
17.3" screen (1920x1080) 60Hz (though system setting lets me choose 59.96 Hz or 60.01 Hz, I tried both and again, no joy). 
GeForce GTX 1060 with 6GB GDDR5 (the problem persists with nouveau and the proprietary drivers btw, and yes, I do sign them in UEFI)
12 GB of RAM
1 x 512 GB SSD (non nvme)
1 x 1 TB HDD

I attach the dmesg files for kernels 5.11.21, 5.12.6, and 5.12.7. All with the OS fully updated.

2. What is the Version-Release number of the kernel:

5.12.6_f34, 5.12.7_f34 and 5.13.0_f35

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

5.12.5

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

I reinstalled everything from scratch. Every time I upgrade to kernel 5.12.5 or above I get the screen flicker/wobble/shaking problem.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

Yes, I did dnf update --enablerepo=updates-testing kernel, it gave me kernel 5.12.7, the problem persisted. 

6. Are you running any modules that not shipped with directly Fedora's kernel?:

Not after I reinstalled from scratch. And the problem persisted. (P.S.: All I had installed before was from rpmfusion).

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.
   
   Will do, for kernels 5.11.21, 5.12.6, and 5.12.7 (all with the rest of the OS fully updated). I also attach the lshw file.

   I posted a video on youtube that shows the problem at: https://youtu.be/0u_CA6saNFc


EDIT:

1) At least someone in my youtube video made a comment that they have the same problem and that they also opened a bug report with "Red Hat". As of now I don't know the number of that bug report.

2) I have gone ahead and tested kernels 5.12.8 and 5.12.9 and no joy.

3) I made an Ubuntu installation to an external HDD and installed kernel 5.12.8 on it. The same thing happened. I'll post the video of that later.

4) I'm going to add a second zip archive with the dmesg files for kernels 5.12.8, 5.12.9, for the Ubuntu case I'm going to add the 5.12.9 dmesg file. I've started using the kernel+debug kernels in Koji, and I've also added the "debug --verbose", and deleted the "quite" parameters in grub.


2nd EDIT:

1) Finally got round to uploading the Ubuntu 20.04 video, I'm not sure it's useful in any way beyond showing that it is the hardware + kernel combination regardless of the *nix I guess. I really have no interest of using Ubuntu. I've been using Fedora in my own laptops since FC2. The video is at: https://youtu.be/xnI_zkabeCo

Comment 1 Fer Sosa 2021-06-09 19:26:40 UTC
Created attachment 1789647 [details]
Zip file with three dmesg text files for kernels 5.11.21+debug_f34, 5.12.9+debug_f34 and 5.12.9_ubuntu_20.14, all with the "debug --verbose" parameters added and the "quite" parameter erased.

Hi, I went ahead and tested with kernels 5.12.8 and 5.12.9 and no joy. I also did an Ubuntu 20.14 installation to an external HDD and installed 5.12.9 and the same thing happened. I attach the dmesg files, with the "debug --verbose" parameter added for kernels 5.11.21+debug_f34, 5.12.9+debug_f34 and 5.12.9_ubuntu_20.14.

Comment 2 Justin M. Forbes 2021-06-11 21:11:55 UTC
*** Bug 1971071 has been marked as a duplicate of this bug. ***

Comment 3 Massimo Di Primio 2021-06-14 17:14:28 UTC
Same problem here!

Below crucial information:

1. Environment:
 - Machine: Laptop Lenovo Z70
 - OS: Fedora 33 ThirtyThree
 - Kernel: x86_64 Linux 5.11.21-200.fc33.x86_64
 - Resolution: 1920x1080
 - DE: MATE 1.24.3
 - WM: Metacity (Marco)
 - Disk: 564G / 1.1T (51%)
 - CPU: Intel Core i7-5500U @ 4x 3GHz
 - GPU: GeForce 840M
 - RAM: 16 GB

1. Problem description:
 a). First time the issue appeared was when upgrading from kernel 5.11.21 to kernel-5.12.5 (everything was normal until kernel-5.11.21.
 b). The issue appears at the boot screen and persists on login screen and all the way up to the desktop.
 c). When restarting the system with kernel 5.11.21 everything is back to normal.
 d). Tried to implement NVIDIA driver successfully, but the problem still shows up with kernel > 5.11.21.
 e). When connecting a 2nd screen, the problem persist on laptop screen, but not on the 2nd screen.
 f). Same thing using gnome instead of Mate (problem shows up from the boot screen).

3. Additional information:
Symptoms appear to be the same as described by user Fer Sosa and appear the seme as the video posted by him.

I Hope the issue will be resolved soon since the system is almost unusable with latest kernel and cannot be upgraded.

Thank you

Comment 4 Justin M. Forbes 2021-06-14 19:49:17 UTC
A couple of questions here.  It looks like all of these laptops are using nvidia gpus, but I am guessing they are also using i915 to save power when not needed?   The second monitor is what makes me ask, as several laptops wire the panel to the i915, and the HDMI port to the nvidia.  It would also be odd to see the same issue in both nvidia proprietary drivers and nouveau.

Can someone try a 5.12.4 kernel for me and let me know if the problem still exists?
in a tmp directory 'koji download-build --arch=x86_64 kernel-5.12.4-300.fc34' should grab a signed kernel that can be tested.

Also, does the problem persist on 5.13 kernels?
in a tmp directory 'koji download-build --arch=x86_64 kernel-5.13.0-0.rc6.45.fc35' should grab a signed kernel that can be tested.  You will not be able to build/load an nvidia proprietary module on this one because rawhide has a newer toolchain.

Comment 5 Fer Sosa 2021-06-15 04:14:06 UTC
(In reply to Justin M. Forbes from comment #4)

Hi Justin, 

First off, thanks for taking the time. We really appreciate it. 

1) I'll try kernel 5.12.4 in the morning (for me anyway, it's late here) and report back.

2) I did try kernel 5.13.0 (it did not say anything about release candidate, it was straight up 5.13.0) for Fedora 35 and the problem persisted. But I'll try the latest 5.13.0-0.rc6.45.fc35 as well as 5.12.4 in the morning.

3) When the problem first started I did have the proprietary Nvidia drivers installed and working great with kernel 5.12.21. I did in fact sign them (as I've always done for almost 3 years now) for kernels 5.12.5 and 5.12.6, it didn't help. After I reformatted I haven't used the proprietary drivers again, only nouveau. I can install de nvidia drivers but I doubt that'll make a difference. Honestly I'm out of my depth here, I don't know enough. I know the nvidia drivers are supposed to be able to pass some of the workload to the intel integrated graphics, but again, since I have the same problem with nvidia or nouveau I don't know if that is at play here.

4) I don't have an external monitor to try with so I don't know how that would behave, but I imagine it would be the same as Masssimo.

5) I don't know if it has any bearing, I'm grasping at straws here, but I have an older laptop that isn't dual boot, and also isn't UEFI. It only runs Fedora 34. It has a old nvidia gpu. I don't even bother to put the proprietary nvidia drivers on it. And it's working fine. So, maybe a UEFI problem? Again, I don't know enough, like I said, grasping at straws. 

Thanks

Comment 6 Fer Sosa 2021-06-15 04:16:55 UTC
I just checked, the gpu of the old laptop is a GeForce GT 525M. OLD

Comment 7 Fer Sosa 2021-06-15 16:05:15 UTC
Created attachment 1791288 [details]
dmesg files for kernels 5.12.4, 5.12.4+debug+"debug --verbose", 5.13.0-0.rc6.45.fc35, 5.13.0-0.rc6.45.fc35+debug+"debug --verbose", 5.12.10, 5.12.10+debug+"debug --verbose"

dmesg files for kernels 5.12.4, 5.12.4+debug+"debug --verbose", 5.13.0-0.rc6.45.fc35, 5.13.0-0.rc6.45.fc35+debug+"debug --verbose", 5.12.10, 5.12.10+debug+"debug --verbose"

Comment 8 Fer Sosa 2021-06-15 16:10:01 UTC
(In reply to Justin M. Forbes from comment #4)


Hi, so I did it. I went ahead and installed kernels 5.12.4, and 5.13.0-0.rc6.45.fc35, and also 5.12.10 which was in the update list this morning (I didn't find 5.12.11 in koji yet, waiting to try that). In all cases the problem persisted. I also uploaded a zip file containing the dmesg files for all those kernels plus the debug kernels with the "debug --verbose" added, so six dmesg files in total. I don't know if they are useful or not but just in case.

Hope this helps.

Comment 9 Justin M. Forbes 2021-06-15 16:41:25 UTC
Thanks, that answers my 2 biggest questions.  There was a patch specifically put into 5.12.5 to address a similar problem on some machines, based on the solution, there was potential that it broke others, but I see this is not the case.  And 5.13-rc6 means it hasn't been solved upstream another way.  Back to looking for an answer.  Given that 5.13-rc6 does not fix the issue, 5.12.11 likely will not either when released, as stable policy is patches have to be in Linus tree first.

Comment 10 Fer Sosa 2021-06-19 23:10:12 UTC
Hi, I'm back with tales from the desperate that grasp at straws. 

So first I went and did a non-UEFI install using an external HDD. Disabled safe boot and UEFI. Installed FC34 to the HDD and updated to kernel 5.12.10. The problem persisted.

I also tried kernel 5.13.0-0.rc6.20210617git70585216fe77.48.fc35 just for fun and the problem persisted. 

No dmesg files this time since I suspect you have more than enough of those. But if you want them I’ll go back and make them and upload them.

I also, I’ve been “researching” and saw some old posts with somewhat similar problems of “tearing”. I tried replicating the solution from them by changing the settings in nvidia-settings. For this I first had to reinstall the proprietary driver. First I tried getting it from rpmfusion, but this didn’t give the same options that the videos I saw mentioned to try. So I re installing the latest proprietary driver straight from Nvidia and still didn’t get the same options. Both ways I get far fewer options than can be seen in the videos. So no luck there.

Comment 11 Justin M. Forbes 2021-06-29 18:07:04 UTC
Unfortunately, I don't think anything in nvidia is going to make a difference. The reason this seems to be specific to nvidia laptops on the laptop panel, but not universal on external panels, and perists with both nouveau and the nvidia binary driver are because it actually has nothing to do with the nvidia chip at all.  Most dual mode laptops use Intel i915 for the display panel, and the nvidia driver allows work to be offloaded to the nvidia gpu and routed back through the i915 to reach the panel.  This allows them to save power for most computing, and only power up the nvidia chip when it is needed. HDMI is typically wired directly to the nvidia GPU with the assumption that you have a power outlet available if you have a monitor available most of the time. In fact, if you blacklisted the nouveau driver to install nvidia, you could remove the nvidia driver and keep nouveau blacklisted, and you likely would not notice any difference in your display at all.  I have looked a couple of times, and have seen some similar problems reported, but either unsolved, or solved with a patch that is already in the kernel, so isn't solving this particular case. You might get some traction filing a big with upstream: https://gitlab.freedesktop.org/drm/intel/-/issues/  If you do, please link the bug back here so I can track the progress.

Comment 12 nmvega 2021-06-29 18:17:36 UTC
(In reply to Justin M. Forbes from comment #11)
Hi Justin. Thank you. I can confirm what you say about laptop kind, as I similarly have a hybrid display laptop (Nvidia + Intel) experiencing this issue:

https://www.lenovo.com/us/en/laptops/ideapad/ideapad-y700-series/Ideapad-Y700-17/p/88IPY700622

Comment 13 Fer Sosa 2021-06-30 00:50:46 UTC
OK, so I went ahead and created an issue where you suggested. It's bug https://gitlab.freedesktop.org/drm/intel/-/issues/3714

Hope this helps.

Comment 14 nmvega 2021-07-02 21:07:43 UTC
I added to that issue, too: https://gitlab.freedesktop.org/drm/intel/-/issues/3714#note_980027

Comment 15 Fer Sosa 2021-07-03 17:17:12 UTC
(In reply to nmvega from comment #14)
> I added to that issue, too:
> https://gitlab.freedesktop.org/drm/intel/-/issues/3714#note_980027

Thanks



BTW, It looks like someone over on that forum found a solution. Sadly I'm not tech savvy enough to implement it myself. I'll copy past what they found here:




Geoffrey Brun @Spekadyon

Hello,
I got the same bug too, on a MSI Apache GE72 2QE, equipped with

CPU: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHzf
Discrete GPU: 3D controller: NVIDIA Corporation GM204M [GeForce GTX 965M] (rev a1)

This issue appeared before 5.12 release, the 5.11 branch is not affected. After some bisection, I was able to identify the commit responsible for this :

commit 2bbd6dba84d44219387df051a1c799b7bac46099
Author: Ville Syrjälä <ville.syrjala.com>
Date:   Thu Jan 7 20:20:25 2021 +0200

    drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

Edit: Reverting this commit on top of kernel 5.13 solves the issue.

Comment 16 Fer Sosa 2021-07-22 03:35:42 UTC
So, no movement recently. So I'll add a little something new.

Recently I tried a couple of new 5.14 kernels and no joy. To be specific they were:

5.14.0-0.rc1.20210714git40226a3d96ef.18.fc35

and

5.14.0-0.rc2.20210721git8cae8cd89f05.24.fc35

Comment 17 Paul 2021-07-27 13:35:01 UTC
(In reply to Fer Sosa from comment #15)
> (In reply to nmvega from comment #14)
> > I added to that issue, too:
> > https://gitlab.freedesktop.org/drm/intel/-/issues/3714#note_980027
> 
> Thanks
> 
> 
> 
> BTW, It looks like someone over on that forum found a solution. Sadly I'm
> not tech savvy enough to implement it myself. I'll copy past what they found
> here:
> 
> 
> 
> 
> Geoffrey Brun @Spekadyon
> 
> Hello,
> I got the same bug too, on a MSI Apache GE72 2QE, equipped with
> 
> CPU: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHzf
> Discrete GPU: 3D controller: NVIDIA Corporation GM204M [GeForce GTX 965M]
> (rev a1)
> 
> This issue appeared before 5.12 release, the 5.11 branch is not affected.
> After some bisection, I was able to identify the commit responsible for this
> :
> 
> commit 2bbd6dba84d44219387df051a1c799b7bac46099
> Author: Ville Syrjälä <ville.syrjala.com>
> Date:   Thu Jan 7 20:20:25 2021 +0200
> 
>     drm/i915: Try to use fast+narrow link on eDP again and fall back to the
> old max strategy on failure
> 
> Edit: Reverting this commit on top of kernel 5.13 solves the issue.

Can I ask why this commit hasn't been reverted? 5.13 is now live and thus the issue has carried over.

Comment 18 nmvega 2021-07-30 22:05:54 UTC
Dear RedHat Friends:

Will anyone be fixing this issue? We are unable to move forward without a fix.
Thank you in advance!

Comment 19 Justin M. Forbes 2021-08-04 12:24:40 UTC
Well, fixing the issue requires a fix be available upstream. I have been watching the bug and waiting for one. There was a test fix posted overnight, so waiting for feedback on that.

Comment 20 nmvega 2021-08-07 22:17:44 UTC
(In reply to Justin M. Forbes from comment #19)
> Well, fixing the issue requires a fix be available upstream. I have been
> watching the bug and waiting for one. There was a test fix posted overnight,
> so waiting for feedback on that.

Hi Justin:

Ah, okay. I understand.

FYI: The team that maintains the "Solus" Linux distribution, implemented the patch shown in the following discussion:

https://gitlab.freedesktop.org/drm/intel/-/issues/3714#note_1022319

Then, user @crom5 installed it on his laptop (via the "Solus" O/S updater). It fixed the issue for him. I have the same laptop model.

I don't know if the patch "diff" (in the URL above) is the one you're referring to, but I wanted to bring it to the teams attention.

Thank you for your assistance! =:)

Comment 21 Fer Sosa 2021-08-09 03:28:41 UTC
So apparently aside from the Solus update that who know who requested it, the guy how has been working on the bug in the feedestop site will request that the fix be integrated to the Ubuntu kernel. I don't know if that is feasible in the fedora kernel but I asked him if he could also request the inclusion in the fedora kernel. 

If there is any fedora kernel we should try please let us know Justin.

Comment 22 Fer Sosa 2021-08-09 03:28:57 UTC
So apparently aside from the Solus update that who know who requested it, the guy how has been working on the bug in the feedestop site will request that the fix be integrated to the Ubuntu kernel. I don't know if that is feasible in the fedora kernel but I asked him if he could also request the inclusion in the fedora kernel. 

If there is any fedora kernel we should try please let us know Justin.

Comment 23 Justin M. Forbes 2021-08-09 12:02:24 UTC
It is already in Fedora with the build done over the weekend, I just haven't been able to file it in an update yet because armv7 is causing issues on F33. In the meantime, feel free to grab https://koji.fedoraproject.org/koji/buildinfo?buildID=1815740 or just create a tmp directory and 'koji download-build --arch=x86_64 kernel-5.13.9-200.fc34 ; dnf update *.rpm'

Comment 24 Fer Sosa 2021-08-09 14:49:27 UTC
Hi Justin,

I'm kernel 5.13.9-200 now and it works great. Thank you for all your help.

Comment 25 nmvega 2021-08-09 15:18:39 UTC
Hi Justin, Fer:

This is great progress. Thank you both.

In my case, which is on Fedora-33, here is the formatted output of the commands that Justin mentioned above:

https://pastebin.com/raw/Wm4HjgTj

Notice the "No match for argument:" messages, as well as the missing "kmod-nvidia-5.13.6-200.fc34.x86_64" package. (Note: The "kmod-VirtualBox-5.13.6-100.fc33.x86_64" package is also missing, but that isn't strictly needed to right now =:)).

I'm not sure my display will start without the "kmod-nvidia" RPM.

@Fer, did you get this to work on Fedora-33. I'm not on Fedora-34 yet.

Thank you! =:)

Comment 26 Alexei Panov 2021-08-09 19:33:59 UTC
With update https://koji.fedoraproject.org/koji/buildinfo?buildID=1815740 works perfectly. Thanks a lot!

Comment 27 Fer Sosa 2021-08-09 19:58:17 UTC
Hi NMVega,

I think since you are on FC33 and the instruction are for FC34 you may have to edit Justin's commands the following way:

koji download-build --arch=x86_64 kernel-5.13.9-100.fc33 ; dnf update *.rpm


BTW, I didn't actually follow Justin's commands exactly because the first part also downloads the "debug" kernel, which I don't really want to install. So I first just went to koji and downloaded the specific kernel Justin told us about and installed the modules I needed/wanted (i.e. not the debug kernel and modules, etc.). In your case for FC33 the link for the specific kernel is: https://koji.fedoraproject.org/koji/buildinfo?buildID=1815741

Comment 28 nmvega 2021-08-09 20:22:35 UTC
Hi Fer:

With help from you and various developers at Freedesktop and Fedora (thank you), things have come a long way since our original conversation about this issue on YouTube:

https://youtu.be/0u_CA6saNFc -- \o/

Anyway, thanks the tip. I had tried that since my previous comment, and sadly got the following:

root@y700# koji download-build --arch=x86_64 kernel-5.13.9-100.fc33
No x86_64 packages available for kernel-5.13.9-100.fc33

root@y700#

Looking at that kernel's "build-state" here, -- https://koji.fedoraproject.org/koji/packageinfo?packageID=8 -- shows a "wrench" symbol as of this writing; so I suspect that that means it may not be built. I'm unsure.

@jforbes -- Is this correct?

Thank you!

Comment 29 Fer Sosa 2021-08-09 20:43:05 UTC
Hi NMVega,

You're right, I didn't actually look in the directory of the link I sent you, it's empty. Justin did mention that he was having problems with FC33 and arm processors. So I'm guessing he'll have that done in the near future. Just a little more patience.

Comment 30 Justin M. Forbes 2021-08-09 21:09:25 UTC
(In reply to Fer Sosa from comment #27)
> BTW, I didn't actually follow Justin's commands exactly because the first
> part also downloads the "debug" kernel, which I don't really want to
> install. So I first just went to koji and downloaded the specific kernel
> Justin told us about and installed the modules I needed/wanted (i.e. not the
> debug kernel and modules, etc.). In your case for FC33 the link for the
> specific kernel is:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1815741

So yes, it will download those packages (and you may not want to if bandwidth is an issue), but dnf update *.rpm will only install/update packages you already have installed and skip the rest. A 'dnf install' would grab it all, but update will only base on the installed packages.

(In reply to nmvega from comment #28)
> Looking at that kernel's "build-state" here, --
> https://koji.fedoraproject.org/koji/packageinfo?packageID=8 -- shows a
> "wrench" symbol as of this writing; so I suspect that that means it may not
> be built. I'm unsure.
> 
> @jforbes -- Is this correct?
> 
> Thank you!

Yes, this is correct, though I have been trying to get that build through for over 24 hours, with the current build going for over 9 hours. The x86_64 build is done though, so you can try 'koji download-task 73555370' to grab the x86_64 build from the current set. The build issues are koji issues, so the resulting kernel is going to be the same whenever it completes.

Comment 31 Fedora Update System 2021-08-09 21:21:36 UTC
FEDORA-2021-d81a932cb3 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d81a932cb3

Comment 32 nmvega 2021-08-09 21:36:54 UTC
(In reply to Justin M. Forbes from comment #30)

Hi Justin:

Thank you. I understood both comments you made above.

I'll download the RPMs with the "task" command that you provided, and then install them. I'll report back my display behavior after I reboot. Fingers crossed.

Thank you!

Comment 33 nmvega 2021-08-09 22:26:18 UTC
Hi Justin:

SUCCESS!

The following worked for me (which downloads and updates kernel RPMs for kernel "5.13.9-100.fc33.x86_64"):

root@y700# mkdir ~/TEMP123.d/ && cd ~/TEMP123.d/
root@y700# sudo koji download-task 73555370
root@y700# rm [List-of-Unneeded-RPMs]
root@y700# sudo dnf update ./*.rpm
root@y700# cd ~ && rm -rf ./TEMP123.d/

The display no longer wobbles. \o/

Probably by the time others read this BUG (if they run into this at all), the KOJI build issue will have been resolved and they can do a normal "sudo dnf -y update".

For completeness, my laptop model is "Lenovo y700-17isk" running Fedora-33 with kernel RPMs for "5.13.9-100.fc33.x86_64". Another user with the identical laptop model -- but running the SOLUS Linux distribution -- reported success with the same kernel modifications implemented there (in Fedora). I mentioned that in this comment (for completeness):

https://bugzilla.redhat.com/show_bug.cgi?id=1965645#c20

Thank you everyone who helped! =:)

Comment 34 Fedora Update System 2021-08-10 11:43:37 UTC
FEDORA-2021-43065274e4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-43065274e4

Comment 35 Fedora Update System 2021-08-10 15:47:28 UTC
FEDORA-2021-d81a932cb3 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-d81a932cb3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d81a932cb3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 36 Fedora Update System 2021-08-11 01:49:13 UTC
FEDORA-2021-43065274e4 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-43065274e4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-43065274e4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 37 Fedora Update System 2021-08-13 01:09:51 UTC
FEDORA-2021-43065274e4 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 38 Fedora Update System 2021-08-13 01:21:45 UTC
FEDORA-2021-d81a932cb3 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 39 soban 2021-08-13 21:12:18 UTC
Hi,

I am using fedora 34 kernel 5.13.9-200.fc34.x86_64 and still have the issue with shaking screen. Problem disappears after I change resolution of screen (next I can go back to my full screen resolution (2160 * 1440 (3:2))). Also I do not know it is relevant but when I try connect my laptop to external monitor using USB-C/VGA adapter, display goes black and I have to hard reset to restore responsiveness (maybe here it is just adapter fault, I do not know).

I am using Chuwi GemiBook with Intel Corporation GeminiLake [UHD Graphics 600].

Here's a link to the video of what it looks like in my case:

https://www.youtube.com/watch?v=re_6EwFHZ34&feature=youtu.be

Comment 40 Massimo Di Primio 2021-08-14 09:43:53 UTC
Hi,
On Fedora 33 seems working fine.
The system is a Laptop Lenovo Z70 with the following options:

 OS: Fedora 33 ThirtyThree
 Kernel: x86_64 Linux 5.13.9-100.fc33.x86_64
 Shell: bash 5.0.17
 Resolution: 1920x1080
 DE: MATE 1.24.3
 WM: Metacity (Marco)
 WM Theme: TraditionalOk
 GTK Theme: TraditionalOk [GTK2/3]
 Disk: 559G / 1.1T (51%)
 CPU: Intel Core i7-5500U @ 4x 3GHz [52.0°C]
 GPU: Intel Corporation HD Graphics 5500 (rev 09)
 RAM: 2240MiB / 15912MiB

Comment 41 Tadas 2021-08-18 19:56:09 UTC
Hi,

Still having issue after updating to latest kernel.

Lenovo P1
OS: Fedora 34 ThirtyFour
Kernel: x86_64 Linux 5.13.10-200.fc34.x86_64
CPU: Intel Core i7-10750H @ 12x 5GHz
GPU: Intel Corporation CometLake-H GT2 [UHD Graphics]
+ tlp disabled
+ i915.enable_psr=0

Comment 42 Fer Sosa 2021-08-19 22:23:56 UTC
Hi soban and Tadas,


First off, I'm not a dev, I'm the guy who opened the bug report. I just wanted to tell you that the bug, for those of us that it was resolved for, was fixed by a dev in https://gitlab.freedesktop.org/drm/intel/-/issues/3714#note_980027 . It's an Intel issue, not a Fedora issue, plus this bug is closed here. 


Also, the video that soban (I don't know if Tadas is the same) posted kinda looks different to the video I posted. I'm no expert, but I get the feeling that yours (soban) is a different bug and that's why it wasn't corrected with the fix that solved mine.


I think you need to open a new bug report at https://gitlab.freedesktop.org/drm/intel/-/issues/ and afterwards email ALL the devs there so that one of them pays attention to it. If Tadas can do a video too it would almost certainly help, together with both your dmesg files. Once this is done you should make a new bug report in bugzilla so that the Fedora devs can track the changes done by the Intel guys and be able to integrate the solution into the Fedora kernel.

Best of luck.

Comment 43 soban 2021-08-20 13:19:27 UTC
Thanks Fer Sosa for the response,

I created the topic on gitlab.freedesktop.org how you suggested.

If someone have the same issue as mine I encourage you to posting there for quicker solution this issue:

https://gitlab.freedesktop.org/drm/intel/-/issues/4012


Note You need to log in before you can comment on or make changes to this bug.