Dell XPS 13 9350 Late 2015

belette · 2016-11-15 18:55:57

Dock WD15 update
I received the dock today, as far as I can see everything is working well except Ethernet re-scan after suspend.
Most of the time after a suspend the Ethernet port is not recognized any more, I think I remember someone with the same issue in the past (I had with the DA200 but was solved after a kernel update, apparently not for the WD15).
Anyone on WD15 with the same issue ? Any tips to solve / having a workaround to re-scan the bus to force detect it ?

frank604 · 2016-11-16 00:37:13

@belette, My apologies. I do have the wd15. I mentioned everything was working. I did not use ethernet on the dock enough to realize this was an issue. You can write a systemd service to run a script that does:

sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:02:02.0/remove"
sudo sh -c "echo 1 > /sys/bus/pci/rescan"

Use dmesg output and lspci -vv to confirm right path.
lspci -vv:

02:02.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015] (prog-if 00 [Normal decode])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 128 bytes
	Interrupt: pin A routed to IRQ 286
	Bus: primary=02, secondary=39, subordinate=39, sec-latency=0
	Memory behind bridge: d9f00000-d9ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport
	Kernel modules: shpchp

Then I went to /sys/bus/pci/devices/ and looked in 0000:02:02.0 and saw remove. When I echo "1" to remove, it will remove all port assignments to devices plugged into my wd15 dock. This includes keyboard and mouse (for me). So I went on built-in keyboard and issued an overall rescan. Hence the explanation of this script.

To enable the script, remember to chmod +x and to allow this script to run without entering root password. There is probably a better way, but to automatically provide priviledge to the script you can add in visudo:

userName ALL= NOPASSWD: /path/to/your/script

Also write a bug report upstream in acpi probably? That way this can be resolved.

Here is dmesg output after suspend and resume cycle that shows error for pcieport:

1 frank604@XPS13 ~ (git)-[master] % dmesg | tail -n 40                                      
[  +0.002914] wlan0: associated
[  +0.000102] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  +2.998222] wlan0: deauthenticating from 4e:d9:e7:69:b0:ee by local choice (Reason: 3=DEAUTH_LEAVING)
[  +0.009631] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  +0.008922] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  +3.990129] wlan0: authenticate with 4e:d9:e7:69:b0:ee
[  +0.057311] wlan0: send auth to 4e:d9:e7:69:b0:ee (try 1/3)
[  +0.002527] wlan0: authenticated
[  +0.002706] wlan0: associate with 4e:d9:e7:69:b0:ee (try 1/3)
[  +0.007496] wlan0: RX AssocResp from 4e:d9:e7:69:b0:ee (capab=0x431 status=0 aid=2)
[  +0.004964] wlan0: associated
[  +0.000100] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[Nov10 04:22] pcieport 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
[  +0.000033] pcieport 0000:02:02.0: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  +0.000001] pcieport 0000:02:02.0: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  +0.000003] pcieport 0000:02:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[  +0.000001] pcieport 0000:02:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[  +0.000001] pcieport 0000:02:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[  +0.000001] pcieport 0000:02:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[Nov10 04:32] pcieport 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
[  +0.000035] pcieport 0000:02:02.0: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  +0.000001] pcieport 0000:02:02.0: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  +0.000003] pcieport 0000:02:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[  +0.000001] pcieport 0000:02:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[  +0.000002] pcieport 0000:02:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[  +0.000001] pcieport 0000:02:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[Nov10 04:42] pcieport 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
[  +0.000003] pcieport 0000:02:02.0: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  +0.000001] pcieport 0000:02:02.0: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  +0.000003] pcieport 0000:02:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[  +0.000000] pcieport 0000:02:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[  +0.000002] pcieport 0000:02:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[  +0.000001] pcieport 0000:02:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[ +16.408751] pcieport 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
[  +0.000039] pcieport 0000:02:02.0: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  +0.000001] pcieport 0000:02:02.0: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  +0.000004] pcieport 0000:02:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[  +0.000002] pcieport 0000:02:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[  +0.000001] pcieport 0000:02:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[  +0.000001] pcieport 0000:02:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]

