Dell XPS 13 9350 Late 2015

zyth88 · 2016-01-09 18:22:14

Thanks altoyr. That fixed the white noise and most pops. Still some pops when booting/shutting down.

bart_vv · 2016-01-09 19:18:41

kgizdov wrote:

sender wrote:
What are the correct fstab options for our NVMe storage?
I was going to set 'discard' but
# hdparm -I /dev/nvme0n1p1 |grep TRIM
yields no output.
Then I found this: https://communities.intel.com/thread/75 … 0&tstart=0
We reviewed your inquiry and have confirmed that with Intel® NVMe SSDs, the discard option when making your Linux filesystem should be turned off. The default extended option is not to discard blocks at filesystem level, retain this. The discard option is not needed an may actually have a performance impact.
What options to set in fstab?
Should this be added to the wiki(s)?
Thanks.
By definition NVMe does not have a TRIM command. It has deallocate. That said, in most cases deallocate is managed internally on firmware level and manufacturers discourage using it manually in your file system options. See this doc from Intel. Moreover, the Dell XPS comes with a Samsung NVMe and Samsung has had very bad rep with TRIM in the past. Many people lost lots of data because of their firmware bugs relating to TRIM in Linux. So I would not recommend trying any of this on your NVMe unless you feel adventurous and want to let us know how it turned out.

I put the discard option into fstab as I always do. Seems to be working without data loss... so far. Didn't know about any differences between SATA and NVMe SSDs, maybe wouldn't do it then. But, AFAIK Windows 10 has discard (or whatever you call it) enabled by default, which would mean that Windows users would probably also suffer from any firmware-level issues, unless some piece of code in Linux invokes some behavior that Windows' code doesn't. Anyway, I think this is highly improbable. Fstrim+cron way always bothered me, having to set something like this, so I simply prefer discard, which should be the proper way to handle SSDs, and should be implemented properly, both in Linux and in firmware, especially after all these years...

kgizdov · 2016-01-10 00:25:08

bart_vv wrote:

I put the discard option into fstab as I always do. Seems to be working without data loss... so far. Didn't know about any differences between SATA and NVMe SSDs, maybe wouldn't do it then. But, AFAIK Windows 10 has discard (or whatever you call it) enabled by default, which would mean that Windows users would probably also suffer from any firmware-level issues, unless some piece of code in Linux invokes some behavior that Windows' code doesn't. Anyway, I think this is highly improbable. Fstrim+cron way always bothered me, having to set something like this, so I simply prefer discard, which should be the proper way to handle SSDs, and should be implemented properly, both in Linux and in firmware, especially after all these years...

It's absolutely your prerogative to do whatever you please. I only put out the info which is in the Arch wiki(in a red box) and numerous online articles that explain why it's disabled by default and why you should not just do it without understanding exactly what it entails. To clarify about the Windows user and so on - deallocate in firmware is not the same thing as invoking file system discard. First and foremost, because discard is file system dependant. You cannot enable it on all file systems. It is a way of the kernel to communicate with the firmware and let it know what "blocks" are not used and can be cleaned, instead of letting the firmware to figure this out on its own. So there are bound to be implementation differences on platforms. For example, if you have an LVM and/or encryption, you cannot use discard.

altoyr wrote:

To get rid of the white-noise install alsamixer then start it -> press F6 -> select 0 HDA Intel PCH -> go to the third lever from left stating "Headphones" and set this one to 22
To get rid of the poping noises I deactivated sound-standby in tlp SOUND_POWER_SAVE_ON_BAT = 0 in /etc/default/tlp
EDIT: I added this to the Wiki, this was my first Wiki-edit so if someone could check it syntax and expression are adequate I would be delighted.

You are a saviour. It's so peaceful now... Thanks.

bart_vv · 2016-01-10 14:35:32

kgizdov wrote:

