Peculiar issue with Bumblebee/driver interaction

[amonakov]

The new 304.22 driver has become more accommodating for Optimus configurations on Linux, as it does not refuse to work in systems where no displays are connected to the Nvidia GPU. However, some people are affected by an issue that "GPU has fallen off the bus" error is produced when optirun is invoked. I have such a system — MSI GE60 laptop with 650M GPU — and I've attempted to investigate that issue.

For me, invoking some CUDA program was enough to workaround the issue. In fact, when testing 304.22 I've noticed that nvidia-xconfig -query-gpu-info has the same effect. Essentially, invoking optirun like this:

sudo tee /proc/acpi/bbswitch <<<ON; nvidia-xconfig -query-gpu-info && optirun glxspheres

works, while omitting the nvidia-xconfig step causes "fallen off the bus" error.

Thanks to nvidia-xconfig being open-source, I was able to find out that the call to nvCfgOpenPciDevice is sufficient to prepare the GPU correctly for optirun. I've coded a short program that does nothing beside calling nvCfgOpenPciDevice, and that is still sufficient to run in place of nvidia-xconfig to make optirun work correctly.

However, it is most puzzling that calling that function from the bumblebee daemon or invoking that simple program using system() does not work! In strace logs I see that the sequence of ioctls looks the same, but open()'ing /dev/nvidia0 from the daemon returns -EIO. It looks as if the daemon was somehow "tainted" and unable to configure the GPU correctly, and that taint affects the small program that is invoked from the daemon (and perhaps the auxiliary X server as well).

How can that happen and how can I debug it further?