Created attachment 112211 [details] Include "3D controller" in vgaarb initalization This issue arises when laptops with nvidia optimus are used, the secondary video card is not defined as a VGA device, instead (on the Zenbook UX32VD) it's defined as: 01:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M / GT 620M/625M/630M/720M] (rev ff) Note the "3D controller" rather than the main video card 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) When booting, the vgaarb reports [ 0.675021] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.675025] vgaarb: loaded [ 0.675027] vgaarb: bridge control possible 0000:00:02.0 Then when the nvidia kernel module is loaded [ 83.698441] bbswitch: enabling discrete graphics [ 84.210385] [drm] Initialized nvidia-drm 0.0.0 20130102 for 0000:01:00.0 on minor 1 [ 84.210397] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 331.13 Sun Sep 29 22:56:10 PDT 2013 [ 84.536244] vgaarb: this pci device is not a vga device [ 84.540504] nvidia 0000:01:00.0: irq 49 for MSI/MSI-X vgaarb complains that the the nvidia graphics is not a vga device. A patch is available here (and attached) https://github.com/Bumblebee-Project/Bumblebee/issues/159#issuecomment-5804686 Which adds "3D controller" to the vgaarb detection When booting with the patch applied: [ 0.679875] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.679881] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=none,locks=none [ 0.679883] vgaarb: loaded [ 0.679884] vgaarb: bridge control possible 0000:01:00.0 [ 0.679886] vgaarb: no bridge control possible 0000:00:02.0 And loading the nvidia module [ 90.357188] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=none [ 90.357530] [drm] Initialized nvidia-drm 0.0.0 20130102 for 0000:01:00.0 on minor 1 [ 90.357536] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 331.13 Sun Sep 29 22:56:10 PDT 2013 [ 90.642917] nvidia 0000:01:00.0: irq 49 for MSI/MSI-X It looks like the vgaarb complaint is just a warning, since everything works the same, but should vgaarb be patched to handle this?
problems with the non free Nvidia setup should be directed to Nvidia
This bug would arise the same if the nouveau driver is used. This bug is due to the device's PCI ID being listed as a "3D controller" instead of a VGA device, meaning that vgaarb doesn't properly setup its interfaces. Please examine the patch.
In which case please provide a trace with nouveau and submit the patch to the lists as per Documentation/SubmittingPatches. From my reading of the PCI spec though the existing code is correct.
I guess this is fixed by now https://devtalk.nvidia.com/default/topic/567297/linux/linux-3-10-driver-crash/post/4353535/#4353535
> This issue arises when laptops with nvidia optimus are used, the secondary > video card is not defined as a VGA device, instead (on the Zenbook UX32VD) > it's defined as: > > 01:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M / GT > 620M/625M/630M/720M] (rev ff) FWIW, it also manifests itself on a MacBook Pro MacBookPro4,1 with a single … 01:00.0 VGA compatible controller: NVIDIA Corporation G84M [GeForce 8600M GT] (rev a1) … although rather erratically, but if it does, then every 30 seconds for as long as the system is up. I have only seen these messages after having booted in EFI mode.
Note that adding such 3D controllers to VGA arbitration may have some side-effects not immediately visible (such as blacklight controls that stop working). Have a look at bug #86121 for such a case. How are the GPUs wired to displays when the nvidia one is flagged as 3D controller? Does the nvidia card have access to displays (via multiplexer) or does it require frames to be passed to Intel card for display? In the second case the nvidia chip is just a graphics/3D accelerator! The vgaarb is being triggered by closed nvidia driver (or maybe userspace) that tries to move VGA IO mappings around when it should not, ending up with vgaarb complaining about a PCI device it is asked to operate on while that device is not a candidate for arbitration.