switcheroo-control fails to detect multi-gpu system

[Anton Sudak]

switcheroo-control fails to detect multi-gpu system. Running programs using discrete card still works using DRI_PRIME variable, but gnome-sell option to launch app using discrete gpu is missing. Logs contain following record:

switcheroo-control could not query vga_switcheroo status: Operation not permitted

I'm not sure that the problem is in switcheroo-control package itself, it might be somwhere deeper.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: switcheroo-control 1.2-1
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: GNOME
Date: Fri May 4 00:24:35 2018
InstallationDate: Installed on 2013-12-27 (1588 days ago)
InstallationMedia: Ubuntu-GNOME 13.10 "Saucy Salamander" - Release amd64 (20131017)
SourcePackage: switcheroo-control
UpgradeStatus: Upgraded to bionic on 2018-04-13 (20 days ago)

[julien.enche (julien.enche-redhat-bugs)]

Description of problem:

On my Optimus laptop, on a fresh boot, the switcheroo-control service does not start correctly and shows this status:

systemctl status switcheroo-control.service
● switcheroo-control.service - Switcheroo Control Proxy service
   Loaded: loaded (/usr/lib/systemd/system/switcheroo-control.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Restarting it manually with systemctl restart switcheroo-control.service makes it work fine until the next reboot.

Version-Release number of selected component (if applicable):
switcheroo-control-1.1-2.fc26

Additional information:
I'm not using nvidia proprietary driver.

00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
01:00.0 3D controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)

[dele604 (dele604-redhat-bugs)]

Created attachment 1383341
systemctl status switcheroo-control.service

[dele604 (dele604-redhat-bugs)]

Have the same issue.

Restarting manually won't work.

sudo cat /sys/kernel/debug/vgaswitcheroo/switch
throws 'Operation not permitted.'

Version:
switcheroo-control.x86_64 1.1-4.fc27
xorg-x11-drv-nouveau.x86_64 1:1.0.15-3.fc27
xorg-x11-drv-intel.x86_64 2.99.917-31.20171025.fc27

[bnocera (bnocera-redhat-bugs)]

SELinux warnings?

[dele604 (dele604-redhat-bugs)]

