Bug 1476366 - switcheroo-control.service does not start correctly on boot
Summary: switcheroo-control.service does not start correctly on boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 30
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1543427 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-28 17:37 UTC by Julien Enche
Modified: 2019-08-21 08:40 UTC (History)
35 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-21 08:40:26 UTC


Attachments (Terms of Use)
systemctl status switcheroo-control.service (963 bytes, text/plain)
2018-01-19 12:02 UTC, Denis
no flags Details

Description Julien Enche 2017-07-28 17:37:25 UTC
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)

Comment 1 Denis 2018-01-19 12:02:17 UTC
Created attachment 1383341 [details]
systemctl status switcheroo-control.service

Comment 2 Denis 2018-01-19 12:05:37 UTC
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

Comment 3 Bastien Nocera 2018-01-19 12:15:46 UTC
SELinux warnings?

Comment 4 Denis 2018-01-19 12:26:18 UTC
(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.

Comment 5 Bastien Nocera 2018-01-19 12:37:09 UTC
I'm going to say this is a kernel problem then.

Comment 6 Laura Abbott 2018-01-19 17:09:54 UTC
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.

Comment 7 Bastien Nocera 2018-02-08 13:13:08 UTC
*** Bug 1543427 has been marked as a duplicate of this bug. ***

Comment 8 陳鐸元 2018-02-24 05:50:54 UTC
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.

Comment 9 Stefanos Kalantzis 2018-03-23 08:33:13 UTC
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).

Comment 10 Fedora End Of Life 2018-05-03 08:32:25 UTC
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.

Comment 11 Stefanos Kalantzis 2018-05-03 10:29:46 UTC
This affects Fedora 27 too. Please update the ticket.

Comment 12 Sebastian 2018-05-03 11:22:07 UTC
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.

Comment 13 Stefanos Kalantzis 2018-05-03 11:36:01 UTC
Correct, but that's just a workaround right ?

Comment 14 Malar Kannan 2018-05-12 18:08:52 UTC
Yup, I can confirm it affects 28 too.

Comment 15 Mat Booth 2018-05-14 10:53:41 UTC
(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?

Comment 16 Laura Abbott 2018-05-14 20:17:49 UTC
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.

Comment 17 Justin M. Forbes 2018-07-23 15:05:55 UTC
*********** 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.

Comment 18 Sebastian 2018-07-24 12:22:32 UTC
The problem is still persisten with the newer kernel (4.17.7-200.fc28.x86_64).

Comment 19 rick.2889 2018-08-01 13:00:47 UTC
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.

Comment 20 Justin M. Forbes 2019-01-29 16:24:50 UTC
*********** 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.

Comment 21 Sebastian 2019-01-29 17:23:54 UTC
Problem still reproducible on Fedora 29. With disabled secure boot everything is fine.

Kernel version: 4.20.4-200.fc29.x86_64

Comment 22 Gabriele 2019-02-17 17:28:14 UTC
Same here with Fedora 29 and kernel 4.20.7-200.fc29.x86_64. When secure boot is disabled everything works fine.

Comment 23 Piratmac 2019-05-08 19:54:00 UTC
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

Comment 24 Justin M. Forbes 2019-08-20 17:36:46 UTC
*********** 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.

Comment 25 Bastien Nocera 2019-08-21 08:40:26 UTC
This was worked around in this switcheroo-control update:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd1633d7cb


Note You need to log in before you can comment on or make changes to this bug.