It's absolutely your prerogative to do whatever you please. I only put out the info which is in the Arch wiki(in a red box) and numerous online articles that explain why it's disabled by default and why you should not just do it without understanding exactly what it entails. To clarify about the Windows user and so on - deallocate in firmware is not the same thing as invoking file system discard. First and foremost, because discard is file system dependant. You cannot enable it on all file systems. It is a way of the kernel to communicate with the firmware and let it know what "blocks" are not used and can be cleaned, instead of letting the firmware to figure this out on its own. So there are bound to be implementation differences on platforms. For example, if you have an LVM and/or encryption, you cannot use discard.

But of course you can, you set the discard flag in your filesystem, so the filesystem will pass any "discard commands" to LVM/dm-crypt layer, which can pass it to the lower layer (to SATA or NVMe driver), which will invoke a TRIM/deallocate command on the bus. Then SSD's firmware will handle that command.

My point is, the only new piece of code here in linux is NVMe driver, and I think that it is highly improbable that TRIM/dealloc is implemented incorrectly in this driver, as all it should do is to invoke proper command on the bus - if something will fail, it probably would be the drive's firmware. And if that will fail, then Windows users should be affected too. At least I hope they will...

daks2 · 2016-01-11 10:26:47

For some reason kernel 4.4 just hates my XPS 13 9350. This appears after a ~30 second blank screen when I try to boot with 4.4.
4.4 kernel error

I've been wading through this thread (YOU GUYS ARE AWESOME) and did the following:
- Realized my 1.00 BIOS was super old and upgraded to 1.1.7
- Saw the bad news about 1.1.7 and promptly went to 1.0.5
- Added the i915.enable_rc6=7 kernel param
- Removed discard from my fstab (old habit)
- Installed the GuC and DMC firmware updates from Intel

I originally thought the GuC/DMC thing was the cause of this error because a GuC/DMC error would appear above "Gave up waiting...", but the Intel update a few pages back seems to have fixed that.

Now I've realized it's just kernel 4.4 (rc8, rc7, and final). Through all of the fiddling I've done with stuff in this thread I've been toggling between 4.4 and 4.3 and I've noticed this only happens on 4.4.

With some light research it seems a re-install might be a fix, but I don't feel like doing that yet. So i'm just sticking to 4.3 for now
Thoughts?

ksim · 2016-01-11 10:33:05

daks2 wrote:

Thoughts?

Do you have nvme in MODULES in mkinitcpio.conf ?

Alad · 2016-01-11 10:49:08

I don't think Ubuntu has a mkinitcpio.conf.

https://wiki.archlinux.org/index.php/Fo … pport_ONLY

Last edited by Alad (2016-01-11 10:55:07)

ksim · 2016-01-11 10:55:26

Alad wrote:

I don't think Ubuntu has a mkinitcpi.conf.
https://wiki.archlinux.org/index.php/Fo … pport_ONLY

then it is better to ask on ubuntu forums about that. as far as I remember ubuntu uses /etc/initramfs-tools/modules, and you can regenerate the images with update-initramfs command, please google for a right way to add modules to the boot image.

frank604 · 2016-01-11 12:57:21

Guys, I am super stoked. A little bit off topic but... my xps 13 is finally coming back from RMA. Due to arrive on the 12th! Just sayin'
On a side note, any new issues brought up from new rc's?

mkey · 2016-01-11 22:15:33

4.4 stable kernel has been released and is available via linux-mainline package.
I've installed it and noticed nothing special unless usual acpi warnings.

That said, I receive these errors when pluging and unpluging AC adapter:

[ 304.868096] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.CHRG] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359)
[ 304.868132] ACPI Error: Method parse/execution failed [\PNOT] (Node ffff8802b80c7ca8), AE_NOT_FOUND (20150930/psparse-542)
[ 304.868151] ACPI Error: Method parse/execution failed [\_SB.AC._PSR] (Node ffff8802b80daaa0), AE_NOT_FOUND (20150930/psparse-542)
[ 304.868186] ACPI Exception: AE_NOT_FOUND, Error reading AC Adapter state (20150930/ac-128)

This happens with 4.3.3-2 kernel too and may lead tlp to miss ac/battery state switching.
Does anybody experience this too ?

Note : I'm running 1.0.5 BIOS version since 1.1.7 is buggy (I mean more than 1.0.5).
Has anyone heard about next BIOS update from Dell ?

