Optimus laptop issues


#101

it thought you’re using video-linux ? (which shouldn’t need bumblebee stuff to work?)

But do you really not want to use that nice 1050m gpu ?

(you can/should also take a look at the arch articles regarding nvidia optimus https://wiki.archlinux.org/index.php/NVIDIA_Optimus [and the related topics linked there])

also in general:
arch wiki suggests not using bumblebee

(not related to you)


#102

I do use video-linux, but as instructed I’ve installed bbswitch because video-linux alone is not powering nvidia gpu properly resulting in very bad battery life. As I’m beginner java dev I started using linux to get knowledge about architecture and development under this os, and atm I don’t really need to use nvidia gpu (maybe/probably that will change in the future). Also I’m dual booting with Windows 10, so if I really need to do something gpu-related I do have access to it there.
What I really need is solid, stable linux setup that will work without the need of troubleshooting every day. I will be more than happy if I get touchpad to work and gpu to power off properly, so I can use my laptop as mobile with decent battery life. I actually consider working on these issues as very educational (as I’ve said I installed linux to “learn” it in the first place).

@petsam
I don’t really think I did any permanent damage to the system (yet), but maybe for sake of clarity that would be the best. I have no time to do that today though, maybe I will do that on the weekend.

And again - I’m very grateful to everyone for spending their time and effort to help me with this. I’m using Manjaro for just couple of days now, and I joined the community literally yesterday, but as far as I can tell - you guys are the best :wink: And @dglt deserves standing ovation for his effort yesterday, as he spent several hours with me on this issue. So whether we solve it or not - keep up the good work everyone, and huge Thank You!


#103

I would remove all bumblebee related stuff (as fixing the touchpad issues wasn’t possible) and replace it with this (if your nvidia gpu is supported by nouveau),

https://wiki.archlinux.org/index.php/PRIME#Open-source_drivers
then nvidia gpu should power off if not needed (but maybe nouveau doesn’t work properly with your card which I think is a pretty recent model , you can check nouveau website and check status):

then it should look like this:

mv@mv-pc:~$ xrandr --listproviders 
Providers: number : 2
Provider 0: id: 0x8b cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 5 associated providers: 1 name:Intel
Provider 1: id: 0x63 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 2 associated providers: 1 name:nouveau

(you could also use modesetting instead of Intel)

then nvidia gpu shouldn’t draw much power if not used:

mv@mv-pc:~$ cd /sys/bus/pci/devices/0000\:01\:00.0/
mv@mv-pc:/sys/bus/pci/devices/0000:01:00.0$ cat enable 
0
mv@mv-pc:/sys/bus/pci/devices/0000:01:00.0$ sensors
nouveau-pci-0100
Adapter: PCI adapter
GPU core:     +0.83 V  (min =  +0.83 V, max =  +1.00 V)
temp1:         -0.0°C  (high = +95.0°C, hyst =  +3.0°C)
                       (crit = +105.0°C, hyst =  +5.0°C)
                       (emerg = +135.0°C, hyst =  +5.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +47.0°C  (high = +86.0°C, crit = +100.0°C)
Core 0:        +44.0°C  (high = +86.0°C, crit = +100.0°C)
Core 1:        +47.0°C  (high = +86.0°C, crit = +100.0°C)

# this is how it looks like if I use nvidia gpu
mv@mv-pc:/sys/bus/pci/devices/0000:01:00.0$ DRI_PRIME=1 glxspheres64 & sleep 1 && cat enable & sleep 1 && sensors
[1] 24329
[2] 24330
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0x105
Context is Direct
OpenGL Renderer: NVC1
2
nouveau-pci-0100
Adapter: PCI adapter
GPU core:     +0.98 V  (min =  +0.83 V, max =  +1.00 V)
temp1:        +41.0°C  (high = +95.0°C, hyst =  +3.0°C)
                       (crit = +105.0°C, hyst =  +5.0°C)
                       (emerg = +135.0°C, hyst =  +5.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +49.0°C  (high = +86.0°C, crit = +100.0°C)
Core 0:        +44.0°C  (high = +86.0°C, crit = +100.0°C)
Core 1:        +48.0°C  (high = +86.0°C, crit = +100.0°C)

[2]+  Fertig                  sleep 1 && cat enable
mv@mv-pc:/sys/bus/pci/devices/0000:01:00.0$ 61.987061 frames/sec - 54.496545 Mpixels/sec
59.892718 frames/sec - 52.655282 Mpixels/sec
59.840096 frames/sec - 52.609018 Mpixels/sec

[1]+  Fertig                  DRI_PRIME=1 glxspheres64

if your nvidia gpu isnt properly supported by nouveau you could just install intel driver (and maybe setup manually), then hopefully nvidia gpu does also not draw much power

sorry for bad english


#104

@sathiel i think @petsam has a very valid point. often this happens where someone uses bumblebee, then tries optimus-manager, then nouveau, settings seem to always linger around causing any further attempts to throw false negatives in terms of what the problem is.
since we know bumblebee wont work considering acpi_osi=! is needed but also breaks touchpad, your left with 2 options. either make nouveau work or make optimus-manager work. either way, starting off with free drivers on a fresh install is the way to go, no bumblebee settings, adding/removing users to groups.
unless you have anything important just wipe it all out, or backup your home folder and then clean install and dont restore the home folder until the new installed is configured properly.

also, remove any devices that are not absolutely crucial to the function of your laptop, usb devices, etc… before the new install to avoid any conflict it/they may or may not have. you can easily plug them in later.

both nouveau and optimus-manager are capable of completely disabling the nvidia gpu.


#105

Ok then, I will try to do fresh install again. Keep your fingers crossed, I will report back soon :wink:

EDIT
So I have installed fresh system using free drivers (no additional options were needed for installation, but I need nouveau.modeset=0 to boot). Updated whole system using pacman -Syu, and installed latest kernel after. Also installed yay. These are all the changes I made to fresh installation. I’ve also created full system snapshot with timeshift so we can now mess with it without the need of full reinstal / initial setup. I’m going to try optimus-manager first. Is there anything specific I should do, or just follow https://wiki.manjaro.org/index.php?title=Optimus_Manager

current xrandr --listproviders

xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:Intel

Nvidia gpu is not powering off, touchpad is working.

EDIT 2
I’m lost… I can’t get optimus manager to work. With default settings I can’t get past login screen (hard freeze when trying to login or switch to TTY). Only way I can get it to boot is changing switcher to bbswitch (default is nouveau), and then I need to put acpi_osi= options to boot again -_-
I have reverted system using timeshift, and now I am on video-linux driver.

xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:Intel

There are no config files in /etc/X11 or any of subfolders. Also no modules blacklisted in /etc/modprobe.d/ and ofc touchpad is working and nvidia card is not powering off.


#106

you could try with modesetting instead of intel, maybe that helps with the gpu issue

(if you remove xf86-video-intel it should use modesetting. if stuck in black screen, switch to another tty [ctrl+alt+f2-6]) login and reinstall xf86-video-intel again. at least pc should then boot to desktop again )

(https://wiki.archlinux.org/index.php/kernel_mode_setting)

edit:


#107

the very odd thing with his laptop is if the nvidia gpu is turned off, he has no touchpad. if he uses bumblebee he can only boot with acpi_osi=! which also happens to break the touchpad’s functionality.
nouveau works and touchpad works but the fans run constant unless using an ACPI call to power off the gpu. then the battery life gets good but the touchpad is also no longer working.

maybe finding a different way to disable the nvidia card or even just get a hold fan control would do the trick.
the other thinking i had was try optimus-manager since it also gives you 2 different ways of pwering down the nvidia gpu. its all guesses though i admit.


#108

nouveau seems not really support this gpu (https://nouveau.freedesktop.org/wiki/CodeNames/ https://bbs.archlinux.org/viewtopic.php?id=230959).

if you try to turn gpu off via sysfs (ensure no driver for gpu is loaded) ? does this also affect touch pad


#109

from what i understand, he doesnt want to use the nvidia gpu at all but he has no option in bios to disable it.

i dont know that method but i refuse to believe that there is no way to disable the gpu without disabling the touchpad. how does the sysfs method work?


#110

e.g.
sudo -i
echo 1 > “/sys/bus/pci/devices/bus_id/remove” (e.g. echo 1 > “/sys/bus/pci/devices/0000:01:00.0/remove” )

but I#m not sure if this really stop the gpu from drawing power (but lspci doesn’t show the gpu anymore)


#111

only one way to find out :fearful:


#112
lspci -k
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05)
	Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 05)
	Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04)
	DeviceName:  Onboard IGD
	Subsystem: ASUSTeK Computer Inc. Device 1bb0
	Kernel driver in use: i915
	Kernel modules: i915
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
	Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31)
	Subsystem: ASUSTeK Computer Inc. Sunrise Point-H USB 3.0 xHCI Controller
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci
00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31)
	Subsystem: ASUSTeK Computer Inc. Sunrise Point-H Thermal subsystem
	Kernel driver in use: intel_pch_thermal
	Kernel modules: intel_pch_thermal
