Bug#956121: Blank screen on 2nd display using wayland

[Simon McVittie]

On Fri, 10 Apr 2020 at 13:21:41 +0200, Pierre Cheynier wrote:
> > Is this reproducible by upgrading/downgrading only libmutter-5-0 and
> > closely-related packages, without altering anything else?
> 
> Yes absolutely, knowing that upgrading libmutter-5-0 also upgrade, by
> dependency:
> gir1.2-mutter-5 libmutter-5-0

That's fine. Everything from the src:mutter source package is tied
together quite closely and upgrading them all as a batch is expected,
although whether you change the mutter binary package or not shouldn't
matter (it doesn't actually do very much).

So we definitely have:

src:mutter version 3.34.3-1: good
src:mutter version 3.34.4-1: not good

although this might be either a bug in mutter, or just mutter doing
something differently that triggers a lower-level issue.

> > Are you able to test this with mutter and gnome-shell 3.36.x from
> > experimental? We're close to uploading those to unstable.
> 
> Not right now, since I almost suceeded having an almost-operational
> working environment :), but I can provide you some feedback soon (let
> say 1 week?)

3.36.x should be in unstable, or even in testing, by then. You might
want to put your working 3.34.3 setup on "hold" in apt/aptitude for now.

> > You appear to have a dual-GPU system. Is the NVIDIA device completely
> > disabled, or are they both active via some sort of dual-GPU arrangement
> > like Bumblebee?

You didn't answer this. If the NVIDIA device is disabled, how did you
disable it?

> These setups are terrible.

Yes, dual-GPU seems to be really hard to get right. The graphics stack is
already a complicated dance involving the kernel, libdrm, Mesa, libmutter
and GNOME Shell; having two GPUs involved just makes that worse.

> Let me tell you that it's a mess if we consider all graphics +
> gnome-shell + plugins related logs :)

Yes it is, but it might be helpful to show us anyway.

If you're using GNOME Shell extensions, please test with them all disabled
and see whether that works (you can re-enable them afterwards).

> I noticed that I observe this during a "working" boot:
> ```
> avril 10 11:47:39 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 2
> avril 10 11:47:39 dell-m4700 kernel: DMAR: [DMA Read] Request device
> [00:1f.2] PASID ffffffff fault addr c9827000 [fault reason 06] PTE
> Read access is not set

If you run the lspci command (install pciutils if you don't already have
it), what device is 00:1f.2?

> But when having this non-working setup, I additionaly got this each
> 5s, following main screen blink, probably some kind of
> reinitialization (let say it's a side-effect?):
> ```
> avril 10 11:46:25 dell-m4700 kernel: dmar_fault: 191660 callbacks suppressed

That means part of the kernel tried to log 191660 lines, and the logging
subsystem wouldn't let it. That's a lot of logging!

> avril 10 11:46:25 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 3
> avril 10 11:46:25 dell-m4700 kernel: DMAR: [DMA Read] Request device
> [01:00.0] PASID ffffffff fault addr fc01e000 [fault reason 06] PTE
> Read access is not set
> avril 10 11:46:25 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 3
> avril 10 11:46:25 dell-m4700 kernel: DMAR: [DMA Read] Request device
> [01:00.0] PASID ffffffff fault addr fc045000 [fault reason 06] PTE
> Read access is not set
> avril 10 11:46:25 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 3
> avril 10 11:46:25 dell-m4700 kernel: DMAR: [DMA Read] Request device
> [01:00.0] PASID ffffffff fault addr fc06a000 [fault reason 06] PTE
> Read access is not set
> avril 10 11:46:25 dell-m4700 kernel: DMAR: DRHD: handling fault status reg 3

Similarly, what device is 01:00.0? It's on its own separate PCIE bus if I
understand correctly, which probably means it's either your Intel GPU or
NVIDIA GPU.

Searching for the log messages suggests that booting with

    intel_iommu=igfx_off

or

    intel_iommu=off

added to the kernel command line might help
(see also <https://bugs.debian.org/935270>, which was also on a Dell).

    smcv