daks2 · 2016-01-12 00:57:27

ksim wrote:

Do you have nvme in MODULES in mkinitcpio.conf ?

Alad wrote:

I don't think Ubuntu has a mkinitcpio.conf.
https://wiki.archlinux.org/index.php/Fo … pport_ONLY

ksim wrote:

then it is better to ask on ubuntu forums about that. as far as I remember ubuntu uses /etc/initramfs-tools/modules, and you can regenerate the images with update-initramfs command, please google for a right way to add modules to the boot image.

Thanks for the pointers. For some reason I thought Ubuntu already included the nvme stuff.
Also, I'm an Arch user too so it's not difficult to see the differences in how to apply fixes. I'm not going to ask for Ubuntu troubleshooting help or anything.

But I did have one more question:
Why are people recompiling their kernel to fix the GuC/DMC and nvme issues?
(Because I fixed them by just adding the GuC/DMC firmware binaries with the Intel scripts and adding nvme to my initramfs modules...)

Last edited by daks2 (2016-01-12 06:06:01)

ksim · 2016-01-12 08:28:45

daks2 wrote:

But I did have one more question:
Why are people recompiling their kernel to fix the GuC/DMC and nvme issues?
(Because I fixed them by just adding the GuC/DMC firmware binaries with the Intel scripts and adding nvme to my initramfs modules...)

we do not recompile kernels because of firmware or nvme, 4.4 version is not available as a binary package yet and we are using AUR and compile the kernel from sources, about firmwares: I am using linux-firmware package, it contains intel video skylake firmwares already as well as broadcomm one.

dedsm · 2016-01-12 10:24:53

Hello guys, does anyone experience black screen when resuming from suspend? it happens to me randomly, all I can do is force-shutdown and unicorns die when I do that.

ksim · 2016-01-12 12:28:09

dedsm wrote:

Hello guys, does anyone experience black screen when resuming from suspend? it happens to me randomly, all I can do is force-shutdown and unicorns die when I do that.

kernel, distr, logs?

dedsm · 2016-01-12 12:51:50

ksim wrote:

dedsm wrote:
Hello guys, does anyone experience black screen when resuming from suspend? it happens to me randomly, all I can do is force-shutdown and unicorns die when I do that.
kernel, distr, logs?

well, using linux-mainline, now in 4.4, sadly it's hard to get logs without being able to see anything, I'll try to debug it soon, it was more a shot to the moon to see if anyone was experiencing this.

zetxx · 2016-01-12 13:08:37

frank604 wrote:

Guys, I am super stoked. A little bit off topic but... my xps 13 is finally coming back from RMA. Due to arrive on the 12th! Just sayin'
On a side note, any new issues brought up from new rc's?

Glad to here that from you

daks2 · 2016-01-12 19:42:10

ksim wrote:

daks2 wrote:
But I did have one more question:
Why are people recompiling their kernel to fix the GuC/DMC and nvme issues?
(Because I fixed them by just adding the GuC/DMC firmware binaries with the Intel scripts and adding nvme to my initramfs modules...)
we do not recompile kernels because of firmware or nvme, 4.4 version is not available as a binary package yet and we are using AUR and compile the kernel from sources, about firmwares: I am using linux-firmware package, it contains intel video skylake firmwares already as well as broadcomm one.

Gotcha, thanks.

Last edited by daks2 (2016-01-12 19:42:19)

vilavil · 2016-01-13 09:40:11

BIOS 1.1.9 is out :
http://www.dell.com/support/home/us/en/ … op/drivers

However, no improvements on my side. I still get 6W idle (50% screen brightness, wifi on) as before the update, and dmesg still shows all the errors it used to. No fix for this bug yet :
https://bugzilla.kernel.org/show_bug.cgi?id=109511

zetxx · 2016-01-13 16:09:30

vilavil wrote:

BIOS 1.1.9 is out :
http://www.dell.com/support/home/us/en/ … op/drivers
However, no improvements on my side. I still get 6W idle (50% screen brightness, wifi on) as before the update, and dmesg still shows all the errors it used to. No fix for this bug yet :
https://bugzilla.kernel.org/show_bug.cgi?id=109511

