Dell XPS 13 9350 Late 2015

gedh · 2017-01-07 16:07:26

kgizdov wrote:

@OdinEidolon, I added a small TPM section to the Wiki.
To All: I just had a quick look at the Wiki and there seems to be some wrong/patially incorrect info there. I would like to have a discussion about what I saw and maybe even other people go have a look for other stuff, before I go off on my own correcting things.

Thanks for adding that to the wiki. Btw. this kind of discussion should ideally happen on the "Discussion" page on the ArchWiki

kgizdov wrote:

To give an example, the first two subsections in the section about BIOS are giving false explanations to common problems not specific to XPS issues. USBs are not shown as boot devices not because of SecureBoot or Legacy Option ROMs, but because the user is trying to boot an MBR-only boot device into GPT/UEFI mode, which is obviously wrong. Switching Legacy Option ROMs to ON and booting your MBR stick risks installing Arch in legacy BIOS mode. I don't think that's what people want. If your Arch ISO image is correctly configured, you can boot in UEFI-only mode no problem. Moreover, you can self-sign the boot image and update the PKI records to even boot with SecureBoot enabled. I agree at least we should have the SecureBoot-off point for convenience as no one really wants to self-sign their linux and then update PKI records manually on every update. However, this is not XPS BIOS issue, this is not even general BIOS issue, this is user error/misconfig. This probably only belongs to general UEFI under Linux discussions, not on our XPS Wiki page.

Your critique seems reasonable. I just removed the according section and referenced the "Secure Boot" ArchWiki article.

kgizdov wrote:

The point about efivars not being recognised - brought upon by exactly what I just explained. If you boot in legacy mode, your efivars will not be recognised. The Wiki is instructing people to do wrong (possibly dangerous) things. There is another case where this might happen as well - using GRUB. Don't use GRUB as your boot loader. It's really really really really really really really bad and only recently even got the memo about EFI. (repeating the 'really' bit is a jab at GRUB devs struggling with for-loops). Use Systemd Boot or if you really must rEFInd. On the Wiki about systemd-boot you can see the second bit is exactly about this problem and how to correct it.

I deleted the according entry and linked to the UEFI subsection about efivars.

kgizdov wrote:

The Thunderbolt and specifically External Display subsection. Firstly, why is External Display listed up among the other built-in devices on the XPS? That's where we list devices that are part of the laptop, which might require special kernel modules for operation or currently not supported. Is anyone's USB-C or Thunderbolt port not working? Does it require a module? I don't think so. And even if it was - the port is not an external display. On top of that, most external display issues are actually Dell-docks-suck issues. The laptop itself has a great USB-C/Thunderbolt port. I myself use it on a daily basis and the kernel works with it out of the box. I use the Cable Matters multi-adaptor and I am yet to find a device I cannot connect to. Moreover, my USB-C to DisplayPort cable from Plugable allows me to connect my monitor and even use its built-in USB dock. I have been interested in these discussions here on the forum and a lot of people use external displays on a daily basis, some of my colleagues do to. I think this should be completely rewritten.

You are not alone. It is kind of odd to list this entry there.

kgizdov wrote:

Can someone with more experience look at the Audio section as well? As far as I remember, I only had to disable power saving in TLP for my audio and the problem is gone. I haven't edited any PulseAudio files. And I definitely haven't disabled my internal mic at all.

The paragraph is actually useful, or at least is was to me, since I experienced this weird behaviour. The power saving option enabled by TLP is unrelated to this section.

OdinEidolon · 2017-01-07 16:12:55

kgizdov wrote:

