Dell XPS 15 9560 (Early 2017)

dtzWill · 2017-03-03 15:46:40

Thanks for all the information and investigation about this, made setting up my laptop much easier!

@pl: Would you mind mentioning that if your kernel already has "CONFIG_ACPI_REV_OVERRIDE_POSSIBLE" enabled then a kernel parameter is all that's needed instead of a patch/rebuild? AFAICT "acpi_rev_override=5" does the same thing as the patch. I just checked on my Arch machine and it appears the config is not already there, but folks with similar problems on other distributions might stumble upon this thread as well . Thanks!

randm · 2017-03-04 20:06:09

Just wanted to update you guys that I have my setup running almost flawlessly with the suggested changes to the 4.9 Kernel (CONFIG_ACPI_REV_OVERRIDE_POSSIBLE set and patch applied) and the nvidia 375 driver, at this point I do not use additional kernel parameters. Bumblebee and BBSwitch work as expected. I had a blast with this machine last week at work (Software Engineer here). An external 4k monitor is plugged in to the Thunderbolt 3 port, and I run Chrome and IntelliJ IDEA with optirun to optimize performance.
One issue remains, though: After I suspend the machine and start up again, the programs that were running with optirun are frozen and need to be restarted. Is there a way to prevent that?

pl · 2017-03-05 10:59:45

patrickb wrote:

@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.)

Maybe 20 minutes. Don't quote me on that. Do you have multithreaded building enabled? If you are using ABS and makepkg, a way to enable it is by adding MAKEFLAGS="-j9" to /etc/makepgk.conf

dtzWill wrote:

@pl: Would you mind mentioning that if your kernel already has "CONFIG_ACPI_REV_OVERRIDE_POSSIBLE" enabled then a kernel parameter is all that's needed instead of a patch/rebuild? AFAICT "acpi_rev_override=5" does the same thing as the patch. I just checked on my Arch machine and it appears the config is not already there, but folks with similar problems on other distributions might stumble upon this thread as well . Thanks!

Sorry I'm a bit behind with the updates because of the weekend. Just came here to do that It's just "acpi_rev_override" without the =5 though, since it's a flag to override the default ACPI revision reported. Or am I mistaken? Should not matter if you give it additional parameters though, they'd just be discarded. (EDIT: removed =1 that I had typed originally)

randm wrote:

One issue remains, though: After I suspend the machine and start up again, the programs that were running with optirun are frozen and need to be restarted. Is there a way to prevent that?

I have the same setup as you and this same problem -- even though it has not been an issue since I don't run anything persistent through optirun. If you constantly keep part of your dev environment running with the GPU on, I would recommend using a plain nvidia session instead of bumblebee.

Last edited by pl (2017-03-15 12:43:45)

randm · 2017-03-05 14:07:22

pl wrote:

I have the same setup as you and this same problem -- even though it has not been an issue since I don't run anything persistent through optirun. If you constantly keep part of your dev environment running with the GPU on, I would recommend using a plain nvidia session instead of bumblebee.

So how do you utilize the NVIDIA GPU if you don't run programs with optirun? Does it automatically pipe graphic-intensive tasks through the card? I'm quite new to Linux, sorry if I'm missing something obvious here...

pl · 2017-03-05 18:57:10

randm wrote:

So how do you utilize the NVIDIA GPU if you don't run programs with optirun? Does it automatically pipe graphic-intensive tasks through the card? I'm quite new to Linux, sorry if I'm missing something obvious here...

I think with recent laptops the same integrated side framebuffer is always used regardless of which GPU is used for rendering. If you uninstall bumblebee and intel and follow https://wiki.archlinux.org/index.php/NVIDIA_Optimus using nvidia (most of the stuff is outdated and for older versions, the setup is actually quite simple these days and differs little from a nvidia-only desktop) you should get a setup where the discrete GPU is used for all rendering and you don't have to worry about there being a hybrid graphics solution underneath.

The default dpi will be quite tiny, but adding xrandr --dpi 96 (or something else) into your xinitrc will solve this. Other than that it seemed to work well when I tried it. Let me know if you try it and face anything weird.

Of course, you still need to use the 375 driver for now and you'll lose a few hours of battery life from the discrete GPU being on -- but from what I understand you do that anyway currently by optirunning some of your constantly active software.