what was your previous version ? 1.0.5 or 1.1.7 ?

vilavil · 2016-01-13 17:36:18

zetxx wrote:

vilavil wrote:
BIOS 1.1.9 is out :
http://www.dell.com/support/home/us/en/ … op/drivers
However, no improvements on my side. I still get 6W idle (50% screen brightness, wifi on) as before the update, and dmesg still shows all the errors it used to. No fix for this bug yet :
https://bugzilla.kernel.org/show_bug.cgi?id=109511
what was your previous version ? 1.0.5 or 1.1.7 ?

1.1.7 was my previous one.

zetxx · 2016-01-14 08:50:40

so, its still as buggy as 1.1.7

kgizdov · 2016-01-14 09:14:30

I still have the problem with ACPI and the USB-C - Nexus 6P still doesn't connect and laptop cannot shut down gracefully afterwards...

angelo · 2016-01-15 01:27:54

Is there a benefit to updating the bios to 1.1.9, in terms of power usage or anything else?
I am currently with 1.0.5.

ksim · 2016-01-15 17:20:23

angelo wrote:

Is there a benefit to updating the bios to 1.1.9, in terms of power usage or anything else?
I am currently with 1.0.5.

I am using the latest BIOS + 4.4 kernel from testing, average power consumption for 16Gb/512Gb/QHD model (wifi on, brightness about minimum, idle activity) is 5-6W, screen off - 2.8-3.4W.

SheepOnMeth · 2016-01-17 15:05:07

I have been running the 1.1.7 on a FHD model with no problem since it was available. What are the proofs that this one is buggy ?

I am upgrading to the one.

Arch Linux

#226 2016-01-09 18:22:14

Re: Dell XPS 13 9350 Late 2015

#227 2016-01-09 19:18:41

Re: Dell XPS 13 9350 Late 2015

#228 2016-01-10 00:25:08

Re: Dell XPS 13 9350 Late 2015

#229 2016-01-10 14:35:32

Re: Dell XPS 13 9350 Late 2015

#230 2016-01-11 10:26:47

Re: Dell XPS 13 9350 Late 2015

#231 2016-01-11 10:33:05

Re: Dell XPS 13 9350 Late 2015

#232 2016-01-11 10:49:08

Re: Dell XPS 13 9350 Late 2015

#233 2016-01-11 10:55:26

Re: Dell XPS 13 9350 Late 2015

#234 2016-01-11 12:57:21

Re: Dell XPS 13 9350 Late 2015

#235 2016-01-11 22:15:33

Re: Dell XPS 13 9350 Late 2015

#236 2016-01-12 00:57:27

Re: Dell XPS 13 9350 Late 2015

#237 2016-01-12 08:28:45

Re: Dell XPS 13 9350 Late 2015

#238 2016-01-12 10:24:53

Re: Dell XPS 13 9350 Late 2015

#239 2016-01-12 12:28:09

Re: Dell XPS 13 9350 Late 2015

#240 2016-01-12 12:51:50

Re: Dell XPS 13 9350 Late 2015

#241 2016-01-12 13:08:37

Re: Dell XPS 13 9350 Late 2015

#242 2016-01-12 19:42:10

Re: Dell XPS 13 9350 Late 2015

#243 2016-01-13 09:40:11

Re: Dell XPS 13 9350 Late 2015

#244 2016-01-13 16:09:30

Re: Dell XPS 13 9350 Late 2015

#245 2016-01-13 17:36:18

Re: Dell XPS 13 9350 Late 2015

#246 2016-01-14 08:50:40

Re: Dell XPS 13 9350 Late 2015

#247 2016-01-14 09:14:30

Re: Dell XPS 13 9350 Late 2015

#248 2016-01-15 01:27:54

Re: Dell XPS 13 9350 Late 2015

#249 2016-01-15 17:20:23

Re: Dell XPS 13 9350 Late 2015

#250 2016-01-17 15:05:07

Re: Dell XPS 13 9350 Late 2015

Board footer