bbswitch is preventing the nvidia module from loading on Fedora 19 about bbswitch

[Lekensteyn]

Please try 0.7 which was released yesterday. It sounds like Fedora tries to load the nvidia driver after bbswitch disabled the card. That is not going to work, the card needs to be turned on before the nvidia driver is loaded. Otherwise you get the symptoms mentioned by you.

[ArchangeGabriel]

I'm saying it one more time to be sure that this point is clear: you indeed can't load the nvidia module while bbswitch has disabled the card. You first need to turn it on (using bbswitch) in order to do that, so I don't see any issue here.

[jmontleon]

I built an 0.7 rpm quick and it got rid of all the trace stuff (don't know if that was expected with 0.6, never really looked before having trouble). Now it looks like:

[  231.447275] bbswitch: version 0.7
[  231.447286] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
[  231.447292] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP
[  231.447439] bbswitch: detected an Optimus _DSM function
[  231.447526] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
[  231.452586] bbswitch: disabling discrete graphics
[  231.464241] pci 0000:01:00.0: power state changed by ACPI to D3cold

Anyway everything seems to be working as expected now. running optirun <whatever> starts the card, loads the driver, and sends me on my way.

[ArchangeGabriel]

The Kernel WARNING was an issue of v0.6 indeed. Closing since everything is OK now.

[gsgatlin]

Will try to build a 0.7 bbswitch dkms based rpm tomorrow for fedora 19/18/17 in my yum repository.

[lxnay]

I still get this with 0.7 and Linux 3.10.1 and NVIDIA 319.32.
It looks like there is a race between what udev does and what bbswitch does.

[Lekensteyn]

@lxnay The same WARNING as in the first post? You are recommended to blacklist nvidia to prevent the race.

[jmontleon]

It looks like when there is an update to the kernel or module it doesn't always get built right; I end up disabling the bbswitch and bumblebee-nvidia services, rebooting, bumblebee-nvidia --debug --force, enabling the services, and rebooting again. After that sanity returns.

[lxnay]

For sake of clarity, I get this, repeated forever (cpu skyrockets until I uninstall nvidia-drivers):

[  154.643985] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:1140)
NVRM: installed in this system is not supported by the 319.32
NVRM: NVIDIA Linux driver release.  Please see 'Appendix
NVRM: A - Supported NVIDIA GPU Products' in this release's
NVRM: README, available on the Linux driver download page
NVRM: at www.nvidia.com.
[  154.643998] nvidia: probe of 0000:01:00.0 failed with error -1
[  154.644417] NVRM: The NVIDIA probe routine failed for 1 device(s).
[  154.644420] NVRM: None of the NVIDIA graphics adapters were initialized!
[  154.644421] [drm] Module unloaded
[  154.678676] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:1140)
NVRM: installed in this system is not supported by the 319.32
NVRM: NVIDIA Linux driver release.  Please see 'Appendix
NVRM: A - Supported NVIDIA GPU Products' in this release's
NVRM: README, available on the Linux driver download page
NVRM: at www.nvidia.com.
[  154.678687] nvidia: probe of 0000:01:00.0 failed with error -1
[  154.678992] NVRM: The NVIDIA probe routine failed for 1 device(s).
[  154.678994] NVRM: None of the NVIDIA graphics adapters were initialized!
[  154.678996] [drm] Module unloaded
[  154.715083] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:1140)
NVRM: installed in this system is not supported by the 319.32
NVRM: NVIDIA Linux driver release.  Please see 'Appendix
NVRM: A - Supported NVIDIA GPU Products' in this release's
NVRM: README, available on the Linux driver download page
NVRM: at www.nvidia.com.
[  154.715098] nvidia: probe of 0000:01:00.0 failed with error -1
[  154.715510] NVRM: The NVIDIA probe routine failed for 1 device(s).
[  154.715512] NVRM: None of the NVIDIA graphics adapters were initialized!
[  154.715514] [drm] Module unloaded
[  154.744553] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:1140)
NVRM: installed in this system is not supported by the 319.32
NVRM: NVIDIA Linux driver release.  Please see 'Appendix
NVRM: A - Supported NVIDIA GPU Products' in this release's
NVRM: README, available on the Linux driver download page
NVRM: at www.nvidia.com.

[lxnay]

You cannot pretend that people blacklist nvidia, it would be better to find a solution that doesn't require user intervention.
It would become harder to integrate and support bbswitch/bumblebee in a distro if we're required to do even that...

[Lekensteyn]

@lxnay Bumblebee already unloads nvidia if needed. But if a distribution chose to load nvidia automatically at the same time bumblebeed starts, then a race is possible. Distribution packagers should blacklist nvidia if they intend to ship Bumblebee because bumblebeed takes care of loading it when optirun is used.

Perhaps your question is how to do such a blacklist? On Ubuntu and Arch at least (and other kmod users), it is sufficient to create /etc/modprobe.d/blacklist-nvidia.conf containing blacklist nvidia. (the filename is not so important)

[gsgatlin]

So should the package bumblebee-nvidia in fedora contain this blacklist file? @lxnay if you can determine if this fixed your issue I could try adding that to the drivers package.

[Lekensteyn]

@gsgatlin Yes, and blacklist nouveau as well, otherwise you have the same race issue (but then with nouveau). (most nvidia packages do this already though)

[gsgatlin]

Ok. I was already having to blacklist nouveau in the grub.conf to get it to work with fedora 18.

version bumblebee-nvidia-310.51-3 for f18/f19 and bumblebee-nvidia-319.23-3 for f17/ RHEL 6 contains a /etc/modprobe.d/blacklist-nvidia.conf file and should be available via yum starting now. Please let me know if this fixes your problem?

[lxnay]

I'm not using Fedora.
I am a Gentoo Developer and the Sabayon Linux creator.
I will have a look at the problem tomorrow, because it also affects my personal laptop.

[lxnay]

blacklisting nvidia works for me. I wonder why I was working until now without doing so. Maybe the modprobe exit status changed? (that might explain the infinite modprobe loop I am observing)... I will dig into it soon.