Dell XPS 15 9560 (Early 2017)

pl · 2017-02-12 15:45:08

I won't be updating this post anymore since hedgepigdaniel was kind enough to set up a wiki page. Thanks!

hedgepigdaniel wrote:

I made a wiki page for the 9560 (I figured there was enough stuff that is distinct from all the other XPS 15s)
https://wiki.archlinux.org/index.php/Dell_XPS_15_9560
Hopefully if we keep it up to date things will be a bit easier to follow for new users

Superseding info for most sections below: See comment #20 for link (https://bugzilla.kernel.org/show_bug.cgi?id=156341#c32) to kernel bug listing with solutions for GPU/ACPI lockup issues. A patch was originally proposed and rejected, and while it works, it's easier to manually set boot option acpi_rev_override

However, for either of these to work, you need to be running a kernel with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE enabled. The default Arch kernel config does not have this enabled, so you need to compile it yourself. Using ABS to get the default linux package, enabling CONFIG_ACPI_REV_OVERRIDE_POSSIBLE in the config and compiling it is enough. I've personally only tried the original patch and am currently running with that, but the more direct acpi_rev_override boot option has been reported by others to work.

This solves the lockup issues and since you don't have to set the acpi_osi boot parameters with this, touchpad also works. For now, I'd recommend this solution instead of using the acpi_osi=! acpi_osi="Windows 2009" boot parameters mentioned in every other section of this post.

Hey! Since there is no thread about this model yet, I figured I'd write down what I've encountered so far and share the work with others setting one up.

I have the default top-end model with 7700HQ, 16GB RAM, 512GB SSD, nVidia 1050, 4K screen.

Prerequisites

Change from RAID to ACHI in BIOS (if you want to be able to still boot into Windows after this, you apparently need to install Samsung ACHI drivers first) and disable Secure Boot.
If you want to do a clean install like I did, the BIOS has a Secure Erase tool, but that also only works in RAID mode. Using ACHI it fails with no info.

System boot shows

[ 0.000038] ACPI: Core revision 20160930
[ 0.034391] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20160930/dswload-210)
[ 0.034400] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160930/psobject-227)
[ 0.034445] ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp11) while loading table (20160930/tbxfload-228)
[ 0.037277] ACPI Error: 1 table load failures, 10 successful (20160930/tbxfload-246)

but boots.

Wireless

Despite reading a lot of discussion beforehand about problems with the Killer card, I've not faced issues with it. Works out of the box with just the bare ip / iw / wpa_supplicant set installed. Have not experienced drops in connection and it seems to connect without delay after booting. No indications of corrupted packets or anything, but no extensive load or speed testing has been done.

Worth noting that during boot there is a warning about the card:

[ 3.535218] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
[ 3.535255] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
[ 3.535475] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
[ 3.535491] ath10k_pci 0000:02:00.0: could not fetch firmware file 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
[ 3.536863] ath10k_pci 0000:02:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
[ 3.536879] ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0
[ 3.538325] ath10k_pci 0000:02:00.0: firmware ver WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5

Keyboard

While a bit mushy coming from a ThinkPad, the keyboard itself seems to work without issue. Binding the XF86 media keys (XF86MonBrightnessUp, XF86AudioMute, etc) to desired functions is enough.

Sadly touchpad sync issues with boot parameters acpi_osi=! acpi_osi="Windows 2009" described below also cause keyboard to tilt for the duration of the resync, resulting in missing or repeated characters. This is not as bad as it sounds since the resync seems to be almost exclusively triggered when using the touchpad. Palm checks might thus cause the biggest problems.

Backlight

Brightness keys directly control keyboard backlight in hardware, but monitor brightness needs to be taken care of. light-git was tested and works without major issues. Setting minimum raw level to 1 instead of 0 prevents the screen from going black on the lowest brightness setting.

Audio

Works without config, just unmute.

Touchscreen

Works out of the box. I had it disabled in BIOS but turned it on just to try. Even multi-touch gestures in Chromium seem to work right away. Might leave it on now with the touchpad issues to have a backup

Graphics

This is where the bigger issues currently lie.