@OdinEidolon, I added a small TPM section to the Wiki.
To All: I just had a quick look at the Wiki and there seems to be some wrong/patially incorrect info there. I would like to have a discussion about what I saw and maybe even other people go have a look for other stuff, before I go off on my own correcting things.
To give an example, the first two subsections in the section about BIOS are giving false explanations to common problems not specific to XPS issues. USBs are not shown as boot devices not because of SecureBoot or Legacy Option ROMs, but because the user is trying to boot an MBR-only boot device into GPT/UEFI mode, which is obviously wrong. Switching Legacy Option ROMs to ON and booting your MBR stick risks installing Arch in legacy BIOS mode. I don't think that's what people want. If your Arch ISO image is correctly configured, you can boot in UEFI-only mode no problem. Moreover, you can self-sign the boot image and update the PKI records to even boot with SecureBoot enabled. I agree at least we should have the SecureBoot-off point for convenience as no one really wants to self-sign their linux and then update PKI records manually on every update. However, this is not XPS BIOS issue, this is not even general BIOS issue, this is user error/misconfig. This probably only belongs to general UEFI under Linux discussions, not on our XPS Wiki page.
The point about efivars not being recognised - brought upon by exactly what I just explained. If you boot in legacy mode, your efivars will not be recognised. The Wiki is instructing people to do wrong (possibly dangerous) things. There is another case where this might happen as well - using GRUB. Don't use GRUB as your boot loader. It's really really really really really really really bad and only recently even got the memo about EFI. (repeating the 'really' bit is a jab at GRUB devs struggling with for-loops). Use Systemd Boot or if you really must rEFInd. On the Wiki about systemd-boot you can see the second bit is exactly about this problem and how to correct it.
The Thunderbolt and specifically External Display subsection. Firstly, why is External Display listed up among the other built-in devices on the XPS? That's where we list devices that are part of the laptop, which might require special kernel modules for operation or currently not supported. Is anyone's USB-C or Thunderbolt port not working? Does it require a module? I don't think so. And even if it was - the port is not an external display. On top of that, most external display issues are actually Dell-docks-suck issues. The laptop itself has a great USB-C/Thunderbolt port. I myself use it on a daily basis and the kernel works with it out of the box. I use the Cable Matters multi-adaptor and I am yet to find a device I cannot connect to. Moreover, my USB-C to DisplayPort cable from Plugable allows me to connect my monitor and even use its built-in USB dock. I have been interested in these discussions here on the forum and a lot of people use external displays on a daily basis, some of my colleagues do to. I think this should be completely rewritten.
Can someone with more experience look at the Audio section as well? As far as I remember, I only had to disable power saving in TLP for my audio and the problem is gone. I haven't edited any PulseAudio files. And I definitely haven't disabled my internal mic at all.
I urge people to go and have a look themselves for other things, which I may have missed.

we should definitely split the general XPS15 article specifically into an article for the XPS9550/9560. Right now it's extremely confusing for a newcomer.

kgizdov · 2017-01-07 16:32:41

@OdinEidolon, I was specifically talking about XPS13 (9350) article. I haven't looked at the XPS15 as I don't own the hardware. You would need to talk to XPS 15 owners for that.

@gedh, what about the external display paragraph? That seems bad too. Should I rewrite it?

gedh · 2017-01-07 16:40:51

kgizdov wrote:

@gedh, what about the external display paragraph? That seems bad too. Should I rewrite it?

Yes, sure go ahead! Personally I do not own an adapter and did not have the need yet to add an external screen. Therefore I have no knowledge about how good or bad the situation is. However it seems the general consensus was that with the right adapter an external screen should work.

OdinEidolon · 2017-01-07 17:41:47

kgizdov wrote:

@OdinEidolon, I was specifically talking about XPS13 (9350) article. I haven't looked at the XPS15 as I don't own the hardware. You would need to talk to XPS 15 owners for that.
@gedh, what about the external display paragraph? That seems bad too. Should I rewrite it?

Ah sorry, damn, too confused.

zhjn921224 · 2017-01-10 10:22:02

kubrick wrote:

