4

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 :)

Other details:

  • 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.

EDIT1:

  • 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 lsusb show up, but then they go away after several seconds (although it almost appears as though they go away specifically because I am invoking lsusb several times...not sure how to test this hypothesis though).
  • The output of lsusb -t is 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 lsusb several 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)?

EDIT2:

  • Here are the last several lines of dmesg after 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.

  • 1
    Small reminder: 17.10 will lose support sometime this month, so an upgrade to 18.04 is recommended in the near future (18.04 will be supported until April 2023 since it's LTS). – Chai T. Rex Jul 6 '18 at 3:39
  • You can also use lsusb -t for a visual representation of the USB tree. – WinEunuuchs2Unix Jul 7 '18 at 20:05
  • @ChaiT.Rex I upgraded to 18.04 two days ago and so far the issue actually seems (maybe) to be resolved. In each boot so far, the extra usb buses show up at first, then disappear after a few seconds. – Daniel Hathcock Jul 8 '18 at 21:19
  • 1
    @DanielHathcock USB-C is a connector size/format. It's also used by Thunderbolt which is 20 Gbit/s and 40 Gbit/s. You mean USB 3.1 which is 10 Gbit/s: google.com/… It's just that your USB 3.1 might have a Type-C connector instead of Type-A connector. Or something like that. It's a confusing area... – WinEunuuchs2Unix Jul 8 '18 at 23:42
  • 1
    anything in dmesg when the buses are disappearing? – Sebastian Stark Jul 10 '18 at 16:33
0

Upgrading to Ubuntu 18.04 fixed the issue I was having (credit to @ChaiT.Rex for the suggestion to upgrade).

I am not sure why this worked however, and would still be interested if someone is able to shed any light on the situation...hence I am not marking this answer as accepted since it is insufficient (yet still useful to other people who have the same issue).

0

It was driving me crazy as well, but as you said, upgrading to 18.04 fixed everything and now I can close the lid knowing that the PC is actually going to sleep every time without having to check the power light. I think upgrading to 18.04 is the only solution then.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.