I am experiencing extreme screen tearing when running on Internal NVME SSD

[Molski]

@Aragorn

Well, it’s a no-brainer, really. When you’re running off the internal drive, there is more activity on that PCIe slot, and the temperature will be higher there, which could be the trigger.

When running from the external drive, the devices are sufficiently separated and there is no crosstalk.

This is what I was leaning towards before even reading it… I still am.

But that could mean several different things.

• Temperature: You must of outruled this? The temp shows in sensors?
• Power: Tried pcie_aspm=off?
• PCIe traffic: The USB device is much much slower obviously, so throwing in a bottleneck gets around this bizarre issue.
  This is tougher to troubleshoot.

[tracyanne]

@linux-aarhus

please say it didn’t occur from day one

Yes it works fine with the External USB SSD.

It did not occur from day one. It happened the day before I posted.

@linux-aarhus

You may also look at the module params for i915 an xe.

modinfo i915
modinfo xe

Given there are no issues when running via the USB SSD, without those , it’s hard to see how they would make a difference.

I’m also waiting to hear back from Slimbook.

@linux-aarhus

look at /etc/modprobe.d for any Intel and/or GPU related stuff.

that is an empty directory.

@Molski

But that could mean several different things.

• Temperature: You must of outruled this? The temp shows in sensors?
• Power: Tried pcie_aspm=off?
• PCIe traffic: The USB device is much much slower obviously, so throwing in a bottleneck gets around this bizarre issue.
  This is tougher to troubleshoot.

Yes temperature doen’t appearto be a factor.
Haven’t looked at pcie_aspm=off
Yes that is probably a factor. USB will be a lot slower.

Ok I tried ‘pcie_aspm=off’, it appeared to reduce the tearing. However after I did a system update, it failed to boot on the NVME. So now I have to fix that.

[Molski]

@tracyanne

Ok I tried ‘pcie_aspm=off’, it appeared to reduce the tearing.

That’s a little less scary..

Just from: https://wiki.archlinux.org/title/Solid_state_drive/NVMe#Troubleshooting

Other symptoms are Btrfs storage becoming read-only and Ext4 reporting I/O errors.

As a workaround, add the kernel parameter >nvme_core.default_ps_max_latency_us=0 to completely disable APST, or set a custom threshold to disable specific states.

If setting latency still does not works, try adding pcie_aspm=off and pcie_port_pm=off (as suggested by [17]). You may also need to disable NVMe and PCIe power saving measures within the BIOS.

Try the other ones too. These force the SSD to not enter any sleep states.

(This will affect battery. But we’re troubleshooting.)

[Teo]

What I do not understand - is it only in one window? How is this possible if it is hardware. It seems to me the lion to the left is intact but the shot is not very clear.

[Ronster]

I’ve been lurking this one, but after you post this screenshot i wanted to give my two cents.

A while ago i had a comparable issue with screen tearing. I’m not saying this applies to you, but maybe it will help.

My system was running fine back then and i started to get tearing after a system update. The problem was i hadn’t use Linux in a while, so i had Secure Boot enabled (not configured in any way). This made the update for graphic card driver bug out in a similar fashion like you are experiencing right now. The issue in my case was that i didn’t add any hardware to Secure Boot. The system kept working but there was tearing all over the place.

This does not explain why it works on your external drive.

[tracyanne]

@Teo

What I do not understand - is it only in one window?

No, that’s just an example. The application Windows (plural) break up… the Background image appears to bleed through, actually, the same thing happens with the Plasma Panels. There isn’t any breakup when it’s just the Background image.

@Ronster

This does not explain why it works on your external drive.

Unfortunately no. I am also not using (in)Secure Boot either. Standard UEFI with Manjaro… and in this case a fresh install on both the Internal and External SSDs

@Molski

That’s a little less scary..

I’ll look at your other options, as soon as I can get the computer to boot on the NVME again.

[tracyanne]

Well I don’t know where to go from here.
After the system failed to boot on the NVME, I decided the quickest way to get it into a bootable state was to simply re install.
So I re installed, and when I logged in there was no screen tearing. So I ran a full system update, rebooted, and the system is still stable with no tearing.

So far there appears to simply be no problem at all.

Given the original problem appeared, after a reboot of an install that had been functioning for 3 months, then continued to present after a reinstall, I cannot explain why yet another reinstall appears to have fixed the problem.

I am currently running on the NVME.

[linux-aarhus]

@linux-aarhus

I am thinking along the lines of

• executing a secure erase
• dd to write zeroes to the entire disk

when you reinstall the system - the files is never placed exactly where they were last time.

That is why I suggested zeroing disk earlier - this exact scenario where the file(s) are placed at a seemingly safe and sound place - but there is a tiny mismatch when the data is read - perhaps due to a dysfunctional memorycell.

nvme’s keep an internal record of damaged cells but they don’t relocate data.

You appear to be a die-hard ext4 user - I am no big fan of btrfs - but it is a belt and suspender file system and I do recognise/see how it may have been able to prevent the issue in the first place.

[tracyanne]

@linux-aarhus

You appear to be a die-hard ext4 user - I am no big fan of btrfs - but it is a belt and suspender file system and I do recognise/see how it may have been able to prevent the issue in the first place.

I will think on it. But for now it appears to be working.

[andreas85]

@tracyanne

So far there appears to simply be no problem at all.

Given the original problem appeared, after a reboot of an install that had been functioning for 3 months, then continued to present after a reinstall, I cannot explain why yet another reinstall appears to have fixed the problem.

A corrupted file (a library, for instance) within the file system—which is then used to generate the graphics—could very well have been the cause. The only remaining question is how that file became corrupted in the first place.

In this context, I would strongly advise keeping a close eye on the SSD’s file system for a while. If possible, use a file system that supports checksums (such as btrfs) and have those checksums verified periodically (e.g., using btrfs scrub).

How else could you possibly discover that your SSD is occasionally dropping a bit?

[tracyanne]

@andreas85

In this context, I would strongly advise keeping a close eye on the SSD’s file system for a while.

My thoughts exactly.

Thanks guys, Unfortunately, there appears to be no actual Solution.

[Molski]

@tracyanne

@andreas85

In this context, I would strongly advise keeping a close eye on the SSD’s file system for a while.

My thoughts exactly.

I third this motion!

@tracyanne

Partition:
  ID-1: / raw-size: 63.48 GiB size: 62.18 GiB (97.96%) used: 10.21 GiB (16.4%)
    fs: ext4 dev: /dev/sda2 maj-min: 8:2 label: N/A
    uuid: fced3a62-fe08-4b92-b6b1-ac0f6f2e1b49
  ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
    used: 328 KiB (0.1%) fs: vfat dev: /dev/sda1 maj-min: 8:1 label: N/A
    uuid: 5127-A586
  ID-3: /home raw-size: 832.58 GiB size: 818.44 GiB (98.30%)
    used: 14.38 GiB (1.8%) fs: ext4 dev: /dev/sda4 maj-min: 8:4 label: N/A
    uuid: c084f514-34a5-41ef-91e6-98c6aa025f18

This is one many of the places where btrfs really shines. If it becomes corrupted, you will know the microsecond you access it.

Not that this helps.

[tracyanne]

@Molski

This is one many of the places where btrfs really shines.

I will stay with ext4, I think.

I’ve used it for as long as it’s been around, and I trust it. If it ain’t broke don’t fix it.