Re: Resume fails with connected USB hub

[Maximilian Pichler]

On Mon, Jan 29, 2018 at 6:43 PM, Maximilian Pichler
 wrote:
> Resume after suspend fails on a Zenbook UX390UA if (and only if) the
> USB hub/adapter that comes with it is connected.

This issue no longer occurs with current from Jun 21st. I don't know
which change (since Jan 24) is responsible.

Re: Resume fails with connected USB hub

[Maximilian Pichler]

On Wed, Jan 31, 2018 at 1:15 PM, Eric Furman  wrote:
> What he is saying is that for this to be properly fixed he needs to have
> actual possession of one of these machines. Some one needs to donate
> one so they can fix the problem.

Unfortunately I currently don't have that option.

On the other hand I added a bunch of printf's to the kernel and am
observing the following: with the hub plugged in, upon suspend the
system consistently
gets stuck in a call to 'tsleep' in 'xhci_command_submit':

error = tsleep(>sc_cmd_trb, PZERO, "xhcicmd",
(timeout*hz+999)/ 1000 + 1);

More precisely, after a hard power down the last entry in
/var/messages/log from before reboot is the output of a printf
immediately before this line of code. The output of a printf
immediately after it is missing.

The call stack is:
tsleep (with timo=51)
xhci_command_submit
xhci_cmd_slot_control
xhci_pipe_close  (called via 'pipe->methods->close')
usbd_close_pipe
usb_free_device
usbd_detach (with dev->address = 7)
[...]
acpi_sleep_state

address 7 presumably refers to the hub:
uhub2 at uhub0 port 13 configuration 1 interface 0 "VIA Labs, Inc.
USB3.0 Hub" rev 3.00/6.85 addr 7

Is this information of any use?

Re: Resume fails with connected USB hub

[Eric Furman]

On Tue, Jan 30, 2018, at 8:56 PM, Maximilian Pichler wrote:
> On Tue, Jan 30, 2018 at 5:54 PM, Theo de Raadt  wrote:
> > 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.

What he is saying is that for this to be properly fixed he needs to have
actual possession of one of these machines. Some one needs to donate
one so they can fix the problem. 

Re: Resume fails with connected USB hub

[Maximilian Pichler]

On Tue, Jan 30, 2018 at 5:54 PM, Theo de Raadt  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=151730049020517

Thanks!

Re: Resume fails with connected USB hub

[Theo de Raadt]

> Resume after suspend fails on a Zenbook UX390UA if (and only if) the
> USB hub/adapter that comes with it is connected.

Is that a pure USB dock, or is it something else?  Does it connect with
a pure USB connector?

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.

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.