Running X without any configuration (I've blacklisted nouveau just in case) defaults to using the Intel card and modesetting, which is a fine baseline. However, turning off the nVidia GPU with acpi_call or bbswitch is where issues start. Trying to start X or suspending with the GPU off will hardlock the system. Trying to turn on the GPU before suspending might hardlock the system.

Running a Bumblebee setup works with the same caveats as long as you are starting X with the nVidia GPU on. Any time optirun is used, the system might hardlock. bbswitch will also automatically try to turn the GPU on for suspend which means it can work, but sometimes results in a hardlock.

Essentially, anything that probes the GPU when it's off, be it a turn-on request itself, might hardlock the system.

Following some discussions on the Bumblebee bug tracker, it seems you can work around this by lying to the BIOS that you are an older version of Windows. It will apparently disable some newer PCIe access methods that result in the loop.

However, while working with a combination of acpi_osi=! acpi_osi="Windows 2009" for the XPS, in this case it also breaks the touchpad and affects the keyboard. Additionally mce hardware errors pop up.

GPU seems to turn off with bbswitch and a few hours of battery added, but even with the boot flags dmesg reads

[ 5575.482112] bbswitch: disabling discrete graphics
[ 5575.482116] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)

Current options (please contribute if you have ideas):

Don't tweak boot parameters and
1. Run using just Intel and leave the nVidia GPU on. Hurts battery and no access to discrete graphics.
2. Install plain nvidia as described on Optimus wiki page. Use at least "xrandr --dpi 96" in xinit, or using xorg device config, to make dpi-based font size more than 4x4 pixels... Again, hurts battery for basic use but gives access to discrete graphics if that is desired.

Add acpi_osi=! acpi_osi="Windows 2009" to boot parameters and
1. Run just Intel, disabling nvidia. Simple and good battery life but touchpad/keyboard issues.
2. Basic bumblebee setup. Only thing that seems to cause issues is suspending while optirun is running, but it only breaks the active program. Good battery, can use nVidia GPU when needed, but touchpad/keyboard issues.

Third option is the check the top of this post and patch the kernel, or hope the patch is included in 4.10 and wait for it

UPDATE: When this was written, nvidia was at version 375. The 378 drivers that were released on the 14th of February however are unable to initialize the nvidia GPU. 378 also exhibits issues on Windows with this card. You need to revert to 375 to get the nvidia card to work at all if you need it. You can download the nvidia and nvidia-utils packages through ABS, change the version back to 375.26 in the PKGBUILD and then use the resulting custom-built nvidia-dkms package if you have already updated the kernel.

Suspend

These are issues that have been hard to pinpoint for sure. I've done around 100 suspends and 50 hardlocks trying to narrow things down. At least default boot parameters and GPU off seems to always result in a hard lock. Any suspending with default boot parameters seems flaky.

Sometimes any suspend using the default parameters might reboot on resume, showing the Dell splash screen. If this happens once, it will always happen no matter the GPU state or boot parameters used. It seems hard-booting by holding down the power button for 4 seconds while running is what gets you out of whatever state the computer is in.

Using boot parameters acpi_osi=! acpi_osi="Windows 2009" suspend seems to work reliably.

Touchpad

Touchpad init reports failing during boot but it works with default boot parameters.

Using acpi_osi=! acpi_osi="Windows 2009" to help with GPU/suspend issues the touchpad starts exhibiting a lot of pauses and cuts and dmesg is filled with sync lost messages.

[ 557.351639] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 557.883707] psmouse serio1: resync failed, issuing reconnect request
[ 558.770427] psmouse serio1: synaptics: queried max coordinates: x [..5664], y [..4646]
[ 558.804356] psmouse serio1: synaptics: queried min coordinates: x [1278..], y [1206..]
[ 574.231331] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 574.232435] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 574.233615] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 574.243609] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
[ 574.244605] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
[ 574.244609] psmouse serio1: issuing reconnect request
[ 575.134447] psmouse serio1: synaptics: queried max coordinates: x [..5664], y [..4646]
[ 575.164288] psmouse serio1: synaptics: queried min coordinates: x [1278..], y [1206..]
[ 576.952284] psmouse serio1: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 577.483698] psmouse serio1: resync failed, issuing reconnect request
[ 578.353805] psmouse serio1: synaptics: queried max coordinates: x [..5664], y [..4646]

