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 ;)

...

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.

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

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

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

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