Link to systemd file in case you want: https://github.com/frank604/Dell-XPS-13 … emd.system
For visudo I added: %wheel ALL = NOPASSWD: /path/to/my/script
Link to script: https://github.com/frank604/scripts/blob/master/wd15
Enable service. Suspend/resume to test. ??? profit

Last edited by frank604 (2016-11-16 00:53:51)

belette · 2016-11-16 09:25:44

@frank604 many thanks for your explanations ! I will test this

Apparently it is working (at least the manual way, I have to test in under a systemd).

Btw, do you have some issues when you disconnect and reconnect the usb c to your XPS?
I already have a bad kernel panic, was able to take a picture:
I had a lot of "[drm: intel_wait_ddi_buf_idle [i915]] *ERROR* Timoueout waiting for DDI BUF B idle patterns" or finishing by bit instead of patterns

I realized for my first tests that connecting and disconnecting usb c is not very stable for me (sometimes the external screen is detected but no signal is sent, pushing the power button of the dock and power up again solve the issue).

What do you think about issuing the script you propose each time the dock is plug on usb type c ? (still don't know how to do it)

Many thanks

Last edited by belette (2016-11-16 12:38:08)

robsmith11 · 2016-11-16 14:45:05

Has anyone else tried the linux-drm-intel-nightly kernel?

I tried to boot it on my 9350, but nvme_core threw some unknown symbol errors:
http://picpaste.com/pics/IMG_20161116_2 … 307111.jpg

frank604 · 2016-11-16 18:53:57

@belette, just copy the service to /etc/systemd/system and then enable the service via systemctl. I use the intel drm branch of kernel and I don't see those errors. I use autorandr with udev rules. Of course I had to create the profiles for mobile and docked. Instead of rebooting wd15, have you manually tried to set the external monitor via xrandr? If you want to run the script upon plug in of dock, you'd need to create udev rules.

@robsmith11, my last compile was a few days ago. I do use the linux-drm-intel-nightly but I use my own version of config file and pkgbuild for the linux drm branch. I do not see the errors.

edit: clarification

Last edited by frank604 (2016-11-17 02:02:43)

kang · 2016-11-18 01:36:12

belette wrote:

@frank604 many thanks for your explanations ! I will test this
Apparently it is working (at least the manual way, I have to test in under a systemd).
Btw, do you have some issues when you disconnect and reconnect the usb c to your XPS?
I already have a bad kernel panic, was able to take a picture:
I had a lot of "[drm: intel_wait_ddi_buf_idle [i915]] *ERROR* Timoueout waiting for DDI BUF B idle patterns" or finishing by bit instead of patterns
I realized for my first tests that connecting and disconnecting usb c is not very stable for me (sometimes the external screen is detected but no signal is sent, pushing the power button of the dock and power up again solve the issue).
What do you think about issuing the script you propose each time the dock is plug on usb type c ? (still don't know how to do it)
Many thanks

I used to have a stable setup using the modesetting driver but recently it started doing the same. It doesn't seem to be the kernel (which i downgraded to test), the other things that got updated are the xorg drivers and other libraries though (no idea which one would be at fault).
I probably should test with modesetting downgraded in case that's that. Didn't think of hitting the dock power though lol. Going to try that at work tomorrow

belette · 2016-11-18 18:36:05

Will try when I'll connect my HDMI again, I thought it was HDMI issue as my external screen is a 3440x1440 and on HDMI 60Hz is not really supported well even if it is working!
Now I am facing another big issue... Display Port is not working at all
xrandr is seeing something but don't think it is related to the DP as if I disconnect or reconnect it xrandr is showing the same result :

Screen 0: minimum 8 x 8, current 6640 x 1800, maximum 32767 x 32767
eDP1 connected 3200x1800+0+0 (normal left inverted right x axis y axis) 290mm x 170mm
   3200x1800     59.98*+  47.99  
   2560x1440     60.00  
   2048x1536     60.00  
   1920x1440     60.00  
   1856x1392     60.01  
   1792x1344     60.01  
   2048x1152     60.00  
   1920x1080     60.00  
   1600x1200     60.00  
   1400x1050     59.98  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1368x768      60.00  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   640x360       60.00  
DP1 disconnected (normal left inverted right x axis y axis)
DP1-1 disconnected (normal left inverted right x axis y axis)
DP1-2 disconnected (normal left inverted right x axis y axis)
DP1-2-1 disconnected (normal left inverted right x axis y axis)
DP1-2-8 connected 3440x1440+3200+0 (normal left inverted right x axis y axis) 800mm x 330mm
   3440x1440     59.97*+  49.99  
   2560x1440     59.95  
   2560x1080     60.00  
   1720x1440     60.00  
   1920x1080     60.00    60.00    50.00    59.94  
   1600x1200     60.00  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
DP1-3 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Have you been able to use DP on your side?

frank604 wrote:

@belette, just copy the service to /etc/systemd/system and then enable the service via systemctl. I use the intel drm branch of kernel and I don't see those errors. I use autorandr with udev rules. Of course I had to create the profiles for mobile and docked. Instead of rebooting wd15, have you manually tried to set the external monitor via xrandr? If you want to run the script upon plug in of dock, you'd need to create udev rules.

belette · 2016-11-18 18:40:03

When you said you are using modesetting what exactly did you set? Is i915 in mkinitcpio.con MODULES enough or have you had something into the kernel parameters as well?
Are you using DP or HDMI btw ? (as I replied to frank604, my DP is not working at all :-(

Don't hesitate to let us know about your tests, very interested to see the result

kang wrote:

belette wrote:
@frank604 many thanks for your explanations ! I will test this
Apparently it is working (at least the manual way, I have to test in under a systemd).
Btw, do you have some issues when you disconnect and reconnect the usb c to your XPS?
I already have a bad kernel panic, was able to take a picture:
I had a lot of "[drm: intel_wait_ddi_buf_idle [i915]] *ERROR* Timoueout waiting for DDI BUF B idle patterns" or finishing by bit instead of patterns
I realized for my first tests that connecting and disconnecting usb c is not very stable for me (sometimes the external screen is detected but no signal is sent, pushing the power button of the dock and power up again solve the issue).
What do you think about issuing the script you propose each time the dock is plug on usb type c ? (still don't know how to do it)
Many thanks
I used to have a stable setup using the modesetting driver but recently it started doing the same. It doesn't seem to be the kernel (which i downgraded to test), the other things that got updated are the xorg drivers and other libraries though (no idea which one would be at fault).
I probably should test with modesetting downgraded in case that's that. Didn't think of hitting the dock power though lol. Going to try that at work tomorrow

kang · 2016-11-19 18:53:23

i meant the xorg modesetting driver.
i use display port on the dock myself. i used hdmi as well before, both working equally well or bad here. as in, same behavior.
my screen is a 60hz 1440p screen.

using the dock power button did not seem to help.

the current issue is that after the screen has been uses once with the dock, unolugging it wont detect the screen is unplugged. plugging back in doesn't send signal to the screen.
using remove/rescan via sysfs does not help (all this work fine for the USB devices)

i used to have that behavior only with the intel xorg driver, but now modesetting as well. havent tried downgrade yet, busy work day

kubrick · 2016-11-20 00:23:38

Hi,

After reading this review: http://www.notebookcheck.net/Dell-XPS-1 … 081.0.html

It came to me that maybe one of the big power drains for QHD+ model was the higher resolution.
I have been experimenting a bit with using the screen at half the resolution (1600x900) and it seems to help. My non-scientific observation seem to show that I can squeeze out about 10% more battery life (8h+ with light firefox browsing).
Powertop reports that the GPU package spends as much of 99% of the time in Idle state (RC6) and it also seems to help the whole CPU package to spend as much as 65% in the C8(pc8) state.
Can anybody else confirm those findings?

Also, "i915.enable_psr=1" seems to help but it makes my screen freeze for a second or two quite often, does anybody else see that too? For me it's completely unusable on X11 but only a bit annoying on Wayland (for a change...).

Cheers,
F

frank604 · 2016-11-20 01:33:26

@kubrick, I've been using my qhd at 1920x1080. I've also set kernel tick to 250hz from the default 300hz. I've also disabled NUMA in kernel. And of course the NVME power saving patch. I haven't tried to enable psr for the exact same reason you mentioned.

8h+ for light browsing/chatting/text editing sounds about right. I'm not sure if resolution would help increase battery life though.

kubrick · 2016-11-20 09:36:15

@frank604 I didn't find that the NVMe patch was making any difference at all, did you?

frank604 · 2016-11-20 09:47:10

For the FHD I noticed a big improvement. Lowered idle temps and less drain. Not too sure yet with QHD as it is new. But all of this is speculation. i've never ran any 'real' tests.

OdinEidolon · 2016-11-20 11:03:34

kubrick wrote:

Hi,
After reading this review: http://www.notebookcheck.net/Dell-XPS-1 … 081.0.html
It came to me that maybe one of the big power drains for QHD+ model was the higher resolution.
I have been experimenting a bit with using the screen at half the resolution (1600x900) and it seems to help. My non-scientific observation seem to show that I can squeeze out about 10% more battery life (8h+ with light firefox browsing).
Powertop reports that the GPU package spends as much of 99% of the time in Idle state (RC6) and it also seems to help the whole CPU package to spend as much as 65% in the C8(pc8) state.
Can anybody else confirm those findings?
Also, "i915.enable_psr=1" seems to help but it makes my screen freeze for a second or two quite often, does anybody else see that too? For me it's completely unusable on X11 but only a bit annoying on Wayland (for a change...).
Cheers,
F

To be honest I strongly suspect that if you run rigorous tests you will see a difference well below 10%. Most of the increased battery consumption from the QHD does not come from increased CPU/GPU load (especially under 2D tasks), but from the fact that a much stronger backlight is needed due to the higher pixel density.

belette · 2016-11-20 22:25:01

I never thought about testing modesetting driver, just to confirm could you share your xorg configuration to use modesetting instead of intel driver ?
or should I remove xf86-video-intel and it will automatically failled back to modesetting?

kang wrote:

i meant the xorg modesetting driver.
i use display port on the dock myself. i used hdmi as well before, both working equally well or bad here. as in, same behavior.
my screen is a 60hz 1440p screen.
using the dock power button did not seem to help.
the current issue is that after the screen has been uses once with the dock, unolugging it wont detect the screen is unplugged. plugging back in doesn't send signal to the screen.
using remove/rescan via sysfs does not help (all this work fine for the USB devices)
i used to have that behavior only with the intel xorg driver, but now modesetting as well. havent tried downgrade yet, busy work day

kang · 2016-11-21 06:41:32

In /etc/X11/xorg.conf.d/20-intel.conf for ex, just have this:

Section "Device"
        Identifier "Intel Graphics"
       Driver "modesetting"
EndSection

Removing the xf86-video-intel does also default back to modesetting AFAIR, though through config its easy to switch anyway.
Also i looked at my last update of it and its much prior i started running into troubles again with this, so im not quite sure atm what broke functionality

Last edited by kang (2016-11-21 06:44:22)

belette · 2016-11-21 12:24:40

Interesting thanks!
Will test this tomorrow to see as I am experimenting the same issue as you (when you disconnect and reconnect) but also for me DP is not working at all (comparing to HDMI where it is working but with the same behavior as you when disconnecting / connecting again)

kang wrote:

In /etc/X11/xorg.conf.d/20-intel.conf for ex, just have this:
Section "Device"
        Identifier "Intel Graphics"
       Driver "modesetting"
EndSection
Removing the xf86-video-intel does also default back to modesetting AFAIR, though through config its easy to switch anyway.
Also i looked at my last update of it and its much prior i started running into troubles again with this, so im not quite sure atm what broke functionality

kang · 2016-11-22 00:07:56

just made some more tests with both HDMI and DP. Same issues though I noticed with HDMI when you disconnect the dock, it shows the monitor is still connected with a subset of the resolutions available (when connected, shows all resolutions)
With DP, it always shows connected with all resolutions.

pci rescan, remove + rescan, xrandr --output xxx --off followed by xrandr --output xxx --auto, intel driver, modesetting driver all exhibit this behavior. I'm guessing its kernel related but I don't understand why when I downgrade to 4.7 this still occurs. Maybe something in the maintenance releases of 4.7 broke it, or maybe its something else.

In any case, this seems to ultimately be an issue in the i915 driver or/and PCI though since it should no longer show the device as connected when I disconnect the dock (OR/AND forcefully call remove in /sys) - and when I reconnect the dock, it's confused by that state somehow (hence no signal is sent to the screen - again dock works for audio, usb, and ethernet otherwise just fine).

I'm currently compiling the latest linux-drm-intel-nightly out of curiosity.

Side note on NVME patches: I tested that a couple of days ago on my i7 QHD and I see a difference. I run at 6.5W (idle/lowest) with kde+chrome+wifi on, mid brightness at full QHD resolution with nvme patches. Otherwise I'm around 7.5w. Measurements were ran with powertop, averaged over 5min of idling

Last edited by kang (2016-11-22 00:09:33)

kgizdov · 2016-11-22 14:17:09

There's a new BIOS - 1.4.10

belette · 2016-11-22 19:16:37

I just finished the update thanks for letting us know, I hope it would improve my usb c experience as I saw a firmware update during the fw update

kgizdov wrote:

There's a new BIOS - 1.4.10

kang · 2016-11-23 00:34:21

updated to 1.4.10, did not solve issues with the screen detection for me

oh also, this, since 4.8 https://bugs.freedesktop.org/show_bug.cgi?id=98214

edit:
I reverted to 4.7.4 + modesetting DDX and detection works again. I must have missed something last time I did this.
So something in 4.8 "broke this", which I guess I'd have to bisect to figure out (which I don't really wanna do lol, it takes FOREVER to boot these Dell laptops - the EFI is so slow). 4.8+modesetting DDX is also pretty crappy all around (weird rendering and all) for some reason. Anyhow, yay.

@belette I also just remembered: make sure in bios/efi you have tested with the security for thunderbolt being fully off/disabled, it caused me troubles in the past even thus i'm using a Dell dock (works fine in windows though)

Last edited by kang (2016-11-23 01:22:08)

pimp · 2016-11-23 14:47:31

Thanks for all the help you guys are posting on this thread.

I keep getting random crashes, i removed "i915" from my mkinitcpio.conf file but left "nvme" this morning, seems to be better so far, but who knows!

Is that still needed with 4.8.10-1-ARCH???

I have tried over the last few days to compile franks "Intel-DRM-Nightly" on his github and also tried installing the nightly from aur, but they both keep failing to compile

So what i'm really asking is, what flags/modules/non-standard part do we need to use with the latest 4.8.10 kernal

Cheers

frank604 · 2016-11-23 19:45:45

@pimp, none that I know of in terms of kernel options. Can you use ix or similar to pipe complete output of your installation for intel drm nightly kernel her in code brackets?

edit: If you want help with crashes we will need more info. journalctl logs, xorg, history of crash.

Last edited by frank604 (2016-11-23 19:49:32)

kang · 2016-11-23 20:02:18

the current version of intel drm nightly has a bunch of modules broken - though it did build for me yesterday. it just doesnt really work well right now ;-)

belette · 2016-11-23 23:53:28

This is interesting, thanks for sharing the link...
Would be great to get this solved for 4.9, but I don't see any update from the beginning of this month

kang wrote:

updated to 1.4.10, did not solve issues with the screen detection for me
oh also, this, since 4.8 https://bugs.freedesktop.org/show_bug.cgi?id=98214

I tried modesetting on 4.8.10 but my X is crashing, perhaps I have to test it like you on latest 4.7

kang wrote:

edit:
I reverted to 4.7.4 + modesetting DDX and detection works again. I must have missed something last time I did this.
So something in 4.8 "broke this", which I guess I'd have to bisect to figure out (which I don't really wanna do lol, it takes FOREVER to boot these Dell laptops - the EFI is so slow). 4.8+modesetting DDX is also pretty crappy all around (weird rendering and all) for some reason. Anyhow, yay.

Outch!!! Many thanks for the suggestion, actually I realized I forgot to click on "Always allow Dell Dock..." now DP is working, I got the same behavior as you got (not recognized after the second reconnection on 4.8.X (even on 4.8.10 installed today)

kang wrote:

@belette I also just remembered: make sure in bios/efi you have tested with the security for thunderbolt being fully off/disabled, it caused me troubles in the past even thus i'm using a Dell dock (works fine in windows though)

Arch Linux

#1101 2016-11-15 18:55:57

Re: Dell XPS 13 9350 Late 2015

#1102 2016-11-16 00:37:13

Re: Dell XPS 13 9350 Late 2015

#1103 2016-11-16 09:25:44

Re: Dell XPS 13 9350 Late 2015

#1104 2016-11-16 14:45:05

Re: Dell XPS 13 9350 Late 2015

#1105 2016-11-16 18:53:57

Re: Dell XPS 13 9350 Late 2015

#1106 2016-11-18 01:36:12

Re: Dell XPS 13 9350 Late 2015

#1107 2016-11-18 18:36:05

Re: Dell XPS 13 9350 Late 2015

#1108 2016-11-18 18:40:03

Re: Dell XPS 13 9350 Late 2015

#1109 2016-11-19 18:53:23

Re: Dell XPS 13 9350 Late 2015

#1110 2016-11-20 00:23:38

Re: Dell XPS 13 9350 Late 2015

#1111 2016-11-20 01:33:26

Re: Dell XPS 13 9350 Late 2015

#1112 2016-11-20 09:36:15

Re: Dell XPS 13 9350 Late 2015

#1113 2016-11-20 09:47:10

Re: Dell XPS 13 9350 Late 2015

#1114 2016-11-20 11:03:34

Re: Dell XPS 13 9350 Late 2015

#1115 2016-11-20 22:25:01

Re: Dell XPS 13 9350 Late 2015

#1116 2016-11-21 06:41:32

Re: Dell XPS 13 9350 Late 2015

#1117 2016-11-21 12:24:40

Re: Dell XPS 13 9350 Late 2015

#1118 2016-11-22 00:07:56

Re: Dell XPS 13 9350 Late 2015

#1119 2016-11-22 14:17:09

Re: Dell XPS 13 9350 Late 2015

#1120 2016-11-22 19:16:37

Re: Dell XPS 13 9350 Late 2015

#1121 2016-11-23 00:34:21

Re: Dell XPS 13 9350 Late 2015

#1122 2016-11-23 14:47:31

Re: Dell XPS 13 9350 Late 2015

#1123 2016-11-23 19:45:45

Re: Dell XPS 13 9350 Late 2015

#1124 2016-11-23 20:02:18

Re: Dell XPS 13 9350 Late 2015

#1125 2016-11-23 23:53:28

Re: Dell XPS 13 9350 Late 2015

Board footer