On Wed, Jan 31, 2018 at 1:15 PM, Eric Furman <[email protected]> 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->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?
