You are not logged in.
# cat /sys/bus/pci/devices/0000\:01\:00.0/power/control
If this command returns auto, you have it enabled. If you can load the NVIDIA driver, I think it is on.
It's "on".
- Updated /etc/bumblebee/bumblebee.conf so that for [driver-nvidia] PMMethod=none (without this, I get a lockup at boot)
[...]
After a normal boot, I manually loaded bbswitch (sudo modprobe bbswitch), then was able to enable/disable the GPU with:
sudo tee /proc/acpi/bbswitch <<<ON
sudo tee /proc/acpi/bbswitch <<<OFF
Disabling automatic power management would make the GPU be on when starting X even if bumblebee is installed, so that would make sense. However, I don't see how this would affect the underlying issues that are caused by changing the GPU power state when you do it manually. Sure you tested that enough times?
For those not following the Kernel bug, see comment 32 on the below. A patch has been submitted to the LKML. With any luck it will be accepted and be in 4.10. Obviously doesn't solve the current need to downgrade to nvidia 375.26-6, but encouraging nonetheless!
Cheers! Had not come across this even after some searching. Latest comment from today mentions it working on this model. Updated original post with the link.
Offline
I see you are using Ubuntu in your gist? What version of the nvidia driver is currently bundled?
It's kde neon, built over ubuntu. I am using nvidia-375
Your touchpad doesn't work because of this:
The touchpad works ok most of the time, but freezes a couple of milliseconds while doing anything. It freezes more when your CPU is jumping frequencies, I am told it looses sync because of this change in frequency. I managed to solve this problem using: "psmouse.resetafter=0" flag in boot config. Most of the freezing is gone, but it's still not smooth alwaays.
Offline
patrickb wrote:I see you are using Ubuntu in your gist? What version of the nvidia driver is currently bundled?
It's kde neon, built over ubuntu. I am using nvidia-375
Ah, yup. That's why your driver loads. Arch is currently ahead at 378 something. So we have to downgrade the package.
patrickb wrote:Your touchpad doesn't work because of this:
The touchpad works ok most of the time, but freezes a couple of milliseconds while doing anything. It freezes more when your CPU is jumping frequencies, I am told it looses sync because of this change in frequency. I managed to solve this problem using: "psmouse.resetafter=0" flag in boot config. Most of the freezing is gone, but it's still not smooth alwaays.
Interesting. That flag hasn't come up in the conversation yet. Although the ultimate fix is the patch that was proposed in the LKML for kernel 4.10. Haven't checked if it's accepted yet, but reports of the plain 4.10 kernel working suggests it's been incorporated.
Offline
I can confirm that the kernel patch resolves the hardlocks (I have also patched the 4.9.11 mainline kernel). I also quickly checked for the changes in the 4.10 kernel release, but did not find them there.
Anyway, I am having trouble satisfying bumblebee dependencies when downgrading to nvidia-375. I had uninstalled bumblebee to downgrade nvidia via
pacman -U nvidia-375-26-[...].pkg.tar.xz nvidia-utils-375-26-[...].pkg.tar.xz
But now any attempt to re-install bumblebee ends in a conflict:
$pacman -S bumblebee
resolving dependencies...
looking for conflicting packages...
:: bumblebee and nvidia-utils are in conflict (nvidia-libgl). Remove nvidia-utils? [y/N] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: bumblebee and nvidia-utils are in conflict
Any hints on how to proceed?
Edit: I ended up re-building the nvidia package (and nvidia-utils) to be compatible with the kernel. At that point, I've removed nvidia-libgl from the PKGBUILD. Quite dirty, but should be enough until NVIDIA releases working drivers. All seems to work fine now, including optirun.
Last edited by zzzad (2017-02-23 16:32:35)
Offline
At that point, I've removed nvidia-libgl from the PKGBUILD. Quite dirty, but should be enough until NVIDIA releases working drivers.
Can you please be more elaborate on that step? Quite new to arch and my tries to manualy install the old package without nvidia-libgl all failed due to non-existance of the file libnvidia-egl-wayland.so.1.0.1
Anyway, great news you made it functional!
Got my XPS15 yesterday and so far except this bug I don't experience any problems, tough I also don't have any adapters or docks yet.
Offline
patrickb wrote:I see you are using Ubuntu in your gist? What version of the nvidia driver is currently bundled?
It's kde neon, built over ubuntu. I am using nvidia-375
patrickb wrote:Your touchpad doesn't work because of this:
The touchpad works ok most of the time, but freezes a couple of milliseconds while doing anything. It freezes more when your CPU is jumping frequencies, I am told it looses sync because of this change in frequency. I managed to solve this problem using: "psmouse.resetafter=0" flag in boot config. Most of the freezing is gone, but it's still not smooth alwaays.
It might be worth trying to blacklist psmouse module entirely. I've done so to remove the dmesg error:
psmouse serio1: synaptics: Unable to initialize device dell xps
When I did so, I also noticed that the touchpad tap lag I was experiencing disappeared (I'm using libinput drivers).
Offline
I got my new XPS 9560 this week and I had some troubles with my video card as well and I couldn't make it run. after installing, removing and installing other stuff as well, I ended up with installing wayland wich works without gpu I think.
Last edited by danielstaleiny (2017-02-28 18:15:56)
Offline
A new BIOS version was just released with the following notes:
Enhancements:
1. Improved the DELL Thunderbolt(TM) Dock stability.
2. Improved the System Stability During Cold Boot , Warm Boot and Hibernation.
3. Improved the NVIDIA(R) GeForce(R) Card stability.
Offline
Can you please be more elaborate on that step? Quite new to arch and my tries to manualy install the old package without nvidia-libgl all failed due to non-existance of the file libnvidia-egl-wayland.so.1.0.1
I downloaded the PKGBUILD for the 375 nvidia and nvidia-utils package from git (there is a download packages-... link)
* https://git.archlinux.org/svntogit/pack … 2e0fbb3ac3
* https://git.archlinux.org/svntogit/pack … 9266476c8e
and then manually removed 'nvidia-libgl' from the 'provides' entry at PKGBUILD:90 of the nvidia-utils package. Not sure I would recommend it as a general solution and I am happy to get back to the pre-build packages.
You might skip re-building the nvidia package if you haven't patched the kernel.
Last edited by zzzad (2017-02-25 20:29:05)
Offline
These are all MOSTLY the same existing warnings and errors I get on my XPS 9550 - except the nvidia specific ones (trouble with X etc, but I do get the exact same warnings from acpi when either activating or de-activating the nvidia card, aswell as plugging in our out the AC-adapter. I suspect the motherboard is pretty much the same (correct me if I am wrong). The BIOS does indeed have exceptions for "_OSI=LINUX" (atleast 1.2.19) but makes very little difference to anything really. Backlight and keyboard-backlight works out of the box on mine with Cinnamon desktop and linux-ck kernel.
I have the FHD (Sharp) display, 512Gb PCIe, i7-6600HQ, 32GB RAM and the 84WHR battery.
Offline
A new BIOS version was just released with the following notes:
Enhancements:
1. Improved the DELL Thunderbolt(TM) Dock stability.
2. Improved the System Stability During Cold Boot , Warm Boot and Hibernation.
3. Improved the NVIDIA(R) GeForce(R) Card stability.
Just FWIW, this makes no difference to the bbswitch OFF => lockup issue (using the current kernel that is). Just thought I'd try it. You know, just in case.
[edit] And I my TB16 just arrived on my desk, so it seemed appropriate to do now.
Last edited by patrickb (2017-02-28 06:01:18)
Offline
pl wrote:A new BIOS version was just released with the following notes:
Enhancements:
1. Improved the DELL Thunderbolt(TM) Dock stability.
2. Improved the System Stability During Cold Boot , Warm Boot and Hibernation.
3. Improved the NVIDIA(R) GeForce(R) Card stability.Just FWIW, this makes no difference to the bbswitch OFF => lockup issue (using the current kernel that is). Just thought I'd try it. You know, just in case.
[edit] And I my TB16 just arrived on my desk, so it seemed appropriate to do now.
I'm running Linux Mint 18 Cinnamon (don't shoot!) on a Dell XPS 15 (9560) and was having problems with the 1050 video card.
I wanted to add that, while the new 1.1.3 BIOS did not fix the bbswitch / nvidia-prime select issue it did allow me to USE the 1050 instead of the intel graphics. Prior to the BIOS update I was unable to get the 1050 to work at all. Now I can successfully use it by selecting the 375 drivers in Driver Manager and selecting the NVIDIA GPU in the PRIME profile section of NVIDIA X Server Settings.
Offline
pl wrote:A new BIOS version was just released with the following notes:
Enhancements:
1. Improved the DELL Thunderbolt(TM) Dock stability.
2. Improved the System Stability During Cold Boot , Warm Boot and Hibernation.
3. Improved the NVIDIA(R) GeForce(R) Card stability.Just FWIW, this makes no difference to the bbswitch OFF => lockup issue (using the current kernel that is). Just thought I'd try it. You know, just in case.
[edit] And I my TB16 just arrived on my desk, so it seemed appropriate to do now.
Thanks for testing this! I was actually gonna ask if someone here wanted to try this just to get clarity if it had any effect... I've got a pretty elaborate work session loaded with a working configuration so not able to revert and boot that easily at the moment
Offline
patrickb wrote:pl wrote:A new BIOS version was just released with the following notes:
Just FWIW, this makes no difference to the bbswitch OFF => lockup issue (using the current kernel that is). Just thought I'd try it. You know, just in case.
[edit] And I my TB16 just arrived on my desk, so it seemed appropriate to do now.
Thanks for testing this! I was actually gonna ask if someone here wanted to try this just to get clarity if it had any effect... I've got a pretty elaborate work session loaded with a working configuration so not able to revert and boot that easily at the moment
Yeah, I had to completely rearrange my desk for the TB16 anyway, so it seemed as good as any chance to try.
Offline
Okay, so according to the Bumblebee issue tracker, the kernel patch was not accepted upstream. I haven't looked into why; however, all the patch did was forced the selection of a specific ACPI revision. This we knew already. What didn't occur to any of us, was to look for a kernel parameter to force the ACPI revision used by the kernel. I'm now writing this message with the nvidia card disabled!
acpi_rev_override=5
Last edited by patrickb (2017-02-28 20:30:48)
Offline
Darn. I've come too soon. No matter what I echoed into /proc/bbswitch, it always returned ON. TLP is messing with things. Standby.
Offline
It seems that something else entirely is going on with my machine as even going back to the "broken" configuration, I can't switch the nvidia card off. The only thing I'm aware of that I have changed is the BIOS update mentioned above. That's a hard supposition to validate unless somebody else wants to try before and after the bios update...
Offline
I have to do some real work now, but here are my findings with the acpi_rev_override=5 flag set against the 4.9.11 kernel:
1) Sometimes I can set bbswitch to OFF, sometimes it just stays ON no matter what. If I do manage to set it to off, then I get a kernel hard lock immediately afterwards.
2) Sometimes the 375 version of the nvidia driver (built agains the 4.9.11 kernel) refuses to load claiming it can't detect the device, other times it loads fine (the nVidia forums suggest this means the device has been powered off by bbswitch).
3) Booting windows in between appears to make no difference.
Offline
patrickb: Try pressing the power button for 4 seconds while the computer is on. I got into a somewhat similar cycle at one point during testing and no amount of regular poweroffs or restarts helped.
Other than that, the only case where I have been unable to turn off the GPU has been with the 378 driver loaded after trying optirun. Writing OFF to the bbswitch file just did nothing afterwards unless booted.
I'll try giving the acpi revision as a kernel parameter after you've found out what is behind your current odd state... just in case this started after that
Offline
patrickb: Try pressing the power button for 4 seconds while the computer is on. I got into a somewhat similar cycle at one point during testing and no amount of regular poweroffs or restarts helped.
Other than that, the only case where I have been unable to turn off the GPU has been with the 378 driver loaded after trying optirun. Writing OFF to the bbswitch file just did nothing afterwards unless booted.
I'll try giving the acpi revision as a kernel parameter after you've found out what is behind your current odd state... just in case this started after that
Okay so, my odd current state was a little PEBKAC. I was running bumblebee with PMMethod set to "none" to avoid the hangup issue. That means bumblebee loads the nvidia module. The card can't be powered down with the module loaded. So no ACTUAL issue there.
I have also learned that the acpi revision override flag is boolean. I.E, if it is true then version 5 is used, if it is false then version 6 (which confusingly seems to actually be numbered "2" in the ACPI standard) is used. (From my brief skim of the code though, 5 should have evaluated to true.) Others are reporting that setting the flag solves their issue. For me, I still get the lockups.
My versions:
Kernel: 4.9.11
BIOS: 1.1.3
nvidia-dkms 375.26-6
nvidia-settings 375.26-1
nvidia-utils 375.26-4
bbswitch 0.8-63
bumblebee 3.2.1-13
Offline
patrickb: is the kernel you are using compiled with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE defined? I don't think the default Arch kernel is. I had to change it manually in the config when building the custom kernel using ABS, and I don't think it will work without it.
Checked both the original patch and the kernel-parameters documentation. The possible values for acpi_rev_override are 1 and 0, with 1 forcing it to revision 5 and 0 is the default revision 2. Additionally:
acpi_rev_override [ACPI]
Override the _REV object to return 5 (instead
of 2 which is mandated by ACPI 6) as the supported ACPI
specification revision (when using this switch, it may
be necessary to carry out a cold reboot _twice_ in a
row to make it take effect on the platform firmware).
Maybe force hardware shutdown the machine twice?
Offline
patrickb: is the kernel you are using compiled with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE defined? I don't think the default Arch kernel is. I had to change it manually in the config when building the custom kernel using ABS, and I don't think it will work without it.
Checked both the original patch and the kernel-parameters documentation. The possible values for acpi_rev_override are 1 and 0, with 1 forcing it to revision 5 and 0 is the default revision 2. Additionally:
acpi_rev_override [ACPI]
Override the _REV object to return 5 (instead
of 2 which is mandated by ACPI 6) as the supported ACPI
specification revision (when using this switch, it may
be necessary to carry out a cold reboot _twice_ in a
row to make it take effect on the platform firmware).Maybe force hardware shutdown the machine twice?
I saw the hardware shutdown thing too actually and gave it a try...just forgot to mention it; however.....
pat-laptop:/home/pat# zcat /proc/config.gz | grep CONFIG_ACPI_REV_OVERRIDE_POSSIBLE
# CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set
Looks like it's time to build a kernel. (Well, actually, it's time to go to bed, but maybe after that!)
Offline
Nothing wrong with building a kernel in bed
Offline
Nothing wrong with building a kernel in bed
Pretty sure that's going to be a tough sell!
Offline
Indeed that solves the issue. An irritating amount of custom going on between nvidia drivers and kernels now though. And it did initially break the TB16, but a hard reboot seems to have resolved that. Otherwise, everything now works!
@pl - how long did your kernel build take? I was slightly disappointed. I'd hoped for maybe sub five minutes, but it was closer to 45 minutes. (Though to be fair, last time I built a kernel it took 16 ish hours.)
Offline