On Tue, Jan 30, 2018 at 5:54 PM, Theo de Raadt <dera...@openbsd.org> wrote: > Is that a pure USB dock, or is it something else? Does it connect with > a pure USB connector?
I'm not sure what "pure" means. It is a box with one female USB-C, HDMI, USB-A plug each, and it has a cable with a male USB-C plug that goes into the laptop. Here is a picture: https://gzhls.at/i/28/61/1552861-n0.jpg This is how it manifests itself when plugged in: uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs, Inc. USB2.0 Hub" rev 2.10/6.80 addr 5 uhub2 at uhub0 port 13 configuration 1 interface 0 "VIA Labs, Inc. USB3.0 Hub" rev 3.00/6.85 addr 6 ugen2 at uhub1 port 2 "VIA Technologies Inc. USB 2.0 BILLBOARD" rev 2.01/3.04 addr 7 (The addr numbers and the uhub/ugen numbers vary each time it is plugged in.) > Maybe the resume-side EFI/ACPI/SMI makes assumptions about it? > > At suspend time, we 'kick off' all devices which we suspect aren't > "part of the machine". That's so that upon resume, we aren't touching > their registers or otherwise expecting them to work. The "suspect" > part includes downstream usb hubs. It looks like uhub0 ("Intel xHCI root hub") is not among the devices being kicked off during bad suspends (with the dock)... apmd: system suspending /bsd: ugen0 detached /bsd: uhub1 detached /bsd: video0 detached /bsd: uvideo0 detached /bsd: ugen1 detached /bsd: ugen2 detached /bsd: uhub2 detached [unable to resume] ...on the other hand, during the good suspends (without the dock) uhub0 *is* detached: apmd: system suspending /bsd: video0 detached /bsd: uvideo0 detached /bsd: ugen0 detached /bsd: ugen1 detached /bsd: uhub0 detached /bsd: uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 apmd: system resumed from sleep Also, upon further testing there was one instance where resume *did* work with the dock. The glaring difference is that uhub0 *was* being detached: apmd: system suspending /bsd: ugen2 detached /bsd: uhub1 detached /bsd: video0 detached /bsd: uvideo0 detached /bsd: ugen0 detached /bsd: ugen1 detached /bsd: uhub2 detached /bsd: uhub0 detached /bsd: uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 apmd: system resumed from sleep /bsd: uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs, Inc. USB2.0 Hub" rev 2.10/6.80 addr 2 /bsd: ugen0 at uhub1 port 2 "VIA Technologies Inc. USB 2.0 BILLBOARD" rev 2.01/3.04 addr 3 /bsd: uvideo0 at uhub0 port 5 configuration 1 interface 0 "AzureWave USB2.0 VGA UVC WebCam" rev 2.00/16.09 addr 4 /bsd: video0 at uvideo0 /bsd: ugen1 at uhub0 port 8 "Intel Bluetooth" rev 2.00/0.01 addr 5 /bsd: ugen2 at uhub0 port 9 "ELAN ELAN:Fingerprint" rev 2.00/1.35 addr 6 /bsd: uhub2 at uhub0 port 13 configuration 1 interface 0 "VIA Labs, Inc. USB3.0 Hub" rev 3.00/6.85 addr 7 > There are a few people who can debug this. It is quite hard to debug > without having a machine on the desk. Something about have non-working > hardware makes Mike and I and others figure out a strategy for determining > where it is locking up. Providing a list of approaches is too hard. Not quite sure I got the point, but am more than happy to help in any way I can. Also, this might be related: https://marc.info/?l=openbsd-bugs&m=151730049020517 Thanks!