00:15.0 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Serial IO I2C Controller #0 (rev 31)
	Subsystem: ASUSTeK Computer Inc. Sunrise Point-H Serial IO I2C Controller
	Kernel driver in use: intel-lpss
	Kernel modules: intel_lpss_pci
00:16.0 Communication controller: Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 (rev 31)
	Subsystem: ASUSTeK Computer Inc. Sunrise Point-H CSME HECI
	Kernel driver in use: mei_me
	Kernel modules: mei_me
00:17.0 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 31)
	Subsystem: ASUSTeK Computer Inc. 82801 Mobile SATA Controller [RAID mode]
	Kernel driver in use: ahci
	Kernel modules: ahci
00:1c.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #5 (rev f1)
	Kernel driver in use: pcieport
00:1c.5 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #6 (rev f1)
	Kernel driver in use: pcieport
00:1c.6 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #7 (rev f1)
	Kernel driver in use: pcieport
00:1f.0 ISA bridge: Intel Corporation HM175 Chipset LPC/eSPI Controller (rev 31)
	Subsystem: ASUSTeK Computer Inc. Sunrise Point-H LPC Controller
00:1f.2 Memory controller: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller (rev 31)
	Subsystem: ASUSTeK Computer Inc. Sunrise Point-H PMC
00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
	Subsystem: ASUSTeK Computer Inc. CM238 HD Audio Controller
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel
00:1f.4 SMBus: Intel Corporation 100 Series/C230 Series Chipset Family SMBus (rev 31)
	Subsystem: ASUSTeK Computer Inc. Sunrise Point-H SMBus
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801
01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev a1)
	Subsystem: ASUSTeK Computer Inc. GP107M [GeForce GTX 1050 Mobile]
	Kernel modules: nouveau
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
	Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
	Kernel driver in use: r8168
	Kernel modules: r8169, r8168
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01)
	Subsystem: ASUSTeK Computer Inc. RTS5229 PCI Express Card Reader
	Kernel driver in use: rtsx_pci
	Kernel modules: rtsx_pci
04:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
	Subsystem: Intel Corporation Dual Band Wireless-AC 8265
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

Nvidia is at 01:00.0, but

[jakub-pc ~]# echo 1 > “/sys/bus/pci/devices/0000:01:00.0/remove”
-bash: “/sys/bus/pci/devices/0000:01:00.0/remove”: Nie ma takiego pliku ani katalogu

/no such file or directory/

@dglt it’s not really about bumblebee alone - every time I use bbswitch I need to use acpi_osi=. It happens on bumblebee, nouveau with bbswitch, and optimus-manager with bbswitch switching method selected. I cannot prove it but it looks like bumblebee is not the problem here.

Also I’ve found this during research
https://github.com/Bumblebee-Project/bbswitch/issues/170
So it’s unlikely it will have any impact
https://nouveau.freedesktop.org/wiki/FeatureMatrix/
So if I understand it correctly - we’re out of options - nouveau is not there yet, and bbswitch(and bumblebee) needs acpi_osi= params…

Too bad, I had really high hopes for this :confused:


#113

i still think your best bet is a clean install, backup with timeshift, and then try again. the reason i say timeshift is that it makes it incredibly easy to return to a state before messing with anything and any changes you make can easily be reset in a matter of a minute or two.


#114

That’s what I was doing last two days. I think I’ve tested every possible thing anyone suggested here and then some on my own. Only thing left now is acpi_call but as I understand it is somehow dangerous to do that. Check post #105


