This is a multipart MIME message.

--==_Exmh_41729123180800
Content-Type: text/plain; charset=us-ascii


There might be a problem with my new code temporarily disabling
status change notifications. A real hub does resend status change
packets until it gets an acknowledge (which would be a "clear
feature" request). The root hub emulation for ehci doesn't do
that correctly, so that status changes might get lost.
I particulary suspect the connect/disconnect sequence which happens
if a device is handed over to a companion controller. Whether
this strikes might depend on timing details and whether the
port in question is among the first or last probed on the hub.
Can you try the appended patch?

best regards
Matthias



--==_Exmh_41729123180800
Content-Type: text/plain ; name="uhub.txt"; charset=us-ascii
Content-Description: uhub.txt
Content-Disposition: attachment; filename="uhub.txt"

# 
# old_revision [20ed559b977f914432de685d7cfcfdf6cb8065b9]
# 
# patch "sys/dev/usb/uhub.c"
#  from [5d3d36e84fc89f85438d0504fe587fddbe54af0e]
#    to [4053dcc0338938487c508c5d260f14690055a1a9]
# 
============================================================
--- sys/dev/usb/uhub.c	5d3d36e84fc89f85438d0504fe587fddbe54af0e
+++ sys/dev/usb/uhub.c	4053dcc0338938487c508c5d260f14690055a1a9
@@ -674,6 +674,15 @@ uhub_intr(usbd_xfer_handle xfer, usbd_pr
 		sc->sc_explorepending = 1;
 		usb_needs_explore(sc->sc_hub);
 	}
+	/*
+	 * XXX workaround for broken implementation of the interrupt
+	 * pipe in EHCI root hub emulation which doesn't resend
+	 * status change notifications until handled: force a rescan
+	 * of the ports we touched in the last run
+	 */
+	if (status == USBD_NORMAL_COMPLETION && sc->sc_explorepending &&
+      !strcmp(sc->sc_dev.dv_parent->dv_parent->dv_cfdriver->cd_name, "ehci"))
+		usb_needs_explore(sc->sc_hub);
 }
 
 #if defined(__FreeBSD__)

--==_Exmh_41729123180800--