I have a Dell XPS 15 9550 (using the latest BIOS 1.7.0) and am running Ubuntu 17.10 using Wayland (I also have Windows 10 dual booted).
The issue is that sometimes (about half the time) when I boot into Ubuntu, suspend will be completely nonfunctional until I reboot.
To be precise: sometimes when I boot, suspend works without fail (call this a "good boot") until I reboot, while other times it never works (a "bad boot") until a reboot. To me, it appears as if bad boots occur completely randomly (i.e. I can get multiple bad boots in a row, or multiple good boots).
Another important detail is that I have found an indicator which tells me exactly whether I am currently in a good or bad boot (without having to attempt to suspend). I use
lsusb: if two extra lines appear, then it means suspend will fail, otherwise suspend will work. i.e. the following indicates a bad boot:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp. Bus 001 Device 003: ID 0c45:6713 Microdia Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
while a good boot looks like:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp. Bus 001 Device 003: ID 0c45:6713 Microdia Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
This seems quite strange to me, and I don't know what it might mean that extra buses are sometimes showing up on lsusb. The XPS 15 has two usb ports, but both should support USB 3.0, so I'm not sure why a "good boot" shows only one 3.0 hub and one 2.0 hub. Any insight here would be very appreciated!
During a bad boot, if I attempt to suspend, the screen goes black for a few seconds, but then turns back on and simply goes back to the login screen. The system log for a failed suspend is exactly as in this question, but I don't believe my question is a duplicate of this because they seem to have resolved their issues (by trying new BIOS etc, while this did not work for me), and they did not include the details about the extra lines showing up in lsusb, so my situation seems slightly different.
Let me know if any additional information would be useful! Thanks in advance :)
- Sometimes when I boot, if I immediately open up a terminal and try
lsusb, it will look at first as though it is a bad boot. But if I wait a couple seconds and try it again, it changes to look like a good boot. In these cases, suspend works, so it is a good boot. I am not sure why it changes though.
- I have not experienced boot issues when using Windows 10
- In the comments of my response here, someone who was having similar issues suggested that maybe my use of Wayland is the issue.
- I upgrade to Ubuntu 18.04, and in the several boots since then, I have not gotten a bad boot. At the beginning the extra lines from
lsusbshow up, but then they go away after several seconds (although it almost appears as though they go away specifically because I am invoking
lsusbseveral times...not sure how to test this hypothesis though).
The output of
lsusb -tis the following at the beginning of a boot:
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M |__ Port 4: Dev 2, If 1, Class=Vendor Specific Class, Driver=btusb, 12M |__ Port 4: Dev 2, If 2, Class=Vendor Specific Class, Driver=btusb, 12M |__ Port 4: Dev 2, If 0, Class=Vendor Specific Class, Driver=btusb, 12M |__ Port 4: Dev 2, If 3, Class=Application Specific Interface, Driver=, 12M |__ Port 12: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 12: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
And after a few seconds (or after invoking
lsusbseveral times) the first two lines go away. I notice that bus 04 has a bandwidth of 10000M, while bus 02 (which sticks around) has 5000M. Could this mean that the issue is related to my USB C port (since I believe it has a higher bandwidth)?
Here are the last several lines of
dmesgafter a boot and after the two ports disappear:
[ 21.582908] xhci_hcd 0000:3e:00.0: xHCI Host Controller [ 21.582916] xhci_hcd 0000:3e:00.0: new USB bus registered, assigned bus number 3 [ 21.584291] xhci_hcd 0000:3e:00.0: hcc params 0x200077c1 hci version 0x110 quirks 0x00009810 [ 21.584529] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 21.584531] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 21.584533] usb usb3: Product: xHCI Host Controller [ 21.584535] usb usb3: Manufacturer: Linux 4.15.0-23-generic xhci-hcd [ 21.584537] usb usb3: SerialNumber: 0000:3e:00.0 [ 21.586177] hub 3-0:1.0: USB hub found [ 21.586192] hub 3-0:1.0: 2 ports detected [ 21.586333] xhci_hcd 0000:3e:00.0: xHCI Host Controller [ 21.586338] xhci_hcd 0000:3e:00.0: new USB bus registered, assigned bus number 4 [ 21.586342] xhci_hcd 0000:3e:00.0: Host supports USB 3.1 Enhanced SuperSpeed [ 21.587203] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [ 21.587206] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 21.587208] usb usb4: Product: xHCI Host Controller [ 21.587209] usb usb4: Manufacturer: Linux 4.15.0-23-generic xhci-hcd [ 21.587211] usb usb4: SerialNumber: 0000:3e:00.0 [ 21.587508] hub 4-0:1.0: USB hub found [ 21.587518] hub 4-0:1.0: 2 ports detected [ 41.029393] xhci_hcd 0000:3e:00.0: remove, state 4 [ 41.029400] usb usb4: USB disconnect, device number 1 [ 41.029578] xhci_hcd 0000:3e:00.0: USB bus 4 deregistered [ 41.029595] xhci_hcd 0000:3e:00.0: xHCI host controller not responding, assume dead [ 41.029598] xhci_hcd 0000:3e:00.0: remove, state 4 [ 41.029601] usb usb3: USB disconnect, device number 1 [ 41.029716] xhci_hcd 0000:3e:00.0: Host halt failed, -19 [ 41.029718] xhci_hcd 0000:3e:00.0: Host not accessible, reset failed. [ 41.029799] xhci_hcd 0000:3e:00.0: USB bus 3 deregistered [ 41.052307] pcieport 0000:07:02.0: Refused to change power state, currently in D3 [ 41.555108] thunderbolt 0000:08:00.0: stopping RX ring 0 [ 41.555123] thunderbolt 0000:08:00.0: disabling interrupt at register 0x38200 bit 12 (0xffffffff -> 0xffffefff) [ 41.555132] thunderbolt 0000:08:00.0: stopping TX ring 0 [ 41.555140] thunderbolt 0000:08:00.0: disabling interrupt at register 0x38200 bit 0 (0xffffffff -> 0xfffffffe) [ 41.555144] thunderbolt 0000:08:00.0: control channel stopped [ 41.555208] thunderbolt 0000:08:00.0: freeing RX ring 0 [ 41.555217] thunderbolt 0000:08:00.0: freeing TX ring 0 [ 41.555225] thunderbolt 0000:08:00.0: shutdown [ 41.556547] pci_bus 0000:08: busn_res: [bus 08] is released [ 41.556637] pci_bus 0000:09: busn_res: [bus 09-3d] is released [ 41.556815] pci_bus 0000:3e: busn_res: [bus 3e] is released [ 41.556878] pci_bus 0000:07: busn_res: [bus 07-3e] is released
You can see where the regular boot process seems to end (21 seconds). At this point all 4 ports are showing. Then 20 seconds later, the two extra ports get removed.