Dell D6000 dock resetting on Ubuntu 16.04
 

Hi,

Every 1-2 hours (in random intervals, sometimes shorter) my two monitors stop getting a signal. If I unplug the dock they start working again. The keyboard and mouse still work though.

Hardware: Latitude 7280, D6000 dock, Dell monitors

Software: Ubuntu 16.04 (i3 window manager)

Initially the monitors didn't work at all, but started after I installed different graphics drivers (these ones)

dmesg outputs these messages:

and then

Hi mbokulic,

Could you please gather logs and attach a zip file to this thread?
To capture these, please follow the instructions from this article:
http://support.displaylink.com/knowl...to-displaylink

Thanks,
Szymon

Braaaaiiiiinnsss (zombie thread)
 

Hi Szymon,

Fedora 26, same displaylink device, exhibits same behaviour. Log attached.

I have the same dock (Dell D6000) and the same symptoms (every 1h to every 10m everything goes down, including ext. displays). Logs are attached.

Update: DisplayLinkManager crashes that are inside the report are not related to this case (but would be worth investigating nevertheless).

Ubuntu 17.10 Beta 2
 

Dell XPS 15 9560 + Dell D6000 @ Ubuntu 17.10 Beta 2 (Gnome @ Xorg)

Random dock disconnect (everything). Re-connecting fixes the issue. Attaching log after 2 disconnects.

EDIT: My bad, only display goes black.

Same issue here. Dell D6000 Dock, 130W adapter, and Latitude 7480

I found a way to bring a display back to life if it's off but available from xrandr output. You need to say something like
It works, but unfortunately I have to rearrange displays after that. Something like

If you use arandr, you can save the monitor config. It saves as a .sh so you just get to re-execute that script and it will re-arrange your monitors.

Handy for having multiple configurations that you use and scripting between them with udev.

In my case, gnome is supposed to take care of it. Unfortunately, display device names (IDs) are changing sometimes after a reboot (or replug), so it fails to do its job and I have to use xrandr. And yes, I ended up saving this to a script (need to think about how to handle changing IDs).