This seems to not happen nearly as much when the system is under load. Turning off the discrete GPU with bbswitch makes the cursor jump around a lot, and turning it back on makes it smoother again. Turing off the GPU with acpi_call's turn_off_gpu script makes it permanently jumpy.

Using boot parameter psmouse.resetafter=0 made the touchpad recover faster initially, but after half a minute of use it was left in an endless "lost sync at byte 1" loop without recovering anymore.

Dock

Ordered a TB16 dock along with this. I am able to run the built in screen along with both a 4K monitor and a 3K monitor in both VT and in X. After disabling Thunderbolt authorization in BIOS (don't know how new plugged-in devices should be authorized under Linux) the USB ports also work. Hotplugging seems to work without issues, suspending does not cause issues with the thunderbolt port, etc. So it seems this is finally a working 3x4K solution on Linux that I've been trying to get for years!

After 6 successful dock/undocks the system hardlocked when connecting the thunderbolt cable. No problems again since. Maybe related to further PCI power issues?

As a side note, the output names (DP-1-1, DP-2-1) seem to be assigned in the order the monitors are plugged in, not based on the ports used. My configuration was broken by turning off a monitor between beingn docked since the names referring to the monitors changed. Unplugging them both, redocking and plugging them in the original order fixed this.

The headphone port on the dock did not work out of the box -- alsamixer crashes when even trying to open the USB sound card it sees after docking. Have not investigated this yet.

----

I've tried a lot of stuff down to i8024.nomux but here are what I've left as boot options:

rw acpi_osi=! acpi_osi="Windows 2009" acpi_osi=Linux acpi_backlight=vendor

The last two are not required. vendor-backlight seems a bit more responsive when changing brightness but that's it.

Just a quick'n'dirty writeup, but posting it right away hoping to hear experiences and ideas, or if someone knows if I'm missing something related to the gpu, suspending and touchpad. I'll update this as more is uncovered.

Last edited by pl (2017-05-24 10:26:45)

patrickb · 2017-02-13 04:27:44

Mine arrives in a week, so I'm watching this with interest...

simo8989 · 2017-02-13 09:15:32

I have exactly your same configuration. Installed arch linux without any particular problem, as you mentioned I had just to switch to achi then the installation when straightforward. I have gnome running only in wayland and this might be a difference from you, I do not understand when you talk about the gpu remaining active, or something like that? I simply have bbswitch with a classical bumblebee setup that puts the discrete graphics off at every boot, cat /proc/acpi/bbswitch returns me off, so I guess the Nvidia card is completely disabled.
I have not tried any optirun because I do not need the discrete card under Linux and also because as far as I know the official Nvidia drivers are not yet supported under wayland.
I have tlp and thermald running, and powertop says that all the powersave options are optimal.
The temperatures are ok, but not satisfying for me, I am around 42 Celsius all the time, and under load I get 47-48. Also the fans wake up more frequently than windows, but I still get 5 hour battery life tested.
I do not use any kernel parameter, mainly because I am not so expert to understand what I will be doing with many of them and I hate when I loose the control of the situation

EDIT: hibernation works perfectly, suspend not tested.

Last edited by simo8989 (2017-02-13 09:18:05)

Ituin · 2017-02-14 05:59:46

I have a similar setup to what's been described in the original post, but also with full disk encryption. everything has so far worked great, up till the same graphics challenges described above. i've spent the last two days trying to configure my way around it with no luck.

pl · 2017-02-14 07:54:19

simo8989 wrote:

I have exactly your same configuration. Installed arch linux without any particular problem, as you mentioned I had just to switch to achi then the installation when straightforward. I have gnome running only in wayland and this might be a difference from you, I do not understand when you talk about the gpu remaining active, or something like that? I simply have bbswitch with a classical bumblebee setup that puts the discrete graphics off at every boot, cat /proc/acpi/bbswitch returns me off, so I guess the Nvidia card is completely disabled.
I have not tried any optirun because I do not need the discrete card under Linux and also because as far as I know the official Nvidia drivers are not yet supported under wayland.
I have tlp and thermald running, and powertop says that all the powersave options are optimal.
The temperatures are ok, but not satisfying for me, I am around 42 Celsius all the time, and under load I get 47-48. Also the fans wake up more frequently than windows, but I still get 5 hour battery life tested.
I do not use any kernel parameter, mainly because I am not so expert to understand what I will be doing with many of them and I hate when I loose the control of the situation
EDIT: hibernation works perfectly, suspend not tested.

From what I've read Wayland is not affected by the same issue that causes X startup to hang when discrete graphics is off.

Could you do a test of repeating

sudo tee /proc/acpi/bbswitch <<<ON
sudo tee /proc/acpi/bbswitch <<<OFF

twenty times or something to turn the GPU on and off simulating optirun/suspend cycles and see if it hangs the system?

patrickb · 2017-02-14 20:52:43

@ituin For what it's worth, rather than using LUKS for full disk encryption (which I presume to be what you meant), you are better off just setting the disk password in the BIOS. As I understand, an SSD encrypts it's contents on write. If you set the disk passphrase in the bios, you are just passwording the encryption key. Thus an encrypted disk with no encryption overhead (which I understand to be in the order of 50% for NVMe type storage). The only caveat is that some BIOS' only support and 8 character password. I haven't checked the Dell BIOS (I will when it arrives), but my ASUS allows a much longer password which means I would not be able to read the disk in a machine who's BIOS had the eight character limit in some kind of disaster scenario.

simo8989 · 2017-02-15 10:02:03

pl wrote:

simo8989 wrote:
I have exactly your same configuration. Installed arch linux without any particular problem, as you mentioned I had just to switch to achi then the installation when straightforward. I have gnome running only in wayland and this might be a difference from you, I do not understand when you talk about the gpu remaining active, or something like that? I simply have bbswitch with a classical bumblebee setup that puts the discrete graphics off at every boot, cat /proc/acpi/bbswitch returns me off, so I guess the Nvidia card is completely disabled.
I have not tried any optirun because I do not need the discrete card under Linux and also because as far as I know the official Nvidia drivers are not yet supported under wayland.
I have tlp and thermald running, and powertop says that all the powersave options are optimal.
The temperatures are ok, but not satisfying for me, I am around 42 Celsius all the time, and under load I get 47-48. Also the fans wake up more frequently than windows, but I still get 5 hour battery life tested.
I do not use any kernel parameter, mainly because I am not so expert to understand what I will be doing with many of them and I hate when I loose the control of the situation
EDIT: hibernation works perfectly, suspend not tested.
From what I've read Wayland is not affected by the same issue that causes X startup to hang when discrete graphics is off.
Could you do a test of repeating
sudo tee /proc/acpi/bbswitch <<<ON
sudo tee /proc/acpi/bbswitch <<<OFF
twenty times or something to turn the GPU on and off simulating optirun/suspend cycles and see if it hangs the system?

I will try this evening when I get home, but as far as I know I expect problems from this operation because I am using the official Nvidia drivers that are not yet supported under wayland. I installed them in order to have my system ready when wayland will support them.

pl · 2017-02-15 14:50:05

simo8989 wrote:

I will try this evening when I get home, but as far as I know I expect problems from this operation because I am using the official Nvidia drivers that are not yet supported under wayland. I installed them in order to have my system ready when wayland will support them.

Cheers! The problem is the same regardless of what drivers -- if any -- are installed. You don't need to actually use the device for drawing to trigger it. It's enough to try to turn it on. Interested to hear your results!

simo8989 · 2017-02-15 23:43:46

pl wrote:

simo8989 wrote:
I will try this evening when I get home, but as far as I know I expect problems from this operation because I am using the official Nvidia drivers that are not yet supported under wayland. I installed them in order to have my system ready when wayland will support them.
Cheers! The problem is the same regardless of what drivers -- if any -- are installed. You don't need to actually use the device for drawing to trigger it. It's enough to try to turn it on. Interested to hear your results!

Tried both tee /proc/acpi/bbswitch >> ON and optirun, in either case the OS freeze as soon as I press enter on the command line.
And worst I discovered that even if I have bumblebee active and running sometimes after reboot or simple poweron the discrete GPU is on by default... cat /proc/acpi/bbswitch returns me ON, and is not possible to put it off through the tee command.
This seems to happen randomly after starting the laptop.

czikus · 2017-02-16 07:30:35

@pl I read your comment about the interaction between the keyboard and the touchpad. I've been struggling with keyboard repeating keys for a long time now, and was wondering if you could elaborate on the potential connection? The problem existed on Precision 5510 and now on XPS 9560. Basically, I often get keys repeating like thisssssssss until another key is pressed. What kind of keyboard problems did you notice? What made it better/worse?

DaNiMoTh · 2017-02-16 14:11:48

Hello! XPS 9560 FHD, i7-7700HQ owner here.

By default, I don't have any hardlock, and suspend/hibernate just run fine. However, I have problems with bumblebee/NVIDIA setup. Mainly, the problem is the following:

[ 8595.552519] bbswitch: Unloaded. Discrete card 0000:01:00.0 is on
[ 8602.536332] bbswitch: version 0.8
[ 8602.536342] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
[ 8602.536355] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP
[ 8602.536373] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[ 8602.536558] bbswitch: detected an Optimus _DSM function
[ 8602.819258] pci 0000:01:00.0: enabling device (0000 -> 0003)
[ 8602.819269] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
[ 8620.795798] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
[ 8620.795864] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:1c8d)
               NVRM: installed in this system is not supported by the 375.26
               NVRM: NVIDIA Linux driver release.  Please see 'Appendix
               NVRM: A - Supported NVIDIA GPU Products' in this release's
               NVRM: README, available on the Linux driver download page
               NVRM: at www.nvidia.com.
