[arch-general] External monitors are no longer detected (Intel graphics)
Hi, I'm using a Thinkpad T450s with Intel graphics. Yesterday, I could no longer connect external monitors via miniDP. They were not detected at all, either by xrandr in i3 or by sway (wayland). I didn't have time to dig out a VGA cable and try that, so I cannot rule out physical damage yet - I did try 2 monitors with different cables, both of which work with my wife's Thinkpad. Since wayland doesn't make a difference, I'm thinking maybe something broke with the (my?) drivers? Is there any other possibility apart from physical damage, and what do I try next? Cheers, Bennett
On 07/02/2019 01:01 AM, Bennett Piater wrote:
Hi, I'm using a Thinkpad T450s with Intel graphics.
Yesterday, I could no longer connect external monitors via miniDP. They were not detected at all, either by xrandr in i3 or by sway (wayland). I didn't have time to dig out a VGA cable and try that, so I cannot rule out physical damage yet - I did try 2 monitors with different cables, both of which work with my wife's Thinkpad.
Since wayland doesn't make a difference, I'm thinking maybe something broke with the (my?) drivers? Is there any other possibility apart from physical damage, and what do I try next?
Cheers, Bennett
Have you checked the troubleshooting options on https://wiki.archlinux.org/index.php/Intel_graphics. I also recall an intel issue with recent kernels, but can't put my hand on a link. The problems experienced with some are listed in the wiki. -- David C. Rankin, J.D.,P.E.
On Tuesday, 2 July 2019, 09:46:02 CEST you wrote:
On 07/02/2019 01:01 AM, Bennett Piater wrote:
Hi, I'm using a Thinkpad T450s with Intel graphics.
Yesterday, I could no longer connect external monitors via miniDP. They were not detected at all, either by xrandr in i3 or by sway (wayland). I didn't have time to dig out a VGA cable and try that, so I cannot rule out physical damage yet - I did try 2 monitors with different cables, both of which work with my wife's Thinkpad.
Since wayland doesn't make a difference, I'm thinking maybe something broke with the (my?) drivers? Is there any other possibility apart from physical damage, and what do I try next?
Cheers, Bennett
Have you checked the troubleshooting options on https://wiki.archlinux.org/index.php/Intel_graphics. I also recall an intel issue with recent kernels, but can't put my hand on a link. The problems experienced with some are listed in the wiki.
There are *some* issues with intel gpu's and recent kernels. I can't use multiple monitors in most of the cases as the i915 module misinterpret possible resolutions, for example. https://bbs.archlinux.org/viewtopic.php?id=246230 https://bugzilla.redhat.com/show_bug.cgi?id=1570392 https://intel-gfx-ci.01.org/cibuglog/open_bugs.html I'm stuck on aur/linux-lts49 on my Zotac CI547 in the meanwhile as everything works there. But better than nothing - or 1024x768 ;)
Have you checked the troubleshooting options on https://wiki.archlinux.org/index.php/Intel_graphics. I also recall an intel issue with recent kernels, but can't put my hand on a link. The problems experienced with some are listed in the wiki.
There are *some* issues with intel gpu's and recent kernels. I can't use multiple monitors in most of the cases as the i915 module misinterpret possible resolutions, for example.
https://bbs.archlinux.org/viewtopic.php?id=246230 https://bugzilla.redhat.com/show_bug.cgi?id=1570392 https://intel-gfx-ci.01.org/cibuglog/open_bugs.html
I'm stuck on aur/linux-lts49 on my Zotac CI547 in the meanwhile as everything works there. But better than nothing - or 1024x768 ;)
Thanks guys. The wiki doesn't list my exact issue, so I'll try booting into linux-lts when I get home and see if that helps. Cheers, Bennett
There are *some* issues with intel gpu's and recent kernels. I can't use multiple monitors in most of the cases as the i915 module misinterpret possible resolutions, for example. Also, I remember some issue with external monitors on this list not long ago: https://lists.archlinux.org/pipermail/arch-general/2019-June/046539.html Even if the OP suspected a faulty HDMI port, this might still be related.
There are *some* issues with intel gpu's and recent kernels. I can't use multiple monitors in most of the cases as the i915 module misinterpret possible resolutions, for example. Also, I remember some issue with external monitors on this list not long ago: https://lists.archlinux.org/pipermail/arch-general/2019-June/046539.html Even if the OP suspected a faulty HDMI port, this might still be related.
That was me. Try the following: set the boot Display to HDMI in the bios / Uefi. If it shows stuff (Lenovo logo or bios menu if invoked) it’s not the hardware. For me the issue fixed itself after a day without explanation. — Flo
Regarding kernel versions: I also had noticed instabilities (more errors than usual in dmesg from drm and i915, weird GL/compositing glitches) on my HD4400 Intel with one external monitor and laptop display starting with 5.1.x. I've so far remained on 5.0.3 and have not debugged in depth due to a lack of time, but the issues definitely started after 5.0.3.
On Tuesday, July 2, 2019 9:59:57 AM CEST Oliver Jaksch via arch-general wrote:
There are *some* issues with intel gpu's and recent kernels. I can't use multiple monitors in most of the cases as the i915 module misinterpret possible resolutions, for example.
https://bbs.archlinux.org/viewtopic.php?id=246230 https://bugzilla.redhat.com/show_bug.cgi?id=1570392 https://intel-gfx-ci.01.org/cibuglog/open_bugs.html
I'm stuck on aur/linux-lts49 on my Zotac CI547 in the meanwhile as everything works there. But better than nothing - or 1024x768 ;)
I rebooted into linux-lts (4.19.56-1-lts) and everything works. I guess I'll stick with that for the time being. This is exciting - I never actually needed my fallback LTS bootloader entry before! :D Should I open a bug? Cheers, Bennett
On Tuesday, 2 July 2019, 17:16:45 CEST you wrote:
On Tuesday, July 2, 2019 9:59:57 AM CEST Oliver Jaksch via arch-general wrote:
There are *some* issues with intel gpu's and recent kernels. I can't use multiple monitors in most of the cases as the i915 module misinterpret possible resolutions, for example.
https://bbs.archlinux.org/viewtopic.php?id=246230 https://bugzilla.redhat.com/show_bug.cgi?id=1570392 https://intel-gfx-ci.01.org/cibuglog/open_bugs.html
I'm stuck on aur/linux-lts49 on my Zotac CI547 in the meanwhile as everything works there. But better than nothing - or 1024x768 ;)
I rebooted into linux-lts (4.19.56-1-lts) and everything works. I guess I'll stick with that for the time being. This is exciting - I never actually needed my fallback LTS bootloader entry before! :D
Glad that this (4.19 in your case) works for you, too.
Should I open a bug?
Good idea in general. But where? Seems that this is Intels' thing again and their list of open bugs is already extensive :( - Oliver
On 2019-07-03 06:38, Oliver Jaksch via arch-general wrote:
Glad that this (4.19 in your case) works for you, too.
Good idea in general. But where? Seems that this is Intels' thing again and their list of open bugs is already extensive :(
I opened an Arch bug so we can track it: https://bugs.archlinux.org/task/63079 The maintainers can report it further upstream, they know where - that's what they are for :) Cheers, Bennett Btw., I saw a bug for the wireless issue on the tracker, so that is reported as well.
On Wednesday, 3 July 2019, 09:25:46 CEST you wrote:
I opened an Arch bug so we can track it: https://bugs.archlinux.org/task/63079
The maintainers can report it further upstream, they know where - that's what they are for :)
Thanks, well done, Bennett! And I took that tracking URL to my bbs post to track that tracking track ... um, need some coffe :) Prost! - Oliver
On Wed, 03 Jul 2019 09:25:46 +0200, Bennett Piater wrote:
I opened an Arch bug so we can track it: https://bugs.archlinux.org/task/63079
The maintainers can report it further upstream, they know where - that's what they are for :)
Hi, since I didn't follow this thread close enough, I don't know if this is an Arch or upstream related issue. However, it's crass if you consider it to be most likely an upstream bug and you think somebody else should do your job. "Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post this in the Arch bug tracker, so both Arch developers and users are made aware of it." - https://wiki.archlinux.org/index.php/Bug_reporting_guidelines#Upstream_or_Ar... Regards, Ralf
On 2019-07-03 09:51, Ralf Mardorf via arch-general wrote:
On Wed, 03 Jul 2019 09:25:46 +0200, Bennett Piater wrote:
I opened an Arch bug so we can track it: https://bugs.archlinux.org/task/63079
The maintainers can report it further upstream, they know where - that's what they are for :)
Hi,
since I didn't follow this thread close enough, I don't know if this is an Arch or upstream related issue. However, it's crass if you consider it to be most likely an upstream bug and you think somebody else should do your job.
"Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post this in the Arch bug tracker, so both Arch developers and users are made aware of it." - https://wiki.archlinux.org/index.php/Bug_reporting_guidelines#Upstream_or_Ar...
Regards, Ralf
To clarify: I did not find an upstream bug, and I don't know that this is an upstream issue.
On Wed, 03 Jul 2019 09:58:48 +0200, Bennett Piater wrote:
On 2019-07-03 09:51, Ralf Mardorf via arch-general wrote:
On Wed, 03 Jul 2019 09:25:46 +0200, Bennett Piater wrote:
I opened an Arch bug so we can track it: https://bugs.archlinux.org/task/63079
The maintainers can report it further upstream, they know where - that's what they are for :)
Hi,
since I didn't follow this thread close enough, I don't know if this is an Arch or upstream related issue. However, it's crass if you consider it to be most likely an upstream bug and you think somebody else should do your job.
"Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post this in the Arch bug tracker, so both Arch developers and users are made aware of it." - https://wiki.archlinux.org/index.php/Bug_reporting_guidelines#Upstream_or_Ar...
Regards, Ralf
To clarify: I did not find an upstream bug, and I don't know that this is an upstream issue.
You could be the first one reporting it upstream. My impression when reading this thread is, that those participating in this thread have got the impression, that it is an upstream bug. The Wiki also mentions, in bold letters: "If Arch is not responsible for a bug, the problem will not be solved by reporting the bug to Arch developers." Keep in mind that you suffer from this bug. If a maintainer doesn't experience this bug, the maintainer hardly can report the bug upstream and in the end you are the one who is affected, if the bug will never get fixed. My intention isn't to teach you to follow rules. I don't care at all if you do or do not. I only want to inform you, that unlikely something will happen, if a bug is reported at the wrong place.
On 2019-07-03 10:24, Ralf Mardorf via arch-general wrote:
Hi,
since I didn't follow this thread close enough, I don't know if this is an Arch or upstream related issue. However, it's crass if you consider it to be most likely an upstream bug and you think somebody else should do your job.
"Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post this in the Arch bug tracker, so both Arch developers and users are made aware of it." - https://wiki.archlinux.org/index.php/Bug_reporting_guidelines#Upstream_or_Ar...
Regards, Ralf
To clarify: I did not find an upstream bug, and I don't know that this is an upstream issue.
You could be the first one reporting it upstream. My impression when reading this thread is, that those participating in this thread have got the impression, that it is an upstream bug.
The Wiki also mentions, in bold letters: "If Arch is not responsible for a bug, the problem will not be solved by reporting the bug to Arch developers."
Keep in mind that you suffer from this bug. If a maintainer doesn't experience this bug, the maintainer hardly can report the bug upstream and in the end you are the one who is affected, if the bug will never get fixed.
My intention isn't to teach you to follow rules. I don't care at all if you do or do not. I only want to inform you, that unlikely something will happen, if a bug is reported at the wrong place.
Thanks, I'm always willing to learn. At the very least, now other archers can easily find out about the bug. When I have more time, I'll try if I can find out more in dmesg or something. Cheers, Bennett
On 7/3/19 3:58 AM, Bennett Piater wrote:
To clarify: I did not find an upstream bug, and I don't know that this is an upstream issue.
It is an upstream bug - peraps my previous email didn't get through - will quote it again - sorry if its a dup: ------- On 7/2/19 1:48 PM, Genes Lists via arch-general wrote:> Check youor mesages and look for EDC asset. There is a fix teed up which may help your case. I have seen this "EDC assert" issue with 8265 [1] and the fix is given in comment #42. I have tested it on kernel 5.2-rc7 and works fine. This impacts all pre-9000 intel wifi cards. This will NOT make it into 5.2, as Emmanual G points out, as its late in the cycle; presumably will be in 5.2.1 and 5.3. A work around you might try is to add this iwlwifi option - then reboot. # cat >> /etc/modprobe.d/iwlwifi.conf options iwlwifi swcrypto=1 regards, gene [1] https://bugzilla.kernel.org/show_bug.cgi?id=203315 -------
On Wednesday, July 3, 2019 2:59:01 PM CEST Genes Lists via arch-general wrote:
On 7/3/19 3:58 AM, Bennett Piater wrote:
To clarify: I did not find an upstream bug, and I don't know that this is an upstream issue.
It is an upstream bug - peraps my previous email didn't get through - will quote it again - sorry if its a dup:
------- On 7/2/19 1:48 PM, Genes Lists via arch-general wrote:>
Check youor mesages and look for EDC asset. There is a fix teed up which may help your case.
I have seen this "EDC assert" issue with 8265 [1] and the fix is given in comment #42. I have tested it on kernel 5.2-rc7 and works fine. This impacts all pre-9000 intel wifi cards.
This will NOT make it into 5.2, as Emmanual G points out, as its late in the cycle; presumably will be in 5.2.1 and 5.3.
A work around you might try is to add this iwlwifi option - then reboot.
# cat >> /etc/modprobe.d/iwlwifi.conf options iwlwifi swcrypto=1
regards,
gene
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203315 -------
I was talking about external monitors not working, you are talking about wifi cards. Herzlich, Bennett
On 7/3/19 9:31 AM, Bennett Piater wrote:
I was talking about external monitors not working, you are talking about wifi cards.
You're right sorry - I replied to wrong email - meant to be to this. It should have been a new thread as different topic. On 7/2/19 12:25 PM, Stanislav N. aka pztrn via arch-general wrote:
Not only GPUs, but also WiFi cards. Got 8265 on Thinkpad T480 and 5G speeds are awful. When you're trying to download via 5G network something big - connection interrupts and won't come back until NetworkManager is restarted, also there are plenty of errors in dmesg. All fine on 5.0.x and LTS kernel (4.19.x), only 5.1.x are affected.
I let rkhunter running around once a week. There were nothing since many months. But today it's report complains about */lib64/libkeyutils.so.1.9* and therefore other tools they're (seems to be) using this SO. The SO matches the one from 'core/keyutils 1.6.1-1' in size and hash. I've uploaded the SO to some "we scan it all" AV sites, but none of them found anything. Should I/we be worried? Anything else I can do? Or is this a false alarm and the warnings are somewhat okay because of the package's nature ("Linux Key Management Utilities")?
Warning: Checking for possible rootkit files and directories [ Warning ] Found file '/lib/libkeyutils.so.1.9'. Possible rootkit: Sniffer component Found file '/lib64/libkeyutils.so.1.9'. Possible rootkit: Sniffer component Found file '/usr/lib/libkeyutils.so.1.9'. Possible rootkit: Sniffer component Found file '/usr/lib64/libkeyutils.so.1.9'. Possible rootkit: Sniffer component
Warning: The following processes are using suspicious files: Command: (sd-pam) UID: 1001 PID: 944 Pathname: Possible Rootkit: Spam tool component Command: NetworkManager UID: 0 PID: 381 Pathname: Possible Rootkit: Spam tool component Command: NetworkManager UID: 385 PID: 381 Pathname: 3166425 Possible Rootkit: Spam tool component Command: NetworkManager UID: 387 PID: 381 Pathname: 3166425 Possible Rootkit: Spam tool component Command: Xorg UID: 0 PID: 512 Pathname: Possible Rootkit: Spam tool component [...]
On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch via arch-general wrote:
I let rkhunter running around once a week. There were nothing since many months. But today it's report complains about */lib64/libkeyutils.so.1.9* and therefore other tools they're (seems to be) using this SO.
The SO matches the one from 'core/keyutils 1.6.1-1' in size and hash. I've uploaded the SO to some "we scan it all" AV sites, but none of them found anything.
Should I/we be worried? Anything else I can do? Or is this a false alarm and the warnings are somewhat okay because of the package's nature ("Linux Key Management Utilities")?
Warning: Checking for possible rootkit files and directories [ Warning ] Found file '/lib/libkeyutils.so.1.9'. Possible rootkit: Sniffer component Found file '/lib64/libkeyutils.so.1.9'. Possible rootkit: Sniffer component Found file '/usr/lib/libkeyutils.so.1.9'. Possible rootkit: Sniffer component Found file '/usr/lib64/libkeyutils.so.1.9'. Possible rootkit: Sniffer component
Warning: The following processes are using suspicious files: Command: (sd-pam) UID: 1001 PID: 944 Pathname: Possible Rootkit: Spam tool component Command: NetworkManager UID: 0 PID: 381 Pathname: Possible Rootkit: Spam tool component Command: NetworkManager UID: 385 PID: 381 Pathname: 3166425 Possible Rootkit: Spam tool component Command: NetworkManager UID: 387 PID: 381 Pathname: 3166425 Possible Rootkit: Spam tool component Command: Xorg UID: 0 PID: 512 Pathname: Possible Rootkit: Spam tool component [...]
No, those libraries are used for key manipulation, that's why rkhunter thinks that they might be sniffer. If you are worried you can check the sources. https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
Am 20.08.19 um 10:00 schrieb Filipe Laíns via arch-general:
On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch via arch-general wrote:
I let rkhunter running around once a week. There were nothing since many months. But today it's report complains about */lib64/libkeyutils.so.1.9* and therefore other tools they're (seems to be) using this SO.
... No, those libraries are used for key manipulation, that's why rkhunter thinks that they might be sniffer.
In this particular case the filename was apparently used by a rootkit in 2013 and it was blacklisted. Now the legitimate owner of the libkeyutils filenames has reached the blacklisted version number. I don't know which of the two possibilities it is in your case. https://bugs.archlinux.org/task/63369 https://www.webhostingtalk.com/showthread.php?t=1235797
On Tue, 20 Aug 2019 10:15:58 +0200, ProgAndy wrote:
Am 20.08.19 um 10:00 schrieb Filipe Laíns via arch-general:
On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch wrote: No, those libraries are used for key manipulation, that's why rkhunter thinks that they might be sniffer.
In this particular case the filename was apparently used by a rootkit in 2013
If a file name should be a pointer to a {false,} positive, it still not necessarily is a {false,} positive. rkhunter probably not only checks file names, if at all. https://sourceforge.net/projects/rkhunter/support
On Tue, 2019-08-20 at 10:15 +0200, ProgAndy wrote:
Am 20.08.19 um 10:00 schrieb Filipe Laíns via arch-general:
On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch via arch-general wrote:
I let rkhunter running around once a week. There were nothing since many months. But today it's report complains about */lib64/libkeyutils.so.1.9* and therefore other tools they're (seems to be) using this SO.
... No, those libraries are used for key manipulation, that's why rkhunter thinks that they might be sniffer.
In this particular case the filename was apparently used by a rootkit in 2013 and it was blacklisted. Now the legitimate owner of the libkeyutils filenames has reached the blacklisted version number. I don't know which of the two possibilities it is in your case.
https://bugs.archlinux.org/task/63369 https://www.webhostingtalk.com/showthread.php?t=1235797
The sources are pulled from [1] and signed by David Howells (Redhat) so I am pretty inclined to trust them. I did not, however, inspect the sources myself so I can give any guarantees. [1] https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git Thanks, Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
On Tue, 2019-08-20 at 09:31 +0100, Filipe Laíns via arch-general wrote:
so I can give any guarantees *I can't
Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
On Tuesday, 20 August 2019, 10:15:58 CEST you wrote:
Am 20.08.19 um 10:00 schrieb Filipe Laíns via arch-general:
On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch via arch-general wrote:
I let rkhunter running around once a week. There were nothing since many months. But today it's report complains about */lib64/libkeyutils.so.1.9* and therefore other tools they're (seems to be) using this SO.
...
No, those libraries are used for key manipulation, that's why rkhunter thinks that they might be sniffer.
In this particular case the filename was apparently used by a rootkit in 2013 and it was blacklisted. Now the legitimate owner of the libkeyutils filenames has reached the blacklisted version number. I don't know which of the two possibilities it is in your case.
https://bugs.archlinux.org/task/63369 https://www.webhostingtalk.com/showthread.php?t=1235797
Thanks to all. I think the URLs Filipe has posted are the most expressive part. Let's hope that this really is a false alarm coming from the past. - Oliver
On 8/20/19 5:58 AM, Oliver Jaksch via arch-general wrote:
On Tuesday, 20 August 2019, 10:15:58 CEST you wrote:
Am 20.08.19 um 10:00 schrieb Filipe Laíns via arch-general:
On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch via arch-general wrote:
I let rkhunter running around once a week. There were nothing since many months. But today it's report complains about */lib64/libkeyutils.so.1.9* and therefore other tools they're (seems to be) using this SO.
...
No, those libraries are used for key manipulation, that's why rkhunter thinks that they might be sniffer.
In this particular case the filename was apparently used by a rootkit in 2013 and it was blacklisted. Now the legitimate owner of the libkeyutils filenames has reached the blacklisted version number. I don't know which of the two possibilities it is in your case.
https://bugs.archlinux.org/task/63369 https://www.webhostingtalk.com/showthread.php?t=1235797
Thanks to all. I think the URLs Filipe has posted are the most expressive part. Let's hope that this really is a false alarm coming from the past. - Oliver
If you're in doubt, you can also try chkrootkit. When dealing with potential false positives, it sometimes helps to try more than one tool. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On Tue, 2019-08-20 at 08:33 +0200, Oliver Jaksch via arch-general wrote:
Should I/we be worried?
Hi Oliver, if something conceivably harmful is found you should take care. If you wouldn't, then why are you using it at all? If proprietary software would detect something you suspect to be a false positive, you would attach it to a report you sent to the company, usually those companies provide an internet channel to upload such files. The company then would take a look at those files. Nobody can tell from the warnings you get when running rkhunter, if it is or isn't a false positive. Even if those files are known to be false positives when not being infected, they still could be infected on your machine. Probably rkhunter provides support channels, too. [rocketmouse@archlinux ~]$ pacman -Si rkhunter | grep URL URL : http://rkhunter.sourceforge.net/ How about https://sourceforge.net/p/rkhunter/_list/tickets ? Regards, Ralf
02.07.2019 12:59, Oliver Jaksch via arch-general пишет:
On Tuesday, 2 July 2019, 09:46:02 CEST you wrote:
On 07/02/2019 01:01 AM, Bennett Piater wrote:
Hi, I'm using a Thinkpad T450s with Intel graphics.
Yesterday, I could no longer connect external monitors via miniDP. They were not detected at all, either by xrandr in i3 or by sway (wayland). I didn't have time to dig out a VGA cable and try that, so I cannot rule out physical damage yet - I did try 2 monitors with different cables, both of which work with my wife's Thinkpad.
Since wayland doesn't make a difference, I'm thinking maybe something broke with the (my?) drivers? Is there any other possibility apart from physical damage, and what do I try next?
Cheers, Bennett
Have you checked the troubleshooting options on https://wiki.archlinux.org/index.php/Intel_graphics. I also recall an intel issue with recent kernels, but can't put my hand on a link. The problems experienced with some are listed in the wiki.
There are *some* issues with intel gpu's and recent kernels. I can't use multiple monitors in most of the cases as the i915 module misinterpret possible resolutions, for example.
Not only GPUs, but also WiFi cards. Got 8265 on Thinkpad T480 and 5G speeds are awful. When you're trying to download via 5G network something big - connection interrupts and won't come back until NetworkManager is restarted, also there are plenty of errors in dmesg. All fine on 5.0.x and LTS kernel (4.19.x), only 5.1.x are affected. -- With best regards, Stanislav N. aka pztrn. https://pztrn.name Matrix: @pztrn:pztrn.name Telegram: @pztrn
Not only GPUs, but also WiFi cards. Got 8265 on Thinkpad T480 and 5G speeds are awful. When you're trying to download via 5G network something big - connection interrupts and won't come back until NetworkManager is restarted, also there are plenty of errors in dmesg. All fine on 5.0.x and LTS kernel (4.19.x), only 5.1.x are affected.
Check youor mesages and look for EDC asset. There is a fix teed up which may help your case. I have seen this "EDC assert" issue with 8265 [1] and the fix is given in comment #42. I have tested it on kernel 5.2-rc7 and works fine. This impacts all pre-9000 intel wifi cards. This will NOT make it into 5.2, as Emmanual G points out, as its late in the cycle; presumably will be in 5.2.1 and 5.3. A work around you might try is to add this iwlwifi option - then reboot. # cat >> /etc/modprobe.d/iwlwifi.conf options iwlwifi swcrypto=1 regards, gene [1] https://bugzilla.kernel.org/show_bug.cgi?id=203315
participants (12)
-
Bennett Piater
-
brent s.
-
David C. Rankin
-
Filipe Laíns
-
Florian Wehner
-
Genes Lists
-
Jens John
-
L. Rose
-
Oliver Jaksch
-
ProgAndy
-
Ralf Mardorf
-
Stanislav N. aka pztrn