Created attachment 98190 [details] dmesg output I try to set up a bumblebee based system. intel work ok. however nouveau fails to load with [ 3.908759] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x108100a1 [ 3.909225] nouveau [ DEVICE][0000:01:00.0] Chipset: GK208 (NV108) [ 3.909662] nouveau [ DEVICE][0000:01:00.0] Family : NVE0 [ 3.911750] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... [ 3.913264] nouveau [ VBIOS][0000:01:00.0] ... signature not found [ 3.913677] nouveau [ VBIOS][0000:01:00.0] checking PROM for image... [ 3.914144] nouveau [ VBIOS][0000:01:00.0] ... signature not found [ 3.914548] nouveau [ VBIOS][0000:01:00.0] checking ACPI for image... [ 3.914947] nouveau [ VBIOS][0000:01:00.0] ... signature not found [ 3.915332] nouveau [ VBIOS][0000:01:00.0] checking PCIROM for image... [ 3.915719] nouveau [ VBIOS][0000:01:00.0] ... signature not found [ 3.916097] nouveau [ VBIOS][0000:01:00.0] checking PLATFORM for image... [ 3.916475] nouveau [ VBIOS][0000:01:00.0] ... signature not found [ 3.916840] nouveau E[ VBIOS][0000:01:00.0] unable to locate usable image [ 3.917198] nouveau E[ DEVICE][0000:01:00.0] failed to create 0x10000001, -22 [ 3.917866] nouveau E[ DRM] failed to create 0x80000080, -22 [ 3.918367] nouveau: probe of 0000:01:00.0 failed with error -22 the full dmesg is attached.
You should avoid bumblebee on recent kernels if you want to use nouveau. Nouveau should now (as of 3.12 or 3.13, iirc) auto-suspend when not in use (assuming that it loads :) ). The first thing I'd do is get rid of bumblebee. I'm pretty sure this isn't your problem, since it should be getting detected as an optimus system, but perhaps something like http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=2677c8889a40d7404cc8fc9210cb59fdf95efa63 would help. Or the vbios should be read from PROM but it's hitting the issue that keplers don't support 8-bit reads from PROM (which should be addressed in 3.15-rc1+), see http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=6b6d97553de21cf3f7b3b7fe7e57a16ac41ee2ac .
(In reply to comment #1) > You should avoid bumblebee on recent kernels if you want to use nouveau. > Nouveau should now (as of 3.12 or 3.13, iirc) auto-suspend when not in use > (assuming that it loads :) ). The first thing I'd do is get rid of bumblebee. thanks for advice. I would love to follow, but this is my 1st optimus experience on Linux. I don't know any other way to use nvidia only when I need some more 3D power. I mean userland utilities. Can you give me some search hints? > > I'm pretty sure this isn't your problem, since it should be getting detected > as an optimus system, but perhaps something like > http://cgit.freedesktop.org/~darktama/nouveau/commit/ > ?id=2677c8889a40d7404cc8fc9210cb59fdf95efa63 would help. Or the vbios should > be read from PROM but it's hitting the issue that keplers don't support > 8-bit reads from PROM (which should be addressed in 3.15-rc1+), see > http://cgit.freedesktop.org/~darktama/nouveau/commit/ > ?id=6b6d97553de21cf3f7b3b7fe7e57a16ac41ee2ac . Can you advise which patch better suits my kernel? Or should I try both?
(In reply to comment #2) > (In reply to comment #1) > > You should avoid bumblebee on recent kernels if you want to use nouveau. > > Nouveau should now (as of 3.12 or 3.13, iirc) auto-suspend when not in use > > (assuming that it loads :) ). The first thing I'd do is get rid of bumblebee. > > thanks for advice. I would love to follow, but this is my 1st optimus > experience on Linux. I don't know any other way to use nvidia only when I > need some more 3D power. I mean userland utilities. Can you give me some > search hints? None. More than likely, your Intel card will be faster than the GK208 with nouveau, since we can't reclock. However if any outputs are directly attached to the NVIDIA card, the functionality becomes a lot more useful. See http://nouveau.freedesktop.org/wiki/Optimus/ for optimus information. To offload 3D, once it's set up, you'd do DRI_PRIME=1 foo-app. > > > > > I'm pretty sure this isn't your problem, since it should be getting detected > > as an optimus system, but perhaps something like > > http://cgit.freedesktop.org/~darktama/nouveau/commit/ > > ?id=2677c8889a40d7404cc8fc9210cb59fdf95efa63 would help. Or the vbios should > > be read from PROM but it's hitting the issue that keplers don't support > > 8-bit reads from PROM (which should be addressed in 3.15-rc1+), see > > http://cgit.freedesktop.org/~darktama/nouveau/commit/ > > ?id=6b6d97553de21cf3f7b3b7fe7e57a16ac41ee2ac . > > Can you advise which patch better suits my kernel? Or should I try both? Step 1: Try 3.14.x, without any bumblebee stuff. Step 2: Try 3.15-rc3 without any bumblebee stuff. Step 3: Try applying the first patch (since it still hasn't hit upstream trees) to 3.15-rc3. You'll need to be a bit creative when applying it, since it's against a differently-formatted tree. It just removes 2 lines, so you can always do it by hand. If all of that still fails to find a VBIOS, attach a fresh dmesg (with 3.15-rc3 + the patch to use acpi method even if not optimus), and an acpidump output.
Created attachment 98193 [details] dmesg after 1st patch I need to wait until my distro (gentoo) makes 3.15 available. meanwhile I applied the 1st patch to my current 3.14 kernel. It did find some BIOS, but some errors appeared. The bumblebee still fails to run glxinfo. dmesg is attached if you are interested.
9-pb8edcn ~ # xrandr --listproviders Providers: number : 1 Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 6 associated providers: 0 name:Intel no luck yet :-(
(In reply to comment #4) > Created attachment 98193 [details] > dmesg after 1st patch > > I need to wait until my distro (gentoo) makes 3.15 available. > meanwhile I applied the 1st patch to my current 3.14 kernel. > > It did find some BIOS, but some errors appeared. The bumblebee still fails > to run glxinfo. > > dmesg is attached if you are interested. Perhaps I was unclear in the steps I outlined. I _did_ think I was fairly explicit in "don't use bumblebee", but perhaps not enough. So let me be crystal clear: DO NOT USE BUMBLEBEE. Also, you don't have to wait for your distribution to make a kernel available. (Unless you're using genkernel or something crazy like that... but even that should be able to build an arbitrary tree, I thought.) You can get releases from http://www.kernel.org/ and/or you can create your own git clone.
Created attachment 98203 [details] dmesg with unpatched 3.15-rc3 unpatched 3.15-rc3 doesn't init my GT730M
(In reply to comment #7) > Created attachment 98203 [details] > dmesg with unpatched 3.15-rc3 > > unpatched 3.15-rc3 doesn't init my GT730M Interesting. That means it's not being detected as optimus... very odd. Can you add in this patch: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=2677c8889a40d7404cc8fc9210cb59fdf95efa63 That should help with the load (since it did before too). However since it's not being detected as optimus, I assume it won't auto-suspend either, which is unfortunate. Also, why do you have this in your kernel cmdline: acpi_osi=!Windows 2012 That sort of thing could cause stuff to break. (Although I kinda assume you put it in because something else was broken already... assuming it's nothing _too_ major, can you try without it?) To figure out why it's not being detected as an optimus system, I need more information: lspci -nn (for the whole system) acpidump (Perhaps more, I'll ask as I trace through the code. But I definitely need those.)
Created attachment 98211 [details] acpidump When I applied http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=2677c8889a40d7404cc8fc9210cb59fdf95efa63 to 3.15-rc3, it did init. 2349-pb8edcn ~ # xrandr --listprovidersProviders: number : 2 Provider 0: id: 0x88 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 6 associated providers: 0 name:Intel Provider 1: id: 0x5f cap: 0x5, Source Output, Source Offload crtcs: 0 outputs: 0 associated providers: 0 name:nouveau 2349-pb8edcn ~ # xrandr --setprovideroffloadsink nouveau Intel I get ~ 180 frames/sec from GT730 in glxspheres. acpi_osi=!Windows 2012 is the carry-over from previous kernels to make backlight control buttons work on my Lenovo thinkpad T540p. They no longer work on 3.15-rc3, so I removed this parameter. I removed the patch from nouveau_acpi.c and re-tested optimus detection w/o acpi_osi=!Windows 2012. It doesn't initialize due to the same reason - no VBIOS. 2349-pb8edcn linux # lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [8086:0c04] (rev 06) 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04) 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-LM [8086:153a] (rev 04) 00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 04) 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 04) 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 [8086:8c10] (rev d4) 00:1c.1 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #2 [8086:8c12] (rev d4) 00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 [8086:8c14] (rev d4) 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 04) 00:1f.0 ISA bridge [0601]: Intel Corporation QM87 Express LPC Controller [8086:8c4f] (rev 04) 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c03] (rev 04) 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 04) 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208M [GeForce GT 730M] [10de:1290] (rev a1) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader [10ec:5227] (rev 01) 04:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b2] (rev 6b) 2349-pb8edcn linux # acpidump > /var/log/acpidump.txt Wrong checksum for FADT! Thanks for your attention to my problem. I would be happy to provide any more information you need.
Very odd. I looked at the _DSM method, and it _seems_ like it's there and should work. The method is there, I traced through it, and based on my meager understanding of ACPI it should be returning an appropriate buffer (via the 'NVOP' function). But clearly something's going wrong, since the prints in nouveau_acpi.c are never even hit, which means it thinks it's _really_ not optimus. The only weird thing about the ACPI dump is that there are two Device (VID) sections, but I don't know ACPI intimately enough to tell whether that's in any way bad. You _do_ have 2 gfx cards. Presumably ACPI specifies some way of mapping these things, but I just don't know what that is. But I bet that the people who wrote ACPI support in Linux do :) If you're comfortable making small edits to code, mind dropping a boatload of printk's all over nouveau_dsm_pci_probe, nouveau_test_dsm, and nouveau_optimus_dsm to try to see why that logic is deciding you're not in an optimus setup? Otherwise I can probably put together a patch for you to test out...
I'm ok to add extra prints to the (kernel nouveau) code and provide you the output. just give me enough guidance.
(In reply to comment #11) > I'm ok to add extra prints to the (kernel nouveau) code and provide you the > output. just give me enough guidance. I need to know why nouveau_dsm_pci_probe is not returning NOUVEAU_DSM_HAS_OPT for the GK208 device. So check all the early exits from the function, as well as the functions it calls to obtain the final result. (Obviously no need to trace through the various acpi helpers, let's assume they're correct for now.)
Created attachment 98227 [details] modified nouveau_acpi.c with printk either I forgot my programming completely, or static int nouveau_dsm_pci_probe is never called. See my modified nouveau_acpi.c and module load output below. [13425.965579] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x108100a1 [13425.965581] nouveau [ DEVICE][0000:01:00.0] Chipset: GK208 (NV108) [13425.965582] nouveau [ DEVICE][0000:01:00.0] Family : NVE0 [13425.966804] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... [13425.966811] nouveau [ VBIOS][0000:01:00.0] ... signature not found [13425.966812] nouveau [ VBIOS][0000:01:00.0] checking PROM for image... [13425.966868] nouveau [ VBIOS][0000:01:00.0] ... signature not found [13425.966869] nouveau [ VBIOS][0000:01:00.0] checking ACPI for image... [13425.966870] nouveau [ VBIOS][0000:01:00.0] ... signature not found [13425.966870] nouveau [ VBIOS][0000:01:00.0] checking PCIROM for image... [13425.966871] nouveau [ VBIOS][0000:01:00.0] ... signature not found [13425.966872] nouveau [ VBIOS][0000:01:00.0] checking PLATFORM for image... [13425.966873] nouveau [ VBIOS][0000:01:00.0] ... signature not found [13425.966874] nouveau E[ VBIOS][0000:01:00.0] unable to locate usable image [13425.966875] nouveau E[ DEVICE][0000:01:00.0] failed to create 0x10000001, -22 [13425.966876] nouveau E[ DRM] failed to create 0x80000080, -22 [13425.967122] nouveau: probe of 0000:01:00.0 failed with error -22
I poked further... from my understanding of the code, nouveau_dsm_pci_probe is called from within 2 while loops in nouveau_dsm_detect (@ line 275). as nouveau_dsm_pci_probe is never called, I would say, the while condition is always false for both loops. I assume pci_get_class is somebody else's domain...
(In reply to comment #14) > I poked further... from my understanding of the code, nouveau_dsm_pci_probe > is called from within 2 while loops in nouveau_dsm_detect (@ line 275). > > as nouveau_dsm_pci_probe is never called, I would say, the while condition > is always false for both loops. Inconceivable :) The first while loop should enter that condition twice, for these two devices: 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208M [GeForce GT 730M] [10de:1290] (rev a1) The second while loop should not have any effect since you don't have any "3D controller" devices. Can you double-check that the first while loop never executes its body? (e.g. put a print before/after/in it, which will confirm that your code is actually being executed and that it never goes inside.)
BTW, this isn't the immediate problem, but in your patch you have, if (!dhandle) printk("DEBUG: !dhandle\n"); return false; Which is unlikely to do what you expect. Unlike Python, C uses braces to define blocks, so that probably should have been if (!dhandle) { printk("DEBUG: !dhandle\n"); return false; } But if the first print isn't getting triggered, it doesn't even get far enough for this to be a problem.
I did notice the missing curly brackets too and fixed them. ok, tracked this mistery down to unset CONFIG_VGA_SWITCHEROO. Once set, calls are in place. [ 3456.395879] wmi: Mapper unloaded [ 3459.834473] wmi: Mapper loaded [ 3459.835817] DEBUG: doing DSM detection [ 3459.835820] DEBUG: probing vga card #1 [ 3459.835821] DEBUG: called nouveau_dsm_pci_probe [ 3459.835826] DEBUG: !acpi_has_method(dhandle, "_DSM") [ 3459.835828] DEBUG: probing vga card #2 [ 3459.835828] DEBUG: called nouveau_dsm_pci_probe [ 3459.835954] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140214/nsarguments-95) [ 3459.836314] DEBUG: nouveau_check_optimus_dsm result: c010001 [ 3459.836316] DEBUG: retval after nouveau_check_optimus_dsm(dhandle): 2 [ 3459.836321] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140214/nsarguments-95) [ 3459.836653] pci 0000:01:00.0: optimus capabilities: enabled, status dynamic powe r, hda bios codec supported [ 3459.836657] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG_.VID_ han dle [ 3459.836953] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x108100a1 [ 3459.836955] nouveau [ DEVICE][0000:01:00.0] Chipset: GK208 (NV108) [ 3459.836957] nouveau [ DEVICE][0000:01:00.0] Family : NVE0 [ 3459.838506] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... [ 3459.838510] nouveau [ VBIOS][0000:01:00.0] ... signature not found [ 3459.838511] nouveau [ VBIOS][0000:01:00.0] checking PROM for image... [ 3459.838565] nouveau [ VBIOS][0000:01:00.0] ... signature not found [ 3459.838566] nouveau [ VBIOS][0000:01:00.0] checking ACPI for image... [ 3459.838568] DEBUG: dsm_detected: 0, optimus_detected: 1 [ 3460.002952] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid [ 3460.002955] nouveau [ VBIOS][0000:01:00.0] using image from ACPI [ 3460.003021] nouveau [ VBIOS][0000:01:00.0] BIT signature found [ 3460.003023] nouveau [ VBIOS][0000:01:00.0] version 80.28.2a.00.30 [ 3460.003876] nouveau [ VBIOS][0000:01:00.0] running init tables [ 3460.046746] nouveau 0000:01:00.0: irq 49 for MSI/MSI-X [ 3460.046758] nouveau [ PMC][0000:01:00.0] MSI interrupts enabled [ 3460.046796] nouveau [ PFB][0000:01:00.0] RAM type: DDR3 [ 3460.046797] nouveau [ PFB][0000:01:00.0] RAM size: 1024 MiB [ 3460.046799] nouveau [ PFB][0000:01:00.0] ZCOMP: 0 tags [ 3460.046857] nouveau E[ PIBUS][0000:01:00.0] HUB0: 0x6013d4 0xbadf5701 (0x19708200) [ 3460.046863] nouveau E[ PIBUS][0000:01:00.0] GPC0: 0x4188ac 0x00000001 (0x1970822e) [ 3460.051219] nouveau [ VOLT][0000:01:00.0] GPU voltage: 600000uv [ 3460.691537] nouveau [ PTHERM][0000:01:00.0] FAN control: none / external [ 3460.691548] nouveau [ PTHERM][0000:01:00.0] fan management: automatic [ 3460.691565] nouveau [ PTHERM][0000:01:00.0] internal sensor: yes [ 3460.691599] nouveau [ CLK][0000:01:00.0] 07: core 405 MHz memory 810 MHz [ 3460.691650] nouveau [ CLK][0000:01:00.0] 0a: core 405-875 MHz memory 1620 MHz [ 3460.691715] nouveau [ CLK][0000:01:00.0] 0f: core 405-875 MHz memory 2002 MHz [ 3460.691777] nouveau [ CLK][0000:01:00.0] --: core 405 MHz memory 810 MHz [ 3460.703809] vga_switcheroo: enabled [ 3460.703931] [TTM] Zone kernel: Available graphics memory: 8155342 kiB [ 3460.703932] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 3460.703932] [TTM] Initializing pool allocator [ 3460.703936] [TTM] Initializing DMA pool allocator [ 3460.703943] nouveau [ DRM] VRAM: 1024 MiB [ 3460.703943] nouveau [ DRM] GART: 1048576 MiB [ 3460.703946] nouveau E[ DRM] Pointer to TMDS table invalid [ 3460.703947] nouveau [ DRM] DCB version 4.0 [ 3460.703948] nouveau E[ DRM] Pointer to flat panel table invalid [ 3460.710300] nouveau [ DRM] MM: using COPY for buffer copies [ 3460.710305] [drm] Initialized nouveau 1.1.1 20120801 for 0000:01:00.0 on minor 1 [ 3465.713671] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140214/nsarguments-95) [ 3465.713979] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140214/nsarguments-95) however xrandr sees no nouveau provider: 2349-pb8edcn linux # xrandr --listproviders Providers: number : 1 Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 6 associated providers: 0 name:Intel
A full restart gives me 2 providers finally. Issue closed. Root cause = missing CONFIG_VGA_SWITCHEROO. stats from glxshperes: anton@2349-pb8edcn ~ $ DRI_PRIME=1 glxspheres Polygons in scene: 62464 Visual ID of window: 0x60 Context is Direct OpenGL Renderer: Mesa DRI Intel(R) Haswell Mobile 389.730071 frames/sec - 434.938759 Mpixels/sec 313.258202 frames/sec - 349.596154 Mpixels/sec 315.264621 frames/sec - 351.835317 Mpixels/sec 312.586974 frames/sec - 348.847063 Mpixels/sec 313.750305 frames/sec - 350.145340 Mpixels/sec 310.040738 frames/sec - 346.005464 Mpixels/sec 252.324787 frames/sec - 434.635791 Mpixels/sec 142.339972 frames/sec - 617.778255 Mpixels/sec anton@2349-pb8edcn ~ $ DRI_PRIME=0 glxspheres Polygons in scene: 62464 Visual ID of window: 0x60 Context is Direct OpenGL Renderer: Mesa DRI Intel(R) Haswell Mobile 61.427659 frames/sec - 68.553267 Mpixels/sec 59.934683 frames/sec - 66.887106 Mpixels/sec 59.953323 frames/sec - 66.907908 Mpixels/sec 59.984469 frames/sec - 66.942667 Mpixels/sec 59.952780 frames/sec - 66.907303 Mpixels/sec 59.972983 frames/sec - 66.929849 Mpixels/sec 59.970282 frames/sec - 66.926834 Mpixels/sec 59.969874 frames/sec - 66.926380 Mpixels/sec
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.