Mageia forum

I write this post to help someone with the same problem.

With the last x11 driver for nvidia the card is not being detected automatically by the optirun software:

[ERROR]Cannot access secondary GPU - error: [XORG] (EE) No devices detected.
[ERROR]Aborting because fallback start is disabled.

This is not because the card is faulty or whatever, simply autodetect no longer works (I do not know if it's a driver problem or a configuration problem). To fix the problem you have to edit the correct file, for instance if you use nvidia proprietary drivers it's /etc/bumblebee/xorg.conf.nvidia (otherwise it would be xorg.conf.noveau, but I don't know if the issue will appear with this driver).

Have a look at the Device section and add this line:

BusID "PCI:0:1:0"

! the actual line is the result of running lspci | grep -i nvidia, but usually the last dot has to be modified into a colon (:)

I don't know if someone with and unfixed system wants to open a bug (yesterday evening I didn't find anything) or if someone wants to edit the wiki (I would do it myself, but I would at least wait for another user confirm that the workaround is OK before).

As proposed in bugzilla
https://bugs.mageia.org/show_bug.cgi?id=27217

Thank you very much, I did not find this bug yesterday so I was wondering if I was the only one

I'm just adding the information on a new issue here that may or may not be caused by the x11 update that caused the bug, I copy the text from the bug because the bug may be fixed or the issue split:


I don't know if it's related, but now that I applied the configuration uncommenting the BusID line in bumblebee/xorg.conf.nvidia to workaround this issue, when my notebook wakes from sleep, the card is not available.

In /proc/acpi/bbswitch the card is OFF, but it seems that bumblebeed can't turn it back on no matter what.

I wonder if it's the case for other people too.

I'm on a Dell XPS 15 (9550), I can provide the errors if needed but the optirun output is not very helpful, tonight I can try to get some info from dmesg or the bumblebeed logs in the journal.

Rebooting the notebook renders the card available again.



These are some outputs and logs:

Code: Select all

[optirun]
$ optirun <software>
[11387.526745] [ERROR]Cannot access secondary GPU - error: Could not enable discrete graphics card

[11387.526799] [ERROR]Aborting because fallback start is disabled.

[dmesg]
[11388.134933] bbswitch: enabling discrete graphics
[11388.134960] pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible)

[journalctl -u bumblebeed]
Sep 04 20:53:08 <hostname> bumblebeed[6972]: Could not enable discrete graphics card

# cat /proc/acpi/bbswitch
0000:01:00.0 OFF

[syslog]
Sep  4 20:53:08 <hostname> kernel: [11388.134933] bbswitch: enabling discrete graphics
Sep  4 20:53:08 <hostname> kernel: [11388.134960] pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible)


If I rmmod bbswitch and modprobe it:

Code: Select all

[syslog]
Sep  4 21:00:21 <hostname> kernel: [11820.692973] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
Sep  4 21:00:21 <hostname> kernel: [11820.692991] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP
Sep  4 21:00:21 <hostname> kernel: [11820.693050] bbswitch: detected an Optimus _DSM function
Sep  4 21:00:21 <hostname> kernel: [11820.693054] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is off
Sep  4 21:00:32 <hostname> bumblebeed[6972]: Could not enable discrete graphics card
Sep  4 21:00:32 <hostname> kernel: [11831.757218] bbswitch: enabling discrete graphics
Sep  4 21:00:32 <hostname> kernel: [11831.757231] pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible)


I think that maybe the last one is the key, when notebook goes to sleep, card is in a state that the system is unable to change.

Yes, i agree with your experience.
Tried it out just some moments ago.
I had to restart the laptop, to get primusrun seeing my device again.

Didn't run into this problem before, because i have no power-settings enabled for my laptop.

This is frustrating because it dind't happen before. I don't know if it's the new driver or the new kernel but I tried booting with an old kernel but the problem persist.

I don't use much power management (my notebook is almost always plugged in) but closing the lid to go to suspend is pretty common nowadays..

You may want to read the more recent comments on https://bugzilla.kernel.org/show_bug.cgi?id=156341

Thank you very much!

Unfortunately at the moment I'm unable to switch to noveau driver (also I don't know exactly HOW to switch to noveau in a running nvidia.

In mga7 there's only this note in the Release Notes but no further link... and the wiki only covers bumblebee (I don't know if current bunblebee drivers supports noveau or how to reconfigure to noveau to see if my proprietary needs are no more): http://ftp.cc.uoc.gr/mirrors/linux/mage ... us_laptops

So it seems this is not something mageia can do anything about it and must wait for an upstream workaround?

I don't know. If you are affected, it might be worth trying out if one of the workarounds works for you.
E.g. disable PCIe power management, use a different acpi_osi string as kernel boot option. And I think there were others mentioned in that bugreport.

I don't know. I have no lockups or power management issues which is what more or less is being addressed in the bug report.

The only thing it's happening is that the nvidia card is unavaillable after a sleep. If I would disable power management altogether for the nvidia card, I'm not sure the notebook would be able to go to sleep so it's a lose/lose situation, since if I don't put the laptop to sleep I have no issues.

I'm going to read the thread from top to bottom but I don't see at the moment any post mentioning a disable nvidia card after sleep. They mention a disable nvidia card after unloading modules, which is probably what's happening to me under the hood, maybe I should simply try to stop&disable bumblebeed but if I do it I can't use optirun anymore. Maybe primusrun can run nonetheless, so I would try something like this when I can afford the possible reboots.

Well, as a workaround I went back to the 5.6.x kernel and even with new driver and new bbswitch, everything is back in order.

Now I'm trying another way: to put the card back on before suspend with the latest 5.7 kernel. First manually, then through a suspend script.

I'll report back in a few minutes.

The test with the latest kernel is successful. I don't add another tag to the thread title, but for future reference I can show the script I used and cite the source.

This is the source, the script body and the location in which you can put the script. I didn't strip the sudo command, if you don't have sudo installed you can remove every instance of the sudo command with the command without sudo: https://github.com/Askannz/optimus-mana ... -675276248

If the original source becomes unavailable, this is the location of the file on the filesystem and the body of the script (I put some indentation differently but it is basically the same script):

Put the script in /usr/lib/systemd/system-sleep/nvidia_suspend.sh

Code: Select all

#!/bin/bash

if [ "${1}" = "pre" ]; then
  # Do the thing you want before suspend here
  echo ON | sudo tee /proc/acpi/bbswitch
elif [ "${1}" = "post" ]; then
  # Do the thing you want after resume here
  echo OFF | sudo tee /proc/acpi/bbswitch
fi