[ 8620.796068] nvidia: probe of 0000:01:00.0 failed with error -1
[ 8620.796135] nvidia-nvlink: Nvlink Core is being initialized, major device number 241
[ 8620.796172] NVRM: The NVIDIA probe routine failed for 1 device(s).
[ 8620.796173] NVRM: None of the NVIDIA graphics adapters were initialized!
[ 8620.796176] nvidia-nvlink: Unregistered the Nvlink Core, major device number 241

The NVIDIA driver does not recognize the card. I've read that it is due to some incompatibilities with the PCI-e power management from kernel 4.8 onwards, but as I can see from the log the card is "enabled" before the module loading.
This is my special udev rule for enabling the PM on the PCIe:

# cat /etc/udev/rules.d/pci_pm.rules 
ACTION=="add", SUBSYSTEM=="pci", ATTR{idVendor}=="10de", ATTR{idProduct}=="1c8d", GOTO="power_pci_rules_end"
ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"

LABEL="power_pci_rules_end"

Any idea? I don't want to mess with boot parameters, the keyboard is more important than the GPU

pl · 2017-02-16 15:14:58

simo8989 wrote:

Tried both tee /proc/acpi/bbswitch >> ON and optirun, in either case the OS freeze as soon as I press enter on the command line.
And worst I discovered that even if I have bumblebee active and running sometimes after reboot or simple poweron the discrete GPU is on by default... cat /proc/acpi/bbswitch returns me ON, and is not possible to put it off through the tee command.
This seems to happen randomly after starting the laptop.

