I have Asus GL753VE laptop with Nvidia 1050Ti running linux 4.14 with driver 384.98 and bios 306 on Debian Unstable.
When I use bumblebee and bbswitch to power the nvidia GPU on and run software via primusrun, everything works perfectly, glxinfo reports correct values, and graphics are accelerated as they should be.
However, when the primus process has finished running and bbswitch powers the nvidia GPU off, after 5-10 seconds system fan spins up to 100% speed and is stuck there, permanently, creating huge amount of noise. There is no method to spin it down other than completely power off the system (reboot is not enough).
This issue is also present on some other laptop models. It has been reported to every relevant project and discussed in depth but to no avail on this particular laptop model:
This issue has been also reported to AsusTek Computer Inc by multiple customers, but that company has not even acknowledged that the bug exists:
Currently as a workaround I am running xorg and everything else directly through mechanism described here Chapter 32. Offloading Graphics Display with RandR 1.4
but a solution to the bbswitch issue would be preferred.
Reporting this to nvidia is basically last resort.
Thank you in advance for any information you can provide to help fix this.
You are hit by this bug:
[url]Invalid Bug ID
The easy workaround would be to use kernel parameter
acpi_osi=! acpi_osi=“Windows 2009”
Unfortunately, on your model probably your touchpad won’t work then. To work around that, you have to change an acpi table and load that on boot. Luckily one of the previous users wrote a howto after fiddling this out on the bumblebee issue you mentioned.
[url]https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-306543064[/url]
I have tried various combinations of acpi_osi, acpi_rev_override and pcie_port_pm kernel parameters, including the one you have posted, but none of them have resulted in fixing of the stuck fan ( but I can confirm that you are correct about disabled touchpad with acpi_osi=“Windows 2009” ).
I will give the described ACPI table patching method a try.
Looking at the acpidump, the kernel parameter should reliably work around the issue. Since it doesn’t, this seems to be something new. Can you attach a dmesg output from when the issue hits, with kernel paramter set?
The lines up to the last with 7.15… timestamp are what’s there immediately after boot.
The lines with 106.88… timestamps are what’s added when I manually start bumblebee service ( service bumblebeed start ).
About 20-30 seconds after performing that command, the fan started to spin at maximum speed and is still doing it.
No luck, then.
Though it’s not the same, maybe attach to the mentioned kernel bug report and upload your acpidump there. Perhaps someone has an idea there.
If you want to use bumblebee, you would have to disable bbswitch to not run into that issue. The dGPU will not be powered down then, leaving you with a higher power consumption.
My concerns are that when the dGPU fails to power off it seems to get into a full throttle situation, is heating up so the fans start to run. You should be able to check that using powertop. Question is, what’s happening on a system suspend? If the dGPU is still on, but the fans are off, this might get ugly.