(In reply to Bastien Nocera from comment #3)
> SELinux warnings?

Selinux is enforced, no warnings.

Service is able to start after disabling Secure Boot in bios.

[bnocera (bnocera-redhat-bugs)]

I'm going to say this is a kernel problem then.

[labbott (labbott-redhat-bugs)]

As it stands, this is working as expected. When secureboot is on, debugfs is locked down. Per the patch, "Normal device interaction should be done through configfs or a miscdev, not debugfs." I think something needs to be done for vgaswitcheroo for secureboot.

[bnocera (bnocera-redhat-bugs)]

*** Bug 1543427 has been marked as a duplicate of this bug. ***

[dannymrt1 (dannymrt1-redhat-bugs)]

This makes the option "Launch using Dedicated Graphics Card" in Gnome's right click menu disappear. So, to make use of the dGPU, I can only launch apps from terminal with the prefix, DRI_PRIME=1.

I'm on 4.15.4-300.fc27.x86_64.

[steve.tcmg (steve.tcmg-redhat-bugs)]

Can confirm this.

The service doesn't run on boot and restarting it produces the exact same error.

Running Fedora 27 up to date with 4.15.10-300.fc27.x86_64 and secure boot and hybrid graphics (intel + nvidia).

[bcotton (bcotton-redhat-bugs)]

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[steve.tcmg (steve.tcmg-redhat-bugs)]

This affects Fedora 27 too. Please update the ticket.

[sebastian4842 (sebastian4842-redhat-bugs)]

Can confirm that witcheroo-control service does not start correctly, but as soon as I disable secure boot it works fine and brings the menu entry "Launch using Dedicated Graphics Card" on Gnome back.

[steve.tcmg (steve.tcmg-redhat-bugs)]

Correct, but that's just a workaround right ?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[mtvoid (mtvoid)]

See https://github.com/hadess/switcheroo-control/issues/12

The bug occurs because switcheroo-control tries to query /sys/kernel/debug/vgaswitcheroo/switch, which is prevented under recent kernels running with Secure Boot enabled, as they lock down access to debugfs. Until the kernel is fixed to provide an alternative method to query vgaswitcheroo information that'll work when booted under Secure Boot and switcheroo-control is updated to use the new method, disabling Secure Boot is the only way to restore functionality.

[malarkannan.p (malarkannan.p-redhat-bugs)]

Yup, I can confirm it affects 28 too.

[mat.booth (mat.booth-redhat-bugs)]

(In reply to Laura Abbott from comment #6)
> As it stands, this is working as expected. When secureboot is on, debugfs is
> locked down. Per the patch, "Normal device interaction should be done
> through configfs or a miscdev, not debugfs." I think something needs to be
> done for vgaswitcheroo for secureboot.

So this should be re-assigned back to switcheroo then?

[labbott (labbott-redhat-bugs)]

not quite. It should probably be tracked under the kernel for now since it's secure boot related. Really if we're going to have a service relying on this it shouldn't be in debugfs anyway.

[jforbes (jforbes-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.

Fedora 28 has now been rebased to 4.17.7-200.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

[sebastian4842 (sebastian4842-redhat-bugs)]

The problem is still persisten with the newer kernel (4.17.7-200.fc28.x86_64).

[ozp (ozp)]

and how to disable secure boot ?

[rick.2889 (rick.2889-redhat-bugs)]

This also happens on a Zenbook UX510UX with GeForce 950M.

In dmesg, there is this output:
[ 5.411221] Lockdown: switcheroo-cont: debugfs is restricted; see man kernel_lockdown.7

As mentioned before, disabling secure boot fixes this. Understandably, since enabling secure boot enforces kernel lockdown mode and thus debugfs restrictions.

Switcheroo-control seems to query a specific path to check the switcheroo status:
https://github.com/hadess/switcheroo-control/blob/master/src/switcheroo-control.c#L26
"/sys/kernel/debug/vgaswitcheroo/switch"

Kernel lockdown mode seems to completely prohibit the use of debugfs so perhaps we need something to change in switcheroo itself, to have its status available via /proc maybe.

[peregrine (andrej1741)]

Seems this bug affects me even when uefi boot disabled in my bios. Or maybe i have another bug. 396 driver from ppa didn't fix that problem. Before I change default cart with sudo prime-select intel it looks like another fixed??? bug - https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1764005

It's pitiful, but I can't use kubuntu 18.04 on my laptop until this bug will be fixed.

[Richard (f-richaad-h)]

/var/log/boot.log: Starting dGPU off during boot...
/var/log/boot.log:[FAILED] Failed to start dGPU off during boot.

Unfortunately my Clevo laptop doesn't have an option in the firmware to disable Secure boot and I'm already running in BIOS mode rather than UEFI. (Same basic details as the original reporter) It's mainly annoying just because of the added delay that it adds to the boot process...

Ideally I'd be able to inflict the same bug and lack of resolution on all of the Ubuntu/switcheroo maintainers so that it would get fixed quickly :)
Instead I'll just have to wait patiently for the fix to come downstream :)

[jforbes (jforbes-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.

Fedora 28 has now been rebased to 4.20.5-100.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29.

If you experience different issues, please open a new bug report for those.

[sebastian4842 (sebastian4842-redhat-bugs)]

Problem still reproducible on Fedora 29. With disabled secure boot everything is fine.

Kernel version: 4.20.4-200.fc29.x86_64

[venturato.gabriele (venturato.gabriele-redhat-bugs)]

Same here with Fedora 29 and kernel 4.20.7-200.fc29.x86_64. When secure boot is disabled everything works fine.

[piratmac (piratmac-redhat-bugs)]

Hello,

In case it can help, I can confirm the same issue on Fedora 30, with secure boot. It is a clean install (installed from the live CD, not through dnf). All packages were updated, and the system rebooted prior to the tests.
Secure Boot is enabled.
Restarting switcheroo-control doesn't work.

Some details / additional information:

# systemctl start switcheroo-control
switcheroo-cont[801]: switcheroo-control could not query vga_switcheroo status: Operation not permitted
systemd[1]: switcheroo-control.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: switcheroo-control.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Switcheroo Control Proxy service.

The switcheroo file is not readable by root:
# cat /sys/kernel/debug/vgaswitcheroo/switch
cat: /sys/kernel/debug/vgaswitcheroo/switch: Operation not permitted

Kernel lockdown is visible in dmesg:
Lockdown: switcheroo-cont: debugfs is restricted; see man kernel_lockdown.7

Installed packages:
switcheroo-control.x86_64 1.1-7.fc30
xorg-x11-drv-intel.x86_64 2.99.917-41.20180618.fc30
xorg-x11-drv-nouveau.x86_64 1:1.0.15-7.fc30

[jforbes (jforbes-redhat-bugs)]

*********** MASS BUG UPDATE **************

We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.2.9-200.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

[bnocera (bnocera-redhat-bugs)]

This was worked around in this switcheroo-control update:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd1633d7cb

[Launchpad Janitor (janitor)]

This bug was fixed in the package switcheroo-control - 1.3.1-2

---------------
switcheroo-control (1.3.1-2) unstable; urgency=medium

  * debian/patches/gtk-doc-make.patch:
    - include gtk-doc.make file which is missing from the tarball,
      it's needed to be able to autoreconf the source

 -- Sebastien Bacher <email address hidden> Wed, 28 Aug 2019 11:12:47 +0200

[lk (lk53)]

This is not fixed on ubuntu for amd/nvidia configs.