Since the last bios upgrade, I'm having a few issues:
If I disable the SATA adapter in the BIOS, I get these errors at boot:
Dec 18 09:49:48 XPS16 kernel: ACPI Error: [\_SB_.PCI0.SAT1] Namespace lookup failure, AE_NOT_FOUND (20160831/dswload-210)
Dec 18 09:49:48 XPS16 kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160831/psobject-227)
Dec 18 09:49:48 XPS16 kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:IdeTable) while loading table (20160831/tbxfload-228)
Dec 18 09:49:48 XPS16 kernel: ACPI Error: 1 table load failures, 8 successful (20160831/tbxfload-246)
Also, when I switch to battery (with or without SATA enabled), I can't set min_perf_pct without waiting for a minute or so.
If I do
echo 12 | sudo tee /sys/devices/system/cpu/intel_pstate/min_perf_pct
and read the value immediately afterwards, it's set to 12, but one second later, it reverts to 100.
I have to use this command every time I switch to battery now:
while [ $(cat /sys/devices/system/cpu/intel_pstate/min_perf_pct) -ne "12" ]; do sudo tlp bat; sleep 3; done
and it usually loops a dozen times before succeeding.
Any suggestion?

As to the ACPI errors, I got the exact same message. Completely no idea and no noticeable issues found.

Asriel · 2017-01-13 17:28:01

Great news - latest drm-intel build (made git clone today) - works perfectly with PSR enabled.
I believe that is the patch missing for so long but now everything in place.
https://cgit.freedesktop.org/drm-intel/ … ea6cb6f3b6

Hope that it will not break again in the release of 4.10

frank604 · 2017-01-14 06:36:25

I've been running on 250hz tick rate for the past couple months. I've noticed lower temps/longer life but having a hard time narrowing down which setting. Can anyone test with this tick rate in their kernel config and let me know if this is true for you too?

OdinEidolon · 2017-01-16 08:38:16

Has anyone done any tests on how different scaling drivers and governors work on our XPS? Pstate/cpufreq ondemand/performance/schedutil?

Asriel · 2017-01-16 12:11:30

Intel P-state does not work with them - only performance and powersave. I've tried once to give up p-state and use acpi + different governers but seemed that p-state is slightly better in terms of battery life. But that was on 4.6 kernel.

OdinEidolon · 2017-01-16 12:38:25

Asriel wrote:

Intel P-state does not work with them - only performance and powersave. I've tried once to give up p-state and use acpi + different governers but seemed that p-state is slightly better in terms of battery life. But that was on 4.6 kernel.

What do you mean that it does not work? Were you referring to cpufreq instead of Pstate? Pstate powersave indeed is the default.

Last edited by OdinEidolon (2017-01-16 12:38:41)

Asriel · 2017-01-16 17:57:06

there are drivers and governers - drivers cover hardware part of cpufreq control, governers are motre about the software. P-state is something going on fully on hardware side - so with the intel p-state driver you delegate to the hardware to decide what to do with freq and voltage, the only thing you can tell to the hardware is the min-max p-states to use and the way to control. Perfomance always do freq up to the max, powersave do freq up gradually. This behavior is controlled by selecting the governor performance or powersave.

The other governors - schedutil, conservative, ondemand etc - are software based, so the p-state is computed by the kernel code and then passed to the driver. P-state driver is not controlable by software - so if you wnat to use schedutil you must give up p-state driver and use acpi driver instead. In this case kernel is controlling the cpu speed, not the cpu inside desiding what speed to run. Kernel is more intelligent than the hadware, but while computing thr p-state reaquired kernel is running the code - so waiking up the cpu. So generally running p-state gives higher frequency, but cpu is more often in power save state, running acpi you have less freq-voltage, but cpu stay awake longer. I have tried both and found out that giving up everything to the hardware is better, the only thing I did is limiting the CPU speed to 80%. The freq-voltage showing that it is more or less linear in the beginning but up to the top freqs voltage is rizing faster than frequency - looks like intel is squizing as much as possible from the chip to get higher max frequency, but those high freq state are not power efficient at all. So I try to avoid CPU to going into that "gaming" segment unless I am connected to the power socket in the wall.