My earlier advise about using xrandr is not working for me either :( I now have monitors shown as on in xrandr, but they are in fact in power saving mode. All this happens once in a while, when a message appears in kernel logs:

This seems like a device wants to sleep, and the kernel can't prevent it and is losing it. Nevertheless, in a moment it brings itself back to life, with everything connected though it working -- except, alas, for the monitors.

That actually gave me an idea. I've attached the dell dock to USB described as 2-2.1 and did:

essentially disabling autosuspend on this bus. Will test how it works, but you may want to try it too.

Edit: For XPS 9560 USB-C Port it will be:

I tried this as well some time ago, and tried again today. Doesn't change anything :(

The other thing I tried is powering the laptop from the usual power supply (I guess if you plug it it, power over USB-C is disabled, but I can't check that).

Yet another thing to try was not setting external display to be primary (i.e. keep the internal panel, eDP1, as primary).

Unfortunately, none of the above helps, I am still getting disconnects. My gut feeling it is bad hardware (either the Thunderbolt controller, or the displayport hardware in the dock, or maybe even both).

Continuing my research, I found that some people say changing the Wi-Fi board from Atheros or Broadcom to Intel makes the Thunderbolt controller work better. As my Atheros 10k wifi is noticeably bad (bad performance, occasional lockups and kernel oopses) I am going to change it anyway and will report back if it helps (I doubt it, but worth a shot).

The next thing I found is, there's so called "USB-C alternate mode" that (among the other things) enables external displays to be connected through USB-C. It looks like, Dell XPS 13 9360 has two DisplayPorts routed to USB-C. I have yet to figure out what dock is required for that (Dell TB-16 I guess) and whether or not it works for Linux.

A new info,
I have noticed that the disconnects happens much less frequently when charging an empty battery (on USB-C) or discharing the laptop (USB3 without adapter).

Any ideas?

I tried it, haven't noticed any differences. Ended up sending the D6000 back, and will make sure to never buy anything with DisplayLink logo again. What I regret is the time I spent trying to make this non-working thing actually work. I mean, in theory (let's compress video and send it over USB for the dock to decompress and show) it sounds OK, in practice, it does not work, and even when it is (maybe in Windows?), it uses lots of CPU, which is not OK.

My research shows that the Thunderbolt (aka USB-C) port in Dell XPS 13 9360 has two displayport outputs wired (using USB-C alternate mode), and with a proper dock/adapter you'll have two working display outputs. So, I have now ordered Dell TB16 dock; Linux reviews are pretty positive (there was a bug making its Ethernet working at full speed, 1 gbps, but it seems it is fixed in latest kernels).

working solution
 

After a few days of struggling, I managed to find a solution on Ubuntu 17.10. Hope this works for everyone having problems with the D6000 dock. Below format is markdown (to lazy to convert it)

## Instructions for fixing the blanking monitor on dock issue within Ubuntu.
**Make sure to reboot after making the changes!**

#### Disable USB AutoSuspend
* `sudo gedit /etc/default/tlp` and change the below value from `1` to `0`

```
USB_AUTOSUSPEND=0
```

* `sudo gedit /etc/udev/rules.d/01-usb-dock.rules`. This will create a new file.

```
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1bcf", ATTR{idProduct}=="2b95", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1bcf", ATTR{idProduct}=="0005", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1d6b", ATTR{idProduct}=="0002", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1d6b", ATTR{idProduct}=="0003", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04d9", ATTR{idProduct}=="0143", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04f3", ATTR{idProduct}=="24a1", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05e3", ATTR{idProduct}=="0608", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05e3", ATTR{idProduct}=="0610", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05e3", ATTR{idProduct}=="0620", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="06c4", ATTR{idProduct}=="c411", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="17e9", ATTR{idProduct}=="6006", TEST=="power/control", ATTR{power/control}="on"
```

#### Disable Display Power Management
* `sudo gedit /etc/X11/xorg.conf` Append the below options to the file.

```
Section "Monitor"
Identifier "DVI-I-3-2"
Option "DPMS" "false"
EndSection

Section "Monitor"
Identifier "DVI-I-2-1"
Option "DPMS" "false"
EndSection
```

#### Disable audio suspend
* `sudo gedit /etc/pulse/default.pa`. Comment out the line indicated below.

```
### Automatically suspend sinks/sources that become idle for too long
# load-module module-suspend-on-idle
```

#### Disale USB wake in BIOS
Boot into the BIOS by pressing the F12 key as the machine turns on. Under `Power Management` >> `USB Wake Support` uncheck both boxes.

I have only just recently come across this hardware.

I too have been experiencing the resetting. At first I thought it was my specific unit as the USB-C power appears to be cut as well and the LED goes from white to red which might indicate that there is some physical link problem. But after reading this forum, I'm starting to doubt that.

The "working solution" posted seem to change vastly too many things to narrow down the problem. It cannot possibly be that _all_ of them are required to fix things.

I'm on ArchLinux so the Ubuntu based instructions need to be converted to my settings. I've tried fiddling with each of these things and none of them individually seem to help.

Can you try removing one fix at a time and see when the issue of disconnections reappears?

Trust me, I tried each of these individually and as soon as I reverted any one of them the problem started again. It seems to me that any power management that Linux attempts to apply to this unit causes either the unit itself or three connection to cycle.

I cannot see how bios support for wake on USB could cause these disconnections. That just seems totally orthogonal to the working theory here.

I think concentrating on the power management is a reasonable theory.

If the power management is the issue, then the dropouts should occur with no devices connected. Can anyone confirm that it still happens with no monitor, or other devices attached (you can't do much about the audio drivers).

I need to sort this out, but I only have access to the hardware during the week.

I have confirmed that this is the bit that makes things work:

Interestingly it is only _one_ device that detaches from the bus (the 17e9:6006 device) which can be confirmed by watching "udevadm monitor".

I couldn't figure out why it was disconnecting. I tried all sorts of other approaches using the power/control interface as suggested, but nothing worked.
I think the runtime PM of the audio output was a crucial part. I have a feeling that the CDC ethernet device might have something to do with it as well in as much as determining exactly _when_ a disconnect will occur.

The way this probably should be dealt with is via the DisplayLinkManager process as there is no kernel module for the display link device. The way this is done seems to just access USB data via the usbdevfs interface. I'm not sure if there is a way to stop the runtime PM stuff through that interface, but the DisplayLinkManager binary blob people should work on getting this fixed as nobody else can work on it (by design). Having audio output constantly on is a _hack_ and shouldn't be the way to rely on keeping the USB link up. Perhaps there is a less power intensive hack to achieve the same result.

Indeed this workaround works solely.

Not sure if this is DL bug or PA bug and where to submit it.

Definitely a displaylink bug. Runtime power management should suspend things when they aren't in use, which includes the entire tree of USB devices, so the kernel is working exactly as intended. The way the displaylink part uses a userspace driver works is a bit odd and issues like this are more likely to occur. Forcing the audio driver to never suspend is just a workaround (and a waste of power).

Worked For Linux Mint 18.3
 

I am running Linux Mint 18.3 (Ubuntu 16.04). I was also having the same problem with the D6000 "crashing" periodically. I can confirm that the modification to the pulse default settings fixed this issue for me. Thanks for finding that and sharing it.

No Display once unplugged from Dock
 

As Part of Laptop refresh we upgraded to Dell Latitude 7280 and 7480 with D6000 Dock.
The issue reported by few users were display goes blank after un-docking the Laptop and also once we place this back to dock also it will not give any display to monitors.
Only solution is manually shutdown and start again.

Any solutions to this very much appreciated.

Thanks
Akhil

Wrong Hardware ids d6000
 

Someone please give me the Hardware Ids of dell d6000 ...Vid & Pid
My device showing wrong ids
Any solution if someone face similar case ?

Turning wifi off appears to fix the issue
 

I'm using a Dell XPS 13 9370 with a D6000 dock on Ubuntu 18.04.2 LTS and was suffering from the dock resetting every few hours. turning off the wifi seams to have stopped this happening.

this is the thread that lead me to try that
https://plugable.com/2016/06/30/inve...ision-laptops/

good luck!