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