#115

my bad, read so many posts in so many threads i start confusing/forgetting them.


#116

Not dangerous, difficult, but now you have lot of experience.
In fact, every system change is potentially dangerous. :anguished:


#117

I’m not scared to break the system, I thought it can damage hardware somehow(silly me). Ok then, I will try to do that tomorrow :slight_smile: Actually thinking about it, with acpi_call brief first try I was closest to achieve the goal, as the “test script” did exactly what I wanted - turned off the gpu with touchpad intact. So what’s left to do is to make the change permanent.


#118

:exploding_head:

was there another time you were able to get acpi_call to power down nvidia and not take the touchpad with it?


#119

Oh I see what I did there. What happened was - test script worked fine, turned off the gpu without breaking touchpad and estimated battery life went up x2. But when I put proper call in /etc/tmpfiles.d/acpi_call.conf it broke the touchpad after reboot. By “test script” I mean:

Once installed load the kernel module:

# modprobe acpi_call

With the kernel module loaded run the following:

# /usr/share/acpi_call/examples/turn_off_gpu.sh

This script will go through all the known data buses and attempt to turn them off. You will get an output similar to the following:

Trying \_SB.PCI0.P0P1.VGA._OFF: failed
Trying \_SB.PCI0.P0P2.VGA._OFF: failed
Trying \_SB_.PCI0.OVGA.ATPX: failed
Trying \_SB_.PCI0.OVGA.XTPX: failed
Trying \_SB.PCI0.P0P3.PEGP._OFF: failed
Trying \_SB.PCI0.P0P2.PEGP._OFF: failed
Trying \_SB.PCI0.P0P1.PEGP._OFF: failed
Trying \_SB.PCI0.MXR0.MXM0._OFF: failed
Trying \_SB.PCI0.PEG1.GFX0._OFF: failed
Trying \_SB.PCI0.PEG0.GFX0.DOFF: failed
Trying \_SB.PCI0.PEG1.GFX0.DOFF: failed
Trying \_SB.PCI0.PEG0.PEGP._OFF: works!
Trying \_SB.PCI0.XVR0.Z01I.DGOF: failed
Trying \_SB.PCI0.PEGR.GFX0._OFF: failed
Trying \_SB.PCI0.PEG.VID._OFF: failed
Trying \_SB.PCI0.PEG0.VID._OFF: failed
Trying \_SB.PCI0.P0P2.DGPU._OFF: failed
Trying \_SB.PCI0.P0P4.DGPU.DOFF: failed
Trying \_SB.PCI0.IXVE.IGPU.DGOF: failed
Trying \_SB.PCI0.RP00.VGA._PS3: failed
Trying \_SB.PCI0.RP00.VGA.P3MO: failed
Trying \_SB.PCI0.GFX0.DSM._T_0: failed
Trying \_SB.PCI0.LPC.EC.PUBS._OFF: failed
Trying \_SB.PCI0.P0P2.NVID._OFF: failed
Trying \_SB.PCI0.P0P2.VGA.PX02: failed
Trying \_SB_.PCI0.PEGP.DGFX._OFF: failed
Trying \_SB_.PCI0.VGA.PX02: failed

See the "works"? This means the script found a bus which your GPU sits on and it has now turned off the chip. To confirm this, your battery time remaining should have increased.

Currently, the chip will turn back on with the next reboot. To get around this, add the kernel module to the array of modules to load at boot: 
/etc/modules-load.d/acpi_call.conf

#Load 'acpi_call.ko' at boot.

acpi_call

To turn off the GPU at boot it is possible to use systemd-tmpfiles.

/etc/tmpfiles.d/acpi_call.conf


w /proc/acpi/call - - - - \\_SB.PCI0.PEG0.PEGP._OFF

So probably the easiest method to do that would be to erase failed calls from the script and make it run at the boot or login? Sorry for the confusion, I was really tired at that point.


#120

yeah, if that powers down gpu without taking the touchpad with it then absolutely. i honestly dont know why the command itself would do it but not the test script but hey, if it works, it works