Alright, this seems consistent with the problems listed then. If you want to try, using the boot parameters fixes all of these issues if you can live with the touchpad and slight keyboard issues... Still hoping for a better solution or at least knowing what the right direction would be to push for a fix. Linux kernel PCIe power management so that no workarounds would need to be used?

czikus wrote:

@pl I read your comment about the interaction between the keyboard and the touchpad. I've been struggling with keyboard repeating keys for a long time now, and was wondering if you could elaborate on the potential connection? The problem existed on Precision 5510 and now on XPS 9560. Basically, I often get keys repeating like thisssssssss until another key is pressed. What kind of keyboard problems did you notice? What made it better/worse?

The issue is similar as to what you described. The keyboard problems only happen when the touchpad loses sync. The touchpad also gets much worse when the GPU is turned off, thus compounding the keyboard problems. If you want to try it yourself, boot with the parameters mentioned in my original post, open up dmesg -w, keep doing circles on the touchpad and pressing keyboard keys at the same time. When you see resync messages, the keys will also get stuck. Turning on the GPU will make the mouse move much smoother (like it's poll rate would quadruple), but does not mitigate the sync issues. After some boots the touchpad might be almost fine for 5 minutes, after some not at all -- I do not know what the real factor is. I noticed the touchpad working just fine the whole time while running mprime originally, so I thought it might have to do with some over-aggressive sleep states, but could not repeat it later, so it was probably a coincidence and is connected to something else.

DaNiMoTh wrote:

Any idea? I don't want to mess with boot parameters, the keyboard is more important than the GPU

My log the last time I enabled discrete graphics reads like this, it seem so vary a lot:

[34306.539871] bbswitch: enabling discrete graphics
[34306.835265] nvidia-nvlink: Nvlink Core is being initialized, major device number 241
[34306.835280] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 375.26 Thu Dec 8 18:36:43 PST 2016
[34306.835281] (using threaded interrupts)
[34306.852943] vgaarb: this pci device is not a vga device
[34306.855773] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34306.855823] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34306.855851] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34306.855876] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34306.855901] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34306.855939] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34306.855965] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34306.930616] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34307.400503] vgaarb: this pci device is not a vga device
[34307.448931] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 375.26 Thu Dec 8 18:04:14 PST 2016
[34310.672425] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34310.679393] nvidia-modeset: Unloading
[34310.694102] nvidia-nvlink: Unregistered the Nvlink Core, major device number 241
[34310.720254] bbswitch: disabling discrete graphics
[34310.720273] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160831/nsarguments-95)
[34310.737319] pci 0000:01:00.0: Refused to change power state, currently in D0

I do seem to have the same driver version but my best guess is that something in your config prevents the KMS version from being used. Sorry, can't give you a better guess...

Also, worth mentioning that I've not really had work-disturbing keyboard issues for now. The touchpad does not seem to be that easy to touch with your palms and I've only seen the keyboard act up for sure when that is happening. I admit I kind of dread my kill-window shortcut getting stuck for a moment and closing all active windows on the active desktop though.

Last edited by pl (2017-02-16 15:17:56)

DaNiMoTh · 2017-02-16 17:03:28

pl wrote:

My log the last time I enabled discrete graphics reads like this, it seem so vary a lot:

Do you have auto power management on PCIe ?

pl · 2017-02-17 07:35:28

DaNiMoTh wrote:

pl wrote:
My log the last time I enabled discrete graphics reads like this, it seem so vary a lot:
Do you have auto power management on PCIe ?

I have not changed the defaults, whatever they might be in this case. Care to enlighten me on something that might be useful or want me to check something?

Last edited by pl (2017-02-17 07:37:35)

DaNiMoTh · 2017-02-17 07:40:39

pl wrote:

I have not changed the defaults, whatever they might be in this case. Care to enlighten me or want me to check something?

If you have not changed the default, then it might be on (the naming is a bit strange: when the power management is on, it means it's disabled...). To check, the command is the following:

# 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.

patrickb · 2017-02-19 01:02:05

With a clean arch installation, I get an almost instant hard lock if I try to do anything with bbswitch; however, adding the below to my kernel params appears to have resulted in a stable system (i.e. I can ON, OFF, ON, OFF with no sign of lockups):

acpi_osi="!Windows 2015"

I now have the X server won't start issue that DaNiMoTh detailed above. I can't confirm whether my acpi_osi setting has caused this though as without it, I get pretty much instant lockup when starting bumblebee.

patrickb · 2017-02-19 01:09:11

I take that back. Sort of.

Without the acpi_osi option="!Windows 2015" option, AND without the bbswitch module loaded, then bumblebee will run, but still fails to start the X server. Loading bbswitch seems to default to "ON", makes no difference to bumblebee not being able to start X, but results in a kernel hard-lock within a few seconds.

randm · 2017-02-20 09:03:42

For those of you having trouble getting Xorg to run due to a "RmInitAdapter failed!" error with this Laptop, check out this thread: https://bbs.archlinux.org/viewtopic.php?id=223209
In short, you need to install the `nvidia` driver version 375.26-6 for now, not the most recent 378.13-1.

aAlpine · 2017-02-21 05:36:15

I've also just received my XPS (specs matching pl's). I seem to have made some progess on the graphics end. With no kernel params, and a pretty standard setup I
- Installed packages: bumblebee mesa xf86-video-intel nvidia, added myself to bumblebee group, enabled bumblebee systemd service (all as per wiki)
- Installed bbswitch
- Updated /etc/bumblebee/bumblebee.conf so that for [driver-nvidia] PMMethod=none (without this, I get a lockup at boot)
- Blacklisted nvidia module

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