randm · 2017-03-06 08:52:04

Thanks for the comprehensive answer

pl wrote:

...but from what I understand you do that anyway currently by optirunning some of your constantly active software.

No, I have this script

#!/usr/bin/env bash

if grep -q 1 "/sys/class/power_supply/AC/online"; then
    /usr/bin/optirun $1
else
    $2
fi

with which I start Chrome and IntelliJ IDEA. So only if I'm starting these programs on AC power optirun is used, if I start them on battery the discrete card stays inactive. Battery life is preserved this way (it's important to me) but I can have full performance when working on AC. Would you suggest doing something else?

pl · 2017-03-06 19:13:56

Alright then. You'd have to restart X to change between an Intel-only session for unplugged use and an nvidia session for plugged-in use, since the Optimus setup does not support switching on the fly. If that is less of a hassle for you with your work habits than broken programs when suspending, it might be worth taking a look at. Otherwise probably not!

Out of curiosity... do those two programs really gain much in your use from being drawn on the discrete GPU for regular use? I personally currently do WebGL stuff at work and don't even bother with running the browser using the discrete GPU, since the integrated GPU is capable of more than 60fps even with the 4k resolution.

I'm sorry, both my original suggestion and this one are kind of lacking for not really knowing what use case you are really trying to solve ... If you only run the programs on the discrete graphics card when plugged in, what is suspend used for? To move between two plugged-in locations? To just save some electricity when away from your desk? Since if you keep switching between optirunning them and not anyway depending on if you are on the move during the same session, maybe the least hassle currently is to just change to not-optirunning them before suspending and keep the setup otherwise as you have it now. Hope you find a working solution!

tillux · 2017-03-12 13:36:25

Mesa with liglvnd support is now in testing is actually already in stable (I think) and might help resolve some of the issues. Also, kernel 4.10.1 is in stable aswell, though I think acpi_rev_override will still be needed. However, no new nvidia drivers are available yet from the repos (current official version over at nvidia is 378.78 released on 09/03/2017 dd/mm/yyyy) and I haven't gotten around to try to build the 375 ones in conjunction with the new libgl stuff. Will post an update when I either did that or driver version 378.78 is available from the arch repos.

hedgepigdaniel · 2017-03-12 23:00:41

I've reported a bug in Arch Linux for the issue with bbswitch not working and kernel parameter acpi_rev_override=1 having no effect unless you recompile the kernel with a changed config: https://bugs.archlinux.org/task/53281

Please vote

Also, lol at how the reason the flag was disabled was because of a problem with audio on the Dell XPS 13: https://bugs.archlinux.org/task/47989

pl · 2017-03-13 10:08:50

I've encountered some problems after updating to 4.10. X still starts fine and I can turn the GPU on and off using bbswitch just fine when using acpi_rev_override, but suspend might hardlock the system as before. Since nothing else if affected, this leads me to think something has changed with timings and the GPU might not be properly on before a certain suspend point is reached. I'll try manually turning it ON before suspending for now to get more info.

I also get a bunch of machine check exceptions reported when I boot that don't appear on 4.9. Does anyone else see this?

Mar 11 19:55:51 funkei kernel: smpboot: CPU0: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (family: 0x6, model: 0x9e, stepping: 0x9)
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 6: ee2000000040110a
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: TSC 0 ADDR fef1ffc0 MISC 788000c086
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1489254948 SOCKET 0 APIC 0 microcode 48
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 7: ee2000000040110a
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: TSC 0 ADDR fef200c0 MISC 388000c086
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1489254948 SOCKET 0 APIC 0 microcode 48
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 8: ee2000000040110a
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: TSC 0 ADDR fef1ff40 MISC 788000c086
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1489254948 SOCKET 0 APIC 0 microcode 48
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 9: ee2000000040110a
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: TSC 0 ADDR fef1cec0 MISC 4388000c086
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1489254948 SOCKET 0 APIC 0 microcode 48

tillux wrote:

