Bug 1965645

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.

*** Bug 1971071 has been marked as a duplicate of this bug. ***

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

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.

(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

I just checked, the gpu of the old laptop is a GeForce GT 525M. OLD

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"

(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.

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.

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.

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.

(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

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.

I added to that issue, too: https://gitlab.freedesktop.org/drm/intel/-/issues/3714#note_980027

(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.

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

(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.

Dear RedHat Friends:

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

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.

(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! =:)

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.

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.

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'

Hi Justin,

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

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! =:)

With update https://koji.fedoraproject.org/koji/buildinfo?buildID=1815740 works perfectly. Thanks a lot!

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

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!

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.

(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.

FEDORA-2021-d81a932cb3 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d81a932cb3

(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!

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! =:)

FEDORA-2021-43065274e4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-43065274e4

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.

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.

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.

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.

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

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

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

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.

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