Project

General

Profile

Bug #17199

Regression with some AMD GPU + Intel HD 4000 graphics (Ivy Bridge)

Added by goupille about 1 month ago. Updated 19 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Hardware support
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

a user reported that with tails 4.0 started on a dell z14 5423 with intel graphics clicking on the start tails button doesn't start tails but keeps going back to the greeter. The issue wasn't there with tails 3.16 and the user was able to start this tails 4.0 device from a dell E6440 with no errors.

I asked the user to try the various workarounds for intel graphics.

Intel HD Graphics 4000.png View - Intel HD Graphics 4000 info Tails 4.0 (50.7 KB) op_mb, 11/01/2019 09:27 PM


Related issues

Related to Tails - Bug #17228: Tails 4.0 greeter loads a second time when admin password added Confirmed

History

#1 Updated by intrigeri about 1 month ago

  • Category set to Hardware support
  • Assignee changed from intrigeri to goupille

Thanks. Please reassign to me once you've collected this info. Also, to work on this we'll probably need the output of tails-debugging-info (run from a text console, redirected to a file, copied to a USB stick, then shared with us somehow).

#3 Updated by intrigeri about 1 month ago

To debug this, I think we'll need the output of tails-debugging-info (run as root in a text console), otherwise I'm afraid there's no way to tell what's going on :/

#4 Updated by op_mb about 1 month ago

i've attached a screenshot from a system with Intel HD Graphics 4000
i cant reproduce the issue

#5 Updated by intrigeri about 1 month ago

  • Subject changed from regression with intel HD 4000 graphics to Regression with some Intel HD 4000 graphics (Ivy Bridge)

#6 Updated by goupille about 1 month ago

adding

 xorg-driver=intel

fixes the issue for that user (I still asked for the debugging info)

#7 Updated by goupille about 1 month ago

  • Assignee changed from goupille to intrigeri

I just resent you the debugging info you requested (the subject is tagged with #17199)

#8 Updated by intrigeri about 1 month ago

Hi @goupille!

goupille wrote:

adding xorg-driver=intel fixes the issue for that user

Interestingly, after they reported that, you asked them to try xorg-driver=modesetting. The OP obliged, so the debugging info we got is about the latter, not about xorg-driver=intel; interestingly, the modesetting driver also makes Tails work :) Maybe you made a typo when asking them the debugging info?

Anyway, this was super useful:

  • The kernel is 5.3.2-1~exp1 so that's probably Tails 4.0
  • That system has two GPUs, with vga_switcheroo doing its thing:
    • "00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09)"
    • "02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7550M/7570M/7650M] [1002:6841]"
  • With xorg-driver=modesetting, the Intel GPU is used by X.Org, because it's the default drm device; the AMD GPU is ignored because there's no support for multiple graphics cards there
  • Without extra boot options:
    • The radeon X.Org driver is used for the AMD GPU, and the modesetting X.Org driver is used for the Intel one.
    • The Greeter loads just fine so there's actually no X.Org hardware support issue here.
    • X.Org segfaults while logging in, during MAC spoofing, triggered by (II) config/udev: Adding drm device (/dev/dri/card1)

So I'm now almost convinced that this has nothing to do with GPU drivers, but rather, MAC spoofing breaks X.Org in some cases (possibly systems with multiple GPUs). I'll ask the OP to test with MAC spoofing disabled.

#9 Updated by intrigeri about 1 month ago

  • Subject changed from Regression with some Intel HD 4000 graphics (Ivy Bridge) to Regression with some AMD GPU + Intel HD 4000 graphics (Ivy Bridge)
  • Status changed from New to Confirmed

#10 Updated by intrigeri about 1 month ago

If my hunch is correct and the problem is caused by MAC spoofing running udevadm trigger, one option could be to exclude graphics devices from the trigger action, e.g. with --subsystem-nomatch=SUBSYSTEM or one of the related options.

#11 Updated by intrigeri 27 days ago

Disabling MAC spoofing does not fix the problem but I was slightly confused when I thought it would: the thing I believe could be breaking stuff here is not spoofing the MAC address per se, but rather the fact that our MAC spoofing implementation, based on blocking/unblocking network devices, triggers udevadm actions, regardless of whether MAC spoofing is enabled or not.

The logs I got this time suggest that systemd-logind is confused about the state of FDs (for /dev/dri/card{0,1} it passes to X.Org: when amnesia's X.Org starts, it gets passed paused FDs which makes it abort. I suspect that's because at least one of /dev/dri/card{0,1} seem to briefly disappear and come back again when we run udevadm trigger.

So one thing I'd like to try is to avoid triggering udev events for GPU devices.

#12 Updated by goupille 27 days ago

I don't know if it is related but we received an anonymous report (Bug report: 20c6669cc73aa96b4bcbf982a55b3d57) from a user with two gpu (Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] and [AMD/ATI] Mars [Radeon HD 8670A/8670M/8750M] [1002:6600]), saying that setting an administrator password in the Greeter prevents Tails to fully start (it keeps coming back to the Greeter when clicking on the "start tails" button)

when no administrator password is set, Tails starts without issues (hence the logs)

#13 Updated by intrigeri 19 days ago

I don't know if it is related but we received an anonymous report (Bug report: 20c6669cc73aa96b4bcbf982a55b3d57) from a user with two gpu (Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] and [AMD/ATI] Mars [Radeon HD 8670A/8670M/8750M] [1002:6600]), saying that setting an administrator password in the Greeter prevents Tails to fully start (it keeps coming back to the Greeter when clicking on the "start tails" button)

when no administrator password is set, Tails starts without issues (hence the logs)

Indeed, this could be related: setting an admin password could increase the chances that we win the systemd-logind vs. MAC spoofing vs. X.Org race condition I had a hunch about above.

So far we had reports of this class of problems affecting 2 users. If there are more, IMO this should become FT work.

#14 Updated by intrigeri 19 days ago

  • Related to Bug #17228: Tails 4.0 greeter loads a second time when admin password added added

#15 Updated by intrigeri 19 days ago

  • Assignee deleted (intrigeri)

#17228 has more info that is consistent with my current best theory.

Also available in: Atom PDF