Mesa with liglvnd support is now in testing is actually already in stable (I think) and might help resolve some of the issues. Also, kernel 4.10.1 is in stable aswell, though I think acpi_rev_override will still be needed. However, no new nvidia drivers are available yet from the repos (current official version over at nvidia is 378.78 released on 09/03/2017 dd/mm/yyyy) and I haven't gotten around to try to build the 375 ones in conjunction with the new libgl stuff. Will post an update when I either did that or driver version 378.78 is available from the arch repos.

Current version of nvidia is still broken. Hope 378.78 fixes things, manually building the 375 one is quite cumbersome, especially if you want it for 32-bit applications as well. acpi_rev_override is indeed still needed, but like I mentioned above, suspend is again problematic after updating to 4.10. bbswitch has also gotten an update inbetween and it's hard to pinpoint something that might fail once every 20 times and sometimes 3 times in a row.

hedgepigdaniel wrote:

I've reported a bug in Arch Linux for the issue with bbswitch not working and kernel parameter acpi_rev_override=1 having no effect unless you recompile the kernel with a changed config: https://bugs.archlinux.org/task/53281
Please vote
Also, lol at how the reason the flag was disabled was because of a problem with audio on the Dell XPS 13: https://bugs.archlinux.org/task/47989

Thanks for creating that! I was thinking about doing the same but thought I'd ask on IRC first why it has disabled in the config in the first place. It seems a bit weird that the solution for the XPS 13 issue has been to disable the OPTION to use the override on any model instead of just not using it for the XPS 13. What am I missing? EDIT: Reading through the reports it seems it was disabled because it was thought that the XPS 13 issue was already fixed. The thread you linked to as a reason is actually people reporting that disabling it has caused issues for them.

Last edited by pl (2017-03-13 11:44:01)

hedgepigdaniel · 2017-03-13 11:46:31

pl wrote:

Current version of nvidia is still broken. Hope 378.78 fixes things, manually building the 375 one is quite cumbersome, especially if you want it for 32-bit applications as well. acpi_rev_override is indeed still needed, but like I mentioned above, suspend is again problematic after updating to 4.10. bbswitch has also gotten an update inbetween and it's hard to pinpoint something that might fail once every 20 times and sometimes 3 times in a row.

Do they do the same releases for linux and windows? When I check the Nvidia driver download site it still nominates 378.13 as the latest linux driver (released Feb 14), even though for example 378.47 for windows was out in January.

Cumbersome is right, I've been struggling all day trying to get it to work. The worst part is I had it working perfectly a few days ago but then I updated something and now I can't reproduce the working state.

pl wrote:

Thanks for creating that! I was thinking about doing the same but thought I'd ask on IRC first why it has disabled in the config in the first place. It seems a bit weird that the solution for the XPS 13 issue has been to disable the OPTION to use the override on any model instead of just not using it for the XPS 13. What am I missing? EDIT: Reading through the reports it seems it was disabled because it was thought that the XPS 13 issue was already fixed. The thread you linked to as a reason is actually people reporting that disabling it has caused issues for them.

Ah yes - that makes much more sense. Does seem like a strange choice to disable the flag, I would have thought it would be up to the user to turn it off if it became unnecessary (Doesn't everyone optimise their kernel parameters regularly?).

delvi932905 · 2017-03-15 13:29:22

Hi,
I have a "problem" with touchpad when I move mouse with tocuhpad, after login in kde (or some else envirement), I can hear sound such as a static noise. This sound is very low but I'm afraid that in the future it may cause problems for speakers. Someone can help me ?

randm · 2017-03-15 14:12:02

pl wrote:

Alright then. You'd have to restart X to change between an Intel-only session for unplugged use and an nvidia session for plugged-in use, since the Optimus setup does not support switching on the fly. If that is less of a hassle for you with your work habits than broken programs when suspending, it might be worth taking a look at. Otherwise probably not!
Out of curiosity... do those two programs really gain much in your use from being drawn on the discrete GPU for regular use? I personally currently do WebGL stuff at work and don't even bother with running the browser using the discrete GPU, since the integrated GPU is capable of more than 60fps even with the 4k resolution.
I'm sorry, both my original suggestion and this one are kind of lacking for not really knowing what use case you are really trying to solve ... If you only run the programs on the discrete graphics card when plugged in, what is suspend used for? To move between two plugged-in locations? To just save some electricity when away from your desk? Since if you keep switching between optirunning them and not anyway depending on if you are on the move during the same session, maybe the least hassle currently is to just change to not-optirunning them before suspending and keep the setup otherwise as you have it now. Hope you find a working solution!

Thanks for your in-dept analysis I didn't experience much performance gain from using the descrete card, so I got rid of that script again and don't use optirun directly anymore. I may use it in the future if I ever have to run a program that is graphic-intensive, like video editing and such.

My motivation to use optirun was based on two things:
1. Some of my collegues at work use Inspiron laptops, which apparently lag just by having a external 4k monitor plugged in and watching a youtube video. I feared that may also be the case with my XPS 15 so I wanted to prevent that from happening
2. I have a GTX card, so I may as well use it (if not on battery power)

But as you already said, it doesn't gain much, except some more heat and noise (from the fans). My working experience is very good without optirun, I will post again if that changes, but for now I'm very happy with my setup. Cheers!

Last edited by randm (2017-03-15 14:12:50)

pl · 2017-03-20 08:24:20

Anyone want to help me investigate the suspend issues that have appeared after 4.10? And maybe at least confirm they are seeing the machine check exceptions after poweron/resume.

It seems with default bumblebee/bbswitch config and acpi_rev_override kernel, resuming from suspend hardlocks the systems every third time.

This looks exactly like the behavior in 4.9 without boot flags or the kernel patch. However, turning the GPU on and off manually does not cause the hardlocks as without the workaround, so this might be an unrelated issue. My first guess was that it's some issue with changed timings and the GPU does not have enough time to power on before suspend in 4.10. So I've been manually turning it on before suspending now. This seemed to initially solve the issue, but after a few days and a few dozen suspends I've still got two hardlocks this way. Trying a fresh boot and a few suspends without manually setting the power state gave the one in three hardlocks again... So no certain reason yet. Maybe the GPU just sometimes fails to change power state or needs more time or seemingly changes it's state, that then results in suspending with it not being in the right state. No better guesses as of now.

The logs don't show anything after "has entered sleep state" after the hardlock. Is there some good way to gather info about this? Running the kernel with debug logging etc? It seems there are some other 4.10 suspend issue threads popping up so maybe this is completely unrelated to our previous GPU problems and the effects of the GPU state are just at most indirect timing/power management related factors in another problem.

hedgepigdaniel · 2017-03-20 08:57:02

I've been playing around with various power saving tweaks and the power consumption is now much lower. Currently I'm getting about 5.8W power consumption on idle with the screen on.

I've done the following:
- Compiled my own kernel including the ACPI_REV_OVERRIDE_POSSIBLE flag set and the nvme APST patches from here: https://github.com/damige/linux-nvme. I checked out 4.10.2 since that's the last kernel version that has worked for me. acpi_rev_override=1 is in the kernel parameters.
- installed bbswitch and bumblebee and enabled the bumblebeed service to disable the dGPU when it isn't used (I never use it)
- Applied module options to i915 (intel iGPU driver): enable_fbc=1 enable_psr=1 disable_power_well=0 (enable_psr=2 without setting disable_power_well also works, not sure if it makes any difference, enable_psr=1 on its own causes screen hangs)
- Installed TLP and enabled the service (default settings)
- Formatted my root partition as btrfs, and set the commit interval to 60 (1 minute)
- Re applied thermal paste to the CPU and GPU. CPU throttling is mostly gone, unsure if it makes the fans any more likely to turn off.

Unfortunately the nvidia card doesn't work with TLP unless you also add pcie_port_pm=off to the kernel parameters, which I think causes increased idle power usage. It's not required to just use bbswitch to disable it though.

If I disable the touchscreen in the BIOS, turn the screen to minimum brightness, turn the keyboard backlight off, and do nothing except occasionally type 'cat /sys/class/power_supply/BAT0/current_now' into the terminal, then the power consumption is typically about 5.8W, and the cinnamon battery indicator sais 13 hours remaining at 100% charge. Seems to make no difference if the wifi is on or off, although when its downloading power consumption spikes to 21W. I have yet to experiment with the iwlwifi settings.

Specs:
- i7 7700HQ
- Toshiba XG4 512GB SSD
- 4K screen
- intel 8265 wifi card

tuxcanfly · 2017-03-20 10:12:31

pl wrote:

I've encountered some problems after updating to 4.10. X still starts fine and I can turn the GPU on and off using bbswitch just fine when using acpi_rev_override, but suspend might hardlock the system as before. Since nothing else if affected, this leads me to think something has changed with timings and the GPU might not be properly on before a certain suspend point is reached. I'll try manually turning it ON before suspending for now to get more info.
I also get a bunch of machine check exceptions reported when I boot that don't appear on 4.9. Does anyone else see this?
Mar 11 19:55:51 funkei kernel: smpboot: CPU0: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (family: 0x6, model: 0x9e, stepping: 0x9)
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 6: ee2000000040110a
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: TSC 0 ADDR fef1ffc0 MISC 788000c086
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1489254948 SOCKET 0 APIC 0 microcode 48
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 7: ee2000000040110a
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: TSC 0 ADDR fef200c0 MISC 388000c086
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1489254948 SOCKET 0 APIC 0 microcode 48
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 8: ee2000000040110a
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: TSC 0 ADDR fef1ff40 MISC 788000c086
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1489254948 SOCKET 0 APIC 0 microcode 48
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 9: ee2000000040110a
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: TSC 0 ADDR fef1cec0 MISC 4388000c086
Mar 11 19:55:51 funkei kernel: mce: [Hardware Error]: PROCESSOR 0:906e9 TIME 1489254948 SOCKET 0 APIC 0 microcode 48

I see the same issue on 4.10. Apparently a false positive and looks like there's a patch to fix that? https://patchwork.kernel.org/patch/9533327/

TheOneJester · 2017-03-22 14:53:54

Anybody had a chance to try Nvidia 378.13-4?

WinterFrostbite · 2017-03-22 15:49:55

TheOneJester wrote:

Anybody had a chance to try Nvidia 378.13-4?

I have tested this driver and confirm that the onboard 1050 still fails to run using Bumblebee / Optirun.

smb1234 · 2017-03-22 21:22:13

pl wrote:

Anyone want to help me investigate the suspend issues that have appeared after 4.10? And maybe at least confirm they are seeing the machine check exceptions after poweron/resume.

I have been experiencing the same suspend / lock issues ever since I upgraded to 4.10, on a 4K XPS 15 9560. I believe these issues are independent of the bbswitch problem, which has completely disappeared since I started compiling my own kernels with the relevant ACPI_REV_OVERRIDE_POSSIBLE flag set to true.

The nvidia locks mostly happened when booting X (startx), while the new locks are happening just after the machine wakes from suspend.

hedgepigdaniel · 2017-03-22 21:49:52

I have not experienced a hard lock on suspend at all so far. I have uninstalled the nvidia drivers - just running an iGPU setup, but with bbswitch installed and bumblebeed enabled. Running 4.10.2 with the nvme patches and the ACPI_REV_OVERRIDE_POSSIBLE flag. I don't suspend that much, but I've done it alot more than 3 times.

Only potentially related problem is sometimes after boot the screen is on but black. I can fix this by suspending and resuming, and which point I can see the contents of the screen.

pl · 2017-03-24 07:58:57

hedgepigdaniel wrote:

I've been playing around with various power saving tweaks

Thanks for the info, some impressive numbers! I've not checked watts but with GPU off and basic powertop auto tweaks (excluding gpu and harddisk write delays) I get around an hour per 10 percent of battery when idle (9-10 hours in total).

tuxcanfly wrote:

I see the same issue on 4.10. Apparently a false positive and looks like there's a patch to fix that? https://patchwork.kernel.org/patch/9533327/

Alright, cheers, good to know its nothing to worry about. Suspected as much...

smb1234 wrote:

I have been experiencing the same suspend / lock issues ever since I upgraded to 4.10, on a 4K XPS 15 9560. I believe these issues are independent of the bbswitch problem, which has completely disappeared since I started compiling my own kernels with the relevant ACPI_REV_OVERRIDE_POSSIBLE flag set to true.
The nvidia locks mostly happened when booting X (startx), while the new locks are happening just after the machine wakes from suspend.

Thanks a lot for confirming this. They might still be semi-related, as manually turning on the GPU before suspend seems to reduce the number of lockups significantly. Probably just a side effect that affects some other system power state that causes it. I have not seen a single X start crash or optirun/manual gpu power state change crash either. Just the hardlocks when waking up from suspend.

hedgepigdaniel wrote:

I have not experienced a hard lock on suspend at all so far. I have uninstalled the nvidia drivers - just running an iGPU setup, but with bbswitch installed and bumblebeed enabled. Running 4.10.2 with the nvme patches and the ACPI_REV_OVERRIDE_POSSIBLE flag. I don't suspend that much, but I've done it alot more than 3 times.

I could try removing the nvidia drivers alltogether to see if it makes a difference and maybe work through some of your other power related tweaks if they affect this. Let us know if you get it to lock though

tuxcanfly · 2017-03-24 09:17:46

Ah how I miss linux-nvme 4.9. Worked perfectly with my XPS 9360.

Upgrading messed up my silent boot and worse, screwed suspend/resume which was working flawlessly.

smb1234 · 2017-03-25 10:40:51

pl wrote:

Thanks a lot for confirming this. They might still be semi-related, as manually turning on the GPU before suspend seems to reduce the number of lockups significantly. Probably just a side effect that affects some other system power state that causes it. I have not seen a single X start crash or optirun/manual gpu power state change crash either. Just the hardlocks when waking up from suspend.

My current configuration which seems to be stable as per today (no lockups when resuming):
- custom-compiled Linux 4.9 with ACPI_REV_OVERRIDE_POSSIBLE
- tlp
- bbswitch
- bumblebee (does not work, nvidia driver can't initialize the card, but does no harm either)

If anybody reading this has an idea how to fix 4.10, let me know, I'll be happy to assist with debugging.

gc · 2017-03-25 12:56:14

UPDATE: it doesn't work also with acpi_rev_override=5 pcie_port_pm=off acpi_backlight=vendor acpi_osi=Linux acpi_osi=! "acpi_osi=Windows 2009"
hello,

I am still not able to use NVIDIA, I installed nvidia 378.13-4 :

# optirun glxspheres64
[ 1909.780643] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA GPU at PCI:1:0:0. Please

[ 1909.780700] [ERROR]Aborting because fallback start is disabled.
# lsmod | grep nvid
nvidia 12197888 0
# grep ^Driver /etc/bumblebee/bumblebee.conf
Driver=nvidia
# cat /proc/acpi/bbswitch
0000:01:00.0 ON

I found it https://gist.github.com/whizzzkid/37c0d … 02ec61c048 someone has luck on arch to switch to nvidia on this laptop?

thanks

Last edited by gc (2017-03-25 13:24:14)

argh-ch · 2017-03-25 22:07:17

Hi, so I recently got this machine, new to Linux and I'm still having troubles with this Nvidia Card.

Originally I followed the NVIDIA and Bumblebee Arch wiki documentation, but I was getting some PCI error, eventually found this thread and managed to use ABS to custom compile Linux kernel with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE and added acpi_rev_override=1 to grub default commands.

I'm now stuck downgrading my nvidia drivers which I managed to do by using the PKGBUILDS from zzzad at https://bbs.archlinux.org/viewtopic.php … 5#p1693735

but now I seem to have some conflict with nvidia-libgl, if i try and remove libglvnd or libgl pacman is very clear that I'm going to have a bad time. I'm unsure how to proceed.

$ ~/build/extra/nvidia-utils>$ ls
NVIDIA-Linux-x86-375.26.run  NVIDIA-Linux-x86_64-375.26-no-compat32.run  PKGBUILD  nvidia-libgl-375.26-2-x86_64.pkg.tar.xz  nvidia-utils-375.26-2-x86_64.pkg.tar.xz  nvidia-utils.install  opencl-nvidia-375.26-2-x86_64.pkg.tar.xz  pkg  src
$ ~/build/extra/nvidia-utils>$ sudo pacman -U nvidia-libgl-375.26-2-x86_64.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...
:: nvidia-libgl and libglvnd are in conflict (libgl). Remove libglvnd? [y/N] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: nvidia-libgl and libglvnd are in conflict
$ ~/build/extra/nvidia-utils>$ sudo pacman -U nvidia-libgl-375.26-2-x86_64.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...
:: nvidia-libgl and libglvnd are in conflict (libgl). Remove libglvnd? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: lib32-libglvnd: removing libglvnd breaks dependency 'libglvnd'
:: mesa: removing libglvnd breaks dependency 'libglvnd'
:: nvidia-utils: removing libglvnd breaks dependency 'libglvnd'
$ ~/build/extra/nvidia-utils>$ sudo pacman -R libglvnd
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: cairo: removing libglvnd breaks dependency 'libgl'
:: freeglut: removing libglvnd breaks dependency 'libgl'
:: glew1.10: removing libglvnd breaks dependency 'libgl'
:: glu: removing libglvnd breaks dependency 'libgl'
:: lib32-libglvnd: removing libglvnd breaks dependency 'libglvnd'
:: libreoffice-fresh: removing libglvnd breaks dependency 'libgl'
:: libva: removing libglvnd breaks dependency 'libgl'
:: mesa: removing libglvnd breaks dependency 'libglvnd'
:: mesa-demos: removing libglvnd breaks dependency 'libgl'
:: mpv: removing libglvnd breaks dependency 'libgl'
:: nvidia-utils: removing libglvnd breaks dependency 'libglvnd'
:: qt4: removing libglvnd breaks dependency 'libgl'
:: qt5-base: removing libglvnd breaks dependency 'libgl'
:: sdl2: removing libglvnd breaks dependency 'libgl'
:: webkitgtk: removing libglvnd breaks dependency 'libgl'
:: webkitgtk2: removing libglvnd breaks dependency 'libgl'
:: xorg-server: removing libglvnd breaks dependency 'libgl'

Arch Linux

#51 2017-03-03 15:46:40

Re: Dell XPS 15 9560 (Early 2017)

#52 2017-03-04 20:06:09

Re: Dell XPS 15 9560 (Early 2017)

#53 2017-03-05 10:59:45

Re: Dell XPS 15 9560 (Early 2017)

#54 2017-03-05 14:07:22

Re: Dell XPS 15 9560 (Early 2017)

#55 2017-03-05 18:57:10

Re: Dell XPS 15 9560 (Early 2017)

#56 2017-03-06 08:52:04

Re: Dell XPS 15 9560 (Early 2017)

#57 2017-03-06 19:13:56

Re: Dell XPS 15 9560 (Early 2017)

#58 2017-03-12 13:36:25

Re: Dell XPS 15 9560 (Early 2017)

#59 2017-03-12 23:00:41

Re: Dell XPS 15 9560 (Early 2017)

#60 2017-03-13 10:08:50

Re: Dell XPS 15 9560 (Early 2017)

#61 2017-03-13 11:46:31

Re: Dell XPS 15 9560 (Early 2017)

#62 2017-03-15 13:29:22

Re: Dell XPS 15 9560 (Early 2017)

#63 2017-03-15 14:12:02

Re: Dell XPS 15 9560 (Early 2017)

#64 2017-03-20 08:24:20

Re: Dell XPS 15 9560 (Early 2017)

#65 2017-03-20 08:57:02

Re: Dell XPS 15 9560 (Early 2017)

#66 2017-03-20 10:12:31

Re: Dell XPS 15 9560 (Early 2017)

#67 2017-03-22 14:53:54

Re: Dell XPS 15 9560 (Early 2017)

#68 2017-03-22 15:49:55

Re: Dell XPS 15 9560 (Early 2017)

#69 2017-03-22 21:22:13

Re: Dell XPS 15 9560 (Early 2017)

#70 2017-03-22 21:49:52

Re: Dell XPS 15 9560 (Early 2017)

#71 2017-03-24 07:58:57

Re: Dell XPS 15 9560 (Early 2017)

#72 2017-03-24 09:17:46

Re: Dell XPS 15 9560 (Early 2017)

#73 2017-03-25 10:40:51

Re: Dell XPS 15 9560 (Early 2017)

#74 2017-03-25 12:56:14

Re: Dell XPS 15 9560 (Early 2017)

#75 2017-03-25 22:07:17

Re: Dell XPS 15 9560 (Early 2017)

Board footer