At an idle state w/ 10% screen brigness (set precisely with xbacklight), powertop reports
- w/ GPU off: discharge rate of about 12 W
- w/ GPU on: discharge rate of about 20 W

I was also able to enter and recover from a systemd suspend with the GPU off successfully (at least once).

This was with nvidia drivers 378.13-1 and the latest kernel 4.9.9-1

optirun glxgears fails w/ GPU on, error message says "Cannot access secondary GPU - error: [XORG] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA GPU at PCI:1:0:0"

So at the very least, it looks like if we script something up to run at the end of boot time, we'll be able to get the power savings.

patrickb · 2017-02-21 05:43:23

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!

https://bugzilla.kernel.org/show_bug.cgi?id=156341#c32

psino · 2017-02-21 16:13:34

With just the Intel GPU active (no nvidia module installed and noveau blacklisted), I'm seeing a higher base discharge rate from the battery that I would have expected, as reported by powertop:

The battery reports a discharge rate of 15.6 W
The estimated remaining time is 4 hours, 29 minutes

Summary: 1448.6 wakeups/second,  5.1 GPU ops/seconds, 0.0 VFS ops/sec and 11.3% CPU use

Power est.              Usage       Events/s    Category       Description
  9.15 W    100.0%                      Device         USB device: usb-device-0cf3-e300
  6.21 W      4.0 pkts/s                Device         nic:tun0
  139 mW      0.0 pkts/s                Device         nic:virbr0
...

From lsusb it seems this is the bluetooth + network card?

Bus 001 Device 002: ID 0cf3:e300 Atheros Communications, Inc.

Are others seeing the same power usage here and can something be done with it? If I'm reading powertop correctly, almost all power usage seem to be from this network card?

simo8989 · 2017-02-21 23:41:02

patrickb wrote:

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!
https://bugzilla.kernel.org/show_bug.cgi?id=156341#c32

Have you guys realized that exactly the same thing happens on Windows 10 with the latest Nvidia drivers 378 ? Basically on windows the system is not anymore able to recognize the discrete graphics card, control panel says that there is a problem with the device, and it seems that actually the Nvidia card is on all the time, infact the fans spin constantly and the battery drains fast.
Even on Windows I solved by downgrading the drivers to the previous version.
If its the case, this issue seems not at all kernel related or in any way linux related, but rather Nvidia related.

Last edited by simo8989 (2017-02-21 23:42:23)

whizzzkid · 2017-02-22 03:10:08

Here you go, this should help you get all your nvidia drivers working: https://gist.github.com/whizzzkid/37c0d … 02ec61c048

The problem is nvidia-drm, you need to blacklist that to get everything loaded nicely.

I now need to sort the touchpad issue. this is annoying!

patrickb · 2017-02-22 03:11:20

That's interesting. I really only booted windows once, and hadn't tried updating the windows drivers. In summary though there are two complete separate issues at play here (1) is the lockups; (2) is the current nvidia driver failing to load/initialise the card. The first is a kernel patch as mentioned above, the second is solved by a downgrade of the nvidia drivers but is otherwise at their whim to solve (or not). But if the problem is indeed present in windows as well as Linux then I'd hope it ends up getting fixed el pronto!

patrickb · 2017-02-22 03:22:59

whizzzkid wrote:

The problem is nvidia-drm, you need to blacklist that to get everything loaded nicely.

I see you are using Ubuntu in your gist? What version of the nvidia driver is currently bundled?

whizzzkid wrote:

I now need to sort the touchpad issue. this is annoying!

Your touchpad doesn't work because of this:

acpi_osi=! acpi_osi="Windows 2009"

Unfortunately, if you remove that, then you'll have the kernel hard-lock issue instead (if you try to turn off the discrete GPU with bbswitch). The answer to that appears to be a kernel patch: https://bugzilla.kernel.org/show_bug.cgi?id=156341

Arch Linux

#1 2017-02-12 15:45:08