OdinEidolon · 2017-01-16 19:28:40

Asriel wrote:

So I try to avoid CPU to going into that "gaming" segment unless I am connected to the power socket in the wall.

Can I ask you how you did that, please?

Stegamjay · 2017-01-16 20:11:02

Hello Guys,

I'm new in this forum. (my laptop is a DELL XPS 9350 1920x1080 8Go I7-6560U)

I've just read this news : "It's Now Possible To Disable & Strip Down Intel's ME Blob"
https://www.phoronix.com/scan.php?page= … E-Cleaning

Someone succed tu deblob the intel Management engine part of the bios on un 9350 laptop ?

Tanks

Asriel · 2017-01-16 21:13:53

OdinEidolon wrote:

Asriel wrote:
So I try to avoid CPU to going into that "gaming" segment unless I am connected to the power socket in the wall.
Can I ask you how you did that, please?

Like this :

echo 15 >/sys/devices/system/cpu/intel_pstate/min_perf_pct
echo 80 >/sys/devices/system/cpu/intel_pstate/max_perf_pct
echo 1 >/sys/devices/system/cpu/intel_pstate/no_turbo

kubrick · 2017-01-17 16:13:43

Stegamjay wrote:

Hello Guys,
I'm new in this forum. (my laptop is a DELL XPS 9350 1920x1080 8Go I7-6560U)
I've just read this news : "It's Now Possible To Disable & Strip Down Intel's ME Blob"
https://www.phoronix.com/scan.php?page= … E-Cleaning
Someone succed tu deblob the intel Management engine part of the bios on un 9350 laptop ?
Tanks

The article mentions that it disables secure boot, which is a feature I'm using. Therefore I won't try it before having more clarity on that one...

OdinEidolon · 2017-01-17 18:21:38

Asriel wrote:

OdinEidolon wrote:
Asriel wrote:
So I try to avoid CPU to going into that "gaming" segment unless I am connected to the power socket in the wall.
Can I ask you how you did that, please?
Like this :
echo 15 >/sys/devices/system/cpu/intel_pstate/min_perf_pct
echo 80 >/sys/devices/system/cpu/intel_pstate/max_perf_pct
echo 1 >/sys/devices/system/cpu/intel_pstate/no_turbo

Thanks!

kang · 2017-01-17 23:47:53

I've been re-trying the intel DDX + kde plasma + newest bios on WD15+XPS13 on kernel 4.9.3 since some things have changed... funny behavior now ;-)

- re-plugging the dock once => screen detected but black
- re-plugging the dock twice => screen detected and works (!)
in both cases, USB no longer works, lol.

So basically screen detection is better yet still broken (vs modesetting DDX), USB somehow is more broken (it's not directly related to the DDX but somehow triggers the issues regardless).
On the bright side the intel driver has proper color correction, renders 2D stuff noticeably faster, and doesn't have weird behavior with screenshots and sddm in plasma (modesetting is totally borked with these running a dual screen setup)

I can reproduce the above every time. Maybe its time to try again the drm-intel kernel.

Last edited by kang (2017-01-17 23:59:59)

OdinEidolon · 2017-01-18 09:30:02

Anyone knows if these:
https://01.org/linuxgraphics/intel-linu … -firmwares
are actually included in linux-firmware?

kubrick · 2017-01-18 10:44:28

OdinEidolon wrote:

Anyone knows if these:
https://01.org/linuxgraphics/intel-linu … -firmwares
are actually included in linux-firmware?

Yes they are: https://git.kernel.org/cgit/linux/kerne … /tree/i915

OdinEidolon · 2017-01-18 10:50:03

kubrick wrote:

OdinEidolon wrote:
Anyone knows if these:
https://01.org/linuxgraphics/intel-linu … -firmwares
are actually included in linux-firmware?
Yes they are: https://git.kernel.org/cgit/linux/kerne … /tree/i915

Thanks.

Plawucht · 2017-01-20 17:01:50

kang wrote:

I've been re-trying the intel DDX + kde plasma + newest bios on WD15+XPS13 on kernel 4.9.3 since some things have changed... funny behavior now ;-)
- re-plugging the dock once => screen detected but black
- re-plugging the dock twice => screen detected and works (!)
in both cases, USB no longer works, lol.
So basically screen detection is better yet still broken (vs modesetting DDX), USB somehow is more broken (it's not directly related to the DDX but somehow triggers the issues regardless).
On the bright side the intel driver has proper color correction, renders 2D stuff noticeably faster, and doesn't have weird behavior with screenshots and sddm in plasma (modesetting is totally borked with these running a dual screen setup)
I can reproduce the above every time. Maybe its time to try again the drm-intel kernel.

This is weird.

I'm running linux 4.9.2-nvme + bios 1.4.12 + gnome + intel modeset and what does work for me is everthing "USB", so from charging over my connected devices, HDMI and even VGA.
What does not work is HDMI to DVI-D to my 2560x1440p 27" "korean" monitor. It's not the cable, it's not the HDMI port since I used a mini-dp to hdmi adapter which also gives an output to my 22" 1080p monitor.
All combinations with my 1080p monitor work, none with my 1440p.

With my Aukey CB-C30, all's good:

$ xrandr --listmonitors
Monitors: 2
 0: +*eDP-1 3200/294x1800/165+0+1440  eDP-1
 1: +DP-1 2560/597x1440/336+344+0  DP-1

$ cvt 2560 1440
# 2560x1440 59.96 Hz (CVT 3.69M9) hsync: 89.52 kHz; pclk: 312.25 MHz
Modeline "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync

But with the WD15:

$ xrandr --listmonitors
Monitors: 2
 0: +*eDP-1 3200/294x1800/165+0+1440  eDP-1
 1: +DP-1-2 1024/255x768/255+3200+0  DP-1-2

Alright, resolution and size are fucked, 14" 4:3 monitor it says in gnomes monitor settings.

xrandr --newmode "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync 
xrandr --addmode DP-1-2 2560x1440_60.00 
xrandr --output DP-1-2 --mode 2560x1440_60.00

still the picture put out looks like nothing to describe. It's weird and hard to describe, it's lines and boxes in solid colors mixed running wild, not reacting to changes of the picture. But not what it should output.
Picture here, it's a little larger, so I don't want to post it here in full size
In gnomes monitor settings, it looks like this:

So nothing except the resolution has changed. BummerFUCK.
I do not get, why it works with the Aukey adapter, but not Dell's.
DELL GET YOUR SHIT TOGETHER! GOD FUCKING DAMMIT!

How on earth do I fix this?

I could also get into the dmesg, if anybody wants it, I'll upload them, as soon as I find out why my dmesg is so overfull. Example:
http://pastebin.com/raw/q8CTnFnR
The most interesting part of the dmesg when comparing the WD15 to the CB-C30 is, that it's nearly identical. See here: http://pastebin.com/raw/kuN7HVws

Edit: Just found this thread: https://bbs.archlinux.org/viewtopic.php?id=219601
It says something about

you'll need to flash the latest WD15 firmware to the device

.
Is this even possible without windows?

Last edited by Plawucht (2017-01-20 17:07:54)

vtrac · 2017-01-25 04:54:53

Anyone have an issue coming back from sleep recently? Mine goes to sleep just fie (per the logs), but on wakeup something crashes (I think) and it goes straight to a fresh boot. It has been working fine for weeks.. I guess some package updated because I've tried on a few saved kernels I had that I know were working fine.

robsmith11 · 2017-01-25 06:33:32

vtrac wrote:

Anyone have an issue coming back from sleep recently? Mine goes to sleep just fie (per the logs), but on wakeup something crashes (I think) and it goes straight to a fresh boot. It has been working fine for weeks.. I guess some package updated because I've tried on a few saved kernels I had that I know were working fine.

I used to get this occasionally. Sometimes it would just never wake up and sometimes it would reboot as you described. I haven't experienced it in 1-2 months. I believe the 1.4.10 BIOS update helped, but no way to know for sure.

robsmith11 · 2017-01-25 06:40:13

Asriel wrote:

Great news - latest drm-intel build (made git clone today) - works perfectly with PSR enabled.

Awesome. Last time I tried building drm-intel-nightly from aur, it wouldn't boot, but built it today and it's working great. I'm using the following parameters without problems:

i915.enable_psr=2 i915.enable_rc6=7 i915.semaphores=1 i915.disable_power_well=0

The one regression after upgrading from damige's 4.8 kernel is that NVME power saving doesn't seem to be enabled (idle power usage jumped up by about 1W). Do I need to pass any kernel parameters to enable NVME power savings with drm-intel?

EDIT:
Just confirmed that NVME power saving is disabled:

$ sudo ./nvme get-feature -f 0x0c -H /dev/nvme0
get-feature:0xc (Autonomous Power State Transition), Current value:00000000
        Autonomous Power State Transition Enable (APSTE): Disabled

Are Andy's patches not in drm-intel-nightly? Do I need to do something to enable them?

Last edited by robsmith11 (2017-01-25 08:10:48)

Arch Linux

#1226 2017-01-07 16:07:26

Re: Dell XPS 13 9350 Late 2015

#1227 2017-01-07 16:12:55

Re: Dell XPS 13 9350 Late 2015

#1228 2017-01-07 16:32:41

Re: Dell XPS 13 9350 Late 2015

#1229 2017-01-07 16:40:51

Re: Dell XPS 13 9350 Late 2015

#1230 2017-01-07 17:41:47

Re: Dell XPS 13 9350 Late 2015

#1231 2017-01-10 10:22:02

Re: Dell XPS 13 9350 Late 2015

#1232 2017-01-13 17:28:01

Re: Dell XPS 13 9350 Late 2015

#1233 2017-01-14 06:36:25

Re: Dell XPS 13 9350 Late 2015

#1234 2017-01-16 08:38:16

Re: Dell XPS 13 9350 Late 2015

#1235 2017-01-16 12:11:30

Re: Dell XPS 13 9350 Late 2015

#1236 2017-01-16 12:38:25

Re: Dell XPS 13 9350 Late 2015

#1237 2017-01-16 17:57:06

Re: Dell XPS 13 9350 Late 2015

#1238 2017-01-16 19:28:40

Re: Dell XPS 13 9350 Late 2015

#1239 2017-01-16 20:11:02

Re: Dell XPS 13 9350 Late 2015

#1240 2017-01-16 21:13:53

Re: Dell XPS 13 9350 Late 2015

#1241 2017-01-17 16:13:43

Re: Dell XPS 13 9350 Late 2015

#1242 2017-01-17 18:21:38

Re: Dell XPS 13 9350 Late 2015

#1243 2017-01-17 23:47:53

Re: Dell XPS 13 9350 Late 2015

#1244 2017-01-18 09:30:02

Re: Dell XPS 13 9350 Late 2015

#1245 2017-01-18 10:44:28

Re: Dell XPS 13 9350 Late 2015

#1246 2017-01-18 10:50:03

Re: Dell XPS 13 9350 Late 2015

#1247 2017-01-20 17:01:50

Re: Dell XPS 13 9350 Late 2015

#1248 2017-01-25 04:54:53

Re: Dell XPS 13 9350 Late 2015

#1249 2017-01-25 06:33:32

Re: Dell XPS 13 9350 Late 2015

#1250 2017-01-25 06:40:13

Re: Dell XPS 13 9350 Late 2015

Board footer