Re: urtwn timeout and system freez
On 09/03/15(Mon) 22:46, Remi Locherer wrote: > On Mon, Mar 09, 2015 at 11:31:56AM +0100, Martin Pieuchot wrote: > > On 07/03/15(Sat) 14:13, Remi Locherer wrote: > > > On Fri, Mar 06, 2015 at 11:24:27PM +0100, Martin Pieuchot wrote: > > > > [...] > > > > Could you tell me if the diff below fixes your issue? > > > > > > I built a kernel with this diff and the diff from Stefan applied on a > > > cvs checkout from yesterday. I could provoke an urtwn0 timeout with > > > running > > > speedtest-cli. > > > > > > * TX status and page fault trap: > > > https://relo.ch/urtwn_freeze/IMG_20150307_134913.jpg > > > * trace cpu 2,0,1,3: > > > https://relo.ch/urtwn_freeze/IMG_20150307_135150.jpg > > > > > > I tested the same with urtwn plugged to the xhci port. The timeout also > > > happens but I can unplug the device without the system dropping to ddb. > > > > Thanks Remi, the problem is that when a pipe is aborted the stack call > > the corresponding *_abort() function even if the transfer has not yet > > been transfered. In this case it is not in the list of pending transfer > > and we should not try to remove it. > > > > Updated diff below to apply on top of a -current checkout. > > This diff fixes the issue for me. I can now remove the urtwn device > once the "urtwn0 timeout" happens and the system continuous to work. Thanks for testing, I've sent this diff with a fix for suspend/resume to tech@ for review.
Re: urtwn timeout and system freez
On Mon, Mar 09, 2015 at 11:31:56AM +0100, Martin Pieuchot wrote: > On 07/03/15(Sat) 14:13, Remi Locherer wrote: > > On Fri, Mar 06, 2015 at 11:24:27PM +0100, Martin Pieuchot wrote: > > > [...] > > > Could you tell me if the diff below fixes your issue? > > > > I built a kernel with this diff and the diff from Stefan applied on a > > cvs checkout from yesterday. I could provoke an urtwn0 timeout with running > > speedtest-cli. > > > > * TX status and page fault trap: > > https://relo.ch/urtwn_freeze/IMG_20150307_134913.jpg > > * trace cpu 2,0,1,3: > > https://relo.ch/urtwn_freeze/IMG_20150307_135150.jpg > > > > I tested the same with urtwn plugged to the xhci port. The timeout also > > happens but I can unplug the device without the system dropping to ddb. > > Thanks Remi, the problem is that when a pipe is aborted the stack call > the corresponding *_abort() function even if the transfer has not yet > been transfered. In this case it is not in the list of pending transfer > and we should not try to remove it. > > Updated diff below to apply on top of a -current checkout. This diff fixes the issue for me. I can now remove the urtwn device once the "urtwn0 timeout" happens and the system continuous to work. Remi
Re: urtwn timeout and system freez
On 07/03/15(Sat) 14:13, Remi Locherer wrote:
> On Fri, Mar 06, 2015 at 11:24:27PM +0100, Martin Pieuchot wrote:
> > [...]
> > Could you tell me if the diff below fixes your issue?
>
> I built a kernel with this diff and the diff from Stefan applied on a
> cvs checkout from yesterday. I could provoke an urtwn0 timeout with running
> speedtest-cli.
>
> * TX status and page fault trap:
> https://relo.ch/urtwn_freeze/IMG_20150307_134913.jpg
> * trace cpu 2,0,1,3:
> https://relo.ch/urtwn_freeze/IMG_20150307_135150.jpg
>
> I tested the same with urtwn plugged to the xhci port. The timeout also
> happens but I can unplug the device without the system dropping to ddb.
Thanks Remi, the problem is that when a pipe is aborted the stack call
the corresponding *_abort() function even if the transfer has not yet
been transfered. In this case it is not in the list of pending transfer
and we should not try to remove it.
Updated diff below to apply on top of a -current checkout.
Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.176
diff -u -p -r1.176 ehci.c
--- ehci.c 6 Mar 2015 22:53:03 - 1.176
+++ ehci.c 9 Mar 2015 10:23:24 -
@@ -206,11 +206,7 @@ void ehci_dump_exfer(struct ehci_xfer *
#define ehci_add_intr_list(sc, ex) \
TAILQ_INSERT_TAIL(&(sc)->sc_intrhead, (ex), inext);
#define ehci_del_intr_list(sc, ex) \
- do { \
- TAILQ_REMOVE(&sc->sc_intrhead, (ex), inext); \
- (ex)->inext.tqe_prev = NULL; \
- } while (0)
-#define ehci_active_intr_list(ex) ((ex)->inext.tqe_prev != NULL)
+ TAILQ_REMOVE(&(sc)->sc_intrhead, (ex), inext);
struct usbd_bus_methods ehci_bus_methods = {
.open_pipe = ehci_open,
@@ -753,6 +749,7 @@ ehci_check_qh_intr(struct ehci_softc *sc
}
done:
DPRINTFN(12, ("ehci_check_intr: ex=%p done\n", ex));
+ ehci_del_intr_list(sc, ex);
timeout_del(&xfer->timeout_handle);
usb_rem_task(xfer->pipe->device, &xfer->abort_task);
ehci_idone(xfer);
@@ -803,6 +800,7 @@ ehci_check_itd_intr(struct ehci_softc *s
return;
done:
DPRINTFN(12, ("ehci_check_itd_intr: ex=%p done\n", ex));
+ ehci_del_intr_list(sc, ex);
timeout_del(&xfer->timeout_handle);
usb_rem_task(xfer->pipe->device, &xfer->abort_task);
ehci_idone(xfer);
@@ -2718,8 +2716,7 @@ ehci_abort_xfer(struct usbd_xfer *xfer,
DPRINTF(("ehci_abort_xfer: xfer=%p pipe=%p\n", xfer, epipe));
- if (sc->sc_bus.dying) {
- /* If we're dying, just do the software part. */
+ if (sc->sc_bus.dying || xfer->status == USBD_NOT_STARTED) {
s = splusb();
xfer->status = status; /* make software ignore it */
timeout_del(&xfer->timeout_handle);
@@ -2732,6 +2729,12 @@ ehci_abort_xfer(struct usbd_xfer *xfer,
return;
}
+ /* Transfer is already done. */
+ if (xfer->status != USBD_IN_PROGRESS) {
+ DPRINTF(("%s: already done \n", __func__));
+ return;
+ }
+
if (xfer->device->bus->intr_context)
panic("ehci_abort_xfer: not in process context");
@@ -2759,6 +2762,7 @@ ehci_abort_xfer(struct usbd_xfer *xfer,
s = splusb();
ex->ehci_xfer_flags |= EHCI_XFER_ABORTING;
xfer->status = status; /* make software ignore it */
+ ehci_del_intr_list(sc, ex);
timeout_del(&xfer->timeout_handle);
usb_rem_task(xfer->device, &xfer->abort_task);
splx(s);
@@ -2827,7 +2831,7 @@ ehci_abort_isoc_xfer(struct usbd_xfer *x
DPRINTF(("ehci_abort_isoc_xfer: xfer %p pipe %p\n", xfer, xfer->pipe));
- if (sc->sc_bus.dying) {
+ if (sc->sc_bus.dying || xfer->status == USBD_NOT_STARTED) {
s = splusb();
xfer->status = status;
timeout_del(&xfer->timeout_handle);
@@ -2837,6 +2841,12 @@ ehci_abort_isoc_xfer(struct usbd_xfer *x
return;
}
+ /* Transfer is already done. */
+ if (xfer->status != USBD_IN_PROGRESS) {
+ DPRINTF(("%s: already done \n", __func__));
+ return;
+ }
+
if (ex->ehci_xfer_flags & EHCI_XFER_ABORTING) {
DPRINTFN(2, ("ehci_abort_isoc_xfer: already aborting\n"));
@@ -2852,9 +2862,10 @@ ehci_abort_isoc_xfer(struct usbd_xfer *x
tsleep(&ex->ehci_xfer_flags, PZERO, "ehciiaw", 0);
return;
}
- ex->ehci_xfer_flags |= EHCI_XFER_ABORTING;
+ ex->ehci_xfer_flags |= EHCI_XFER_ABORTING;
xfer->status = status;
+ ehci_del_intr_list(sc, ex);
timeout_del(&xfer->timeout_handle);
usb_rem_task(xfer->device, &xfer->abort_task);
@@ -2998,8 +3009,7 @@ ehci_device_ctrl_done(struct usbd_xfer *
}
#endif
- if (xfer->status != USBD_NOMEM && ehc
Re: urtwn timeout and system freez
On Fri, Mar 06, 2015 at 11:24:27PM +0100, Martin Pieuchot wrote: > On 06/03/15(Fri) 22:06, Remi Locherer wrote: > > On Fri, Mar 06, 2015 at 09:15:23AM +0100, Stefan Sperling wrote: > > > On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote: > > > > Hi, > > > > > > > > Since about fall 2014 I see "urtwn0 timeout" every now an then like > > > > others that reported it. An unplug and replut of the urtwn device > > > > usually helped. > > > > > > > > But with the snapshots from March 1st and 3rd the system just freezes > > > > when I unplug the urtwn device after I see the timeout message in > > > > xconsole. The system just freezes and does not drop to ddb. > > > > > > > > With the snapshot from February 20 I did not observe these freezes. > > > > > > > > Outputs of lsusb -v and dmesg below. > > > > > > > > Remi > > > > > > > > > > Hi Remi, > > > > > > I've discussed this with mpi. We're unsure what's going on exactly. > > > > > > Can you please really make sure you're not dropping into ddb (i.e. > > > don't detach the device while in X, but when on console)? > > > > Your assumption is right! Switching from X to console _before_ unplugging > > the urtwn device gives me an ddb promt. I made photos from trace and ps: > > > > * page fault trap: https://relo.ch/urtwn_freeze/IMG_20150306_184105.jpg > > * trace cpu 0 - 3: https://relo.ch/urtwn_freeze/IMG_20150306_192412.jpg > > * ps part 1: https://relo.ch/urtwn_freeze/IMG_20150306_192537.jpg > > * ps part 2: https://relo.ch/urtwn_freeze/IMG_20150306_192708.jpg > > It looks like we're trying to remove a transfer from the list of pending > xfers when it has not yet been added to it. > > Could you tell me if the diff below fixes your issue? I built a kernel with this diff and the diff from Stefan applied on a cvs checkout from yesterday. I could provoke an urtwn0 timeout with running speedtest-cli. * TX status and page fault trap: https://relo.ch/urtwn_freeze/IMG_20150307_134913.jpg * trace cpu 2,0,1,3: https://relo.ch/urtwn_freeze/IMG_20150307_135150.jpg I tested the same with urtwn plugged to the xhci port. The timeout also happens but I can unplug the device without the system dropping to ddb.
Re: urtwn timeout and system freez
On 06/03/15(Fri) 22:06, Remi Locherer wrote:
> On Fri, Mar 06, 2015 at 09:15:23AM +0100, Stefan Sperling wrote:
> > On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote:
> > > Hi,
> > >
> > > Since about fall 2014 I see "urtwn0 timeout" every now an then like
> > > others that reported it. An unplug and replut of the urtwn device
> > > usually helped.
> > >
> > > But with the snapshots from March 1st and 3rd the system just freezes
> > > when I unplug the urtwn device after I see the timeout message in
> > > xconsole. The system just freezes and does not drop to ddb.
> > >
> > > With the snapshot from February 20 I did not observe these freezes.
> > >
> > > Outputs of lsusb -v and dmesg below.
> > >
> > > Remi
> > >
> >
> > Hi Remi,
> >
> > I've discussed this with mpi. We're unsure what's going on exactly.
> >
> > Can you please really make sure you're not dropping into ddb (i.e.
> > don't detach the device while in X, but when on console)?
>
> Your assumption is right! Switching from X to console _before_ unplugging
> the urtwn device gives me an ddb promt. I made photos from trace and ps:
>
> * page fault trap: https://relo.ch/urtwn_freeze/IMG_20150306_184105.jpg
> * trace cpu 0 - 3: https://relo.ch/urtwn_freeze/IMG_20150306_192412.jpg
> * ps part 1: https://relo.ch/urtwn_freeze/IMG_20150306_192537.jpg
> * ps part 2: https://relo.ch/urtwn_freeze/IMG_20150306_192708.jpg
It looks like we're trying to remove a transfer from the list of pending
xfers when it has not yet been added to it.
Could you tell me if the diff below fixes your issue?
Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.175
diff -u -p -r1.175 ehci.c
--- ehci.c 28 Feb 2015 09:22:59 - 1.175
+++ ehci.c 6 Mar 2015 22:21:28 -
@@ -2716,7 +2716,7 @@ ehci_abort_xfer(struct usbd_xfer *xfer,
DPRINTF(("ehci_abort_xfer: xfer=%p pipe=%p\n", xfer, epipe));
- if (sc->sc_bus.dying) {
+ if (sc->sc_bus.dying || xfer->status == USBD_NOT_STARTED) {
/* If we're dying, just do the software part. */
s = splusb();
xfer->status = status; /* make software ignore it */
@@ -2728,6 +2728,12 @@ ehci_abort_xfer(struct usbd_xfer *xfer,
#endif
usb_transfer_complete(xfer);
splx(s);
+ return;
+ }
+
+ /* Transfer is already done. */
+ if (xfer->status != USBD_IN_PROGRESS) {
+ DPRINTF(("%s: already done \n", __func__));
return;
}
Re: urtwn timeout and system freez
On Fri, Mar 06, 2015 at 09:15:23AM +0100, Stefan Sperling wrote:
> On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote:
> > Hi,
> >
> > Since about fall 2014 I see "urtwn0 timeout" every now an then like
> > others that reported it. An unplug and replut of the urtwn device
> > usually helped.
> >
> > But with the snapshots from March 1st and 3rd the system just freezes
> > when I unplug the urtwn device after I see the timeout message in
> > xconsole. The system just freezes and does not drop to ddb.
> >
> > With the snapshot from February 20 I did not observe these freezes.
> >
> > Outputs of lsusb -v and dmesg below.
> >
> > Remi
> >
>
> Hi Remi,
>
> I've discussed this with mpi. We're unsure what's going on exactly.
>
> Can you please really make sure you're not dropping into ddb (i.e.
> don't detach the device while in X, but when on console)?
Your assumption is right! Switching from X to console _before_ unplugging
the urtwn device gives me an ddb promt. I made photos from trace and ps:
* page fault trap: https://relo.ch/urtwn_freeze/IMG_20150306_184105.jpg
* trace cpu 0 - 3: https://relo.ch/urtwn_freeze/IMG_20150306_192412.jpg
* ps part 1: https://relo.ch/urtwn_freeze/IMG_20150306_192537.jpg
* ps part 2: https://relo.ch/urtwn_freeze/IMG_20150306_192708.jpg
I'll apply the below diff and report back with the results.
> Can you please apply this diff and let us know if you see any STATUS=?
> lines with it when the problem happens (again, console, not X)?
>
> Thanks.
>
> Index: if_urtwn.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 if_urtwn.c
> --- if_urtwn.c10 Feb 2015 23:25:46 - 1.42
> +++ if_urtwn.c6 Mar 2015 08:12:23 -
> @@ -1635,7 +1635,7 @@ urtwn_rxeof(struct usbd_xfer *xfer, void
> int len, totlen, pktlen, infosz, npkts;
>
> if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
> - DPRINTF(("RX status=%d\n", status));
> + printf("RX status=%d\n", status);
> if (status == USBD_STALLED)
> usbd_clear_endpoint_stall_async(sc->rx_pipe);
> if (status != USBD_CANCELLED)
> @@ -1703,7 +1703,7 @@ urtwn_txeof(struct usbd_xfer *xfer, void
> TAILQ_INSERT_TAIL(&sc->tx_free_list, data, next);
>
> if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
> - DPRINTF(("TX status=%d\n", status));
> + printf("TX status=%d\n", status);
> if (status == USBD_STALLED)
> usbd_clear_endpoint_stall_async(data->pipe);
> ifp->if_oerrors++;
>
Re: urtwn timeout and system freez
On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote:
> Hi,
>
> Since about fall 2014 I see "urtwn0 timeout" every now an then like
> others that reported it. An unplug and replut of the urtwn device
> usually helped.
>
> But with the snapshots from March 1st and 3rd the system just freezes
> when I unplug the urtwn device after I see the timeout message in
> xconsole. The system just freezes and does not drop to ddb.
>
> With the snapshot from February 20 I did not observe these freezes.
>
> Outputs of lsusb -v and dmesg below.
>
> Remi
>
Hi Remi,
I've discussed this with mpi. We're unsure what's going on exactly.
Can you please really make sure you're not dropping into ddb (i.e.
don't detach the device while in X, but when on console)?
Can you please apply this diff and let us know if you see any STATUS=?
lines with it when the problem happens (again, console, not X)?
Thanks.
Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.42
diff -u -p -r1.42 if_urtwn.c
--- if_urtwn.c 10 Feb 2015 23:25:46 - 1.42
+++ if_urtwn.c 6 Mar 2015 08:12:23 -
@@ -1635,7 +1635,7 @@ urtwn_rxeof(struct usbd_xfer *xfer, void
int len, totlen, pktlen, infosz, npkts;
if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
- DPRINTF(("RX status=%d\n", status));
+ printf("RX status=%d\n", status);
if (status == USBD_STALLED)
usbd_clear_endpoint_stall_async(sc->rx_pipe);
if (status != USBD_CANCELLED)
@@ -1703,7 +1703,7 @@ urtwn_txeof(struct usbd_xfer *xfer, void
TAILQ_INSERT_TAIL(&sc->tx_free_list, data, next);
if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
- DPRINTF(("TX status=%d\n", status));
+ printf("TX status=%d\n", status);
if (status == USBD_STALLED)
usbd_clear_endpoint_stall_async(data->pipe);
ifp->if_oerrors++;
Re: urtwn timeout and system freez
I confirm. I have the same issue. On Fri, Mar 6, 2015 at 10:45 AM, Remi Locherer wrote: > Hi, > > Since about fall 2014 I see "urtwn0 timeout" every now an then like > others that reported it. An unplug and replut of the urtwn device > usually helped. > > But with the snapshots from March 1st and 3rd the system just freezes > when I unplug the urtwn device after I see the timeout message in > xconsole. The system just freezes and does not drop to ddb. > > With the snapshot from February 20 I did not observe these freezes. > > Outputs of lsusb -v and dmesg below. > > Remi > > > Bus 000 Device 001: ID 1912: > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 3.00 > bDeviceClass9 Hub > bDeviceSubClass 0 Unused > bDeviceProtocol 1 Single TT > bMaxPacketSize0 9 > idVendor 0x1912 > idProduct 0x > bcdDevice1.00 > iManufacturer 1 Renesas > iProduct2 xHCI root hub > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 25 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x40 > (Missing must-be-set bit!) > Self Powered > MaxPower0mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 9 Hub > bInterfaceSubClass 0 Unused > bInterfaceProtocol 0 Full speed (or root) hub > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0002 1x 2 bytes > bInterval 255 > Hub Descriptor: > bLength 13 > bDescriptorType 42 > nNbrPorts 4 > wHubCharacteristic 0x > Ganged power switching > Ganged overcurrent protection > TT think time 8 FS bits > bPwrOn2PwrGood 10 * 2 milli seconds > bHubContrCurrent 0 milli Ampere > DeviceRemovable0x00 > PortPwrCtrlMask0x00 > Hub Port Status: >Port 1: .0900 Unknown Speed Recovery >Port 2: .0900 Unknown Speed Recovery >Port 3: .0900 Unknown Speed Recovery >Port 4: .0900 Unknown Speed Recovery > Device Status: 0x0001 > Self Powered > > Bus 001 Device 001: ID 8086: Intel Corp. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass9 Hub > bDeviceSubClass 0 Unused > bDeviceProtocol 1 Single TT > bMaxPacketSize064 > idVendor 0x8086 Intel Corp. > idProduct 0x > bcdDevice1.00 > iManufacturer 1 Intel > iProduct2 EHCI root hub > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 25 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x40 > (Missing must-be-set bit!) > Self Powered > MaxPower0mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 9 Hub > bInterfaceSubClass 0 Unused > bInterfaceProtocol 0 Full speed (or root) hub > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 12 > Hub Descriptor: > bLength 10 > bDescriptorType 41 > nNbrPorts 3 > wHubCharacteristic 0x0002 > No power switching (usb 1.0) > Ganged overcurrent protection > TT think time 8 FS bits > bPwrOn2PwrGood 200 * 2 milli seconds > bHubContrCurrent 0 milli Ampere > DeviceRemovable0x00 > PortPwrCtrlMask0x00 > Hub Port Status: >Port 1: .0503 highspeed power enable connect >Port 2: .0500 highspeed power >Port 3: .0500
urtwn timeout and system freez
Hi, Since about fall 2014 I see "urtwn0 timeout" every now an then like others that reported it. An unplug and replut of the urtwn device usually helped. But with the snapshots from March 1st and 3rd the system just freezes when I unplug the urtwn device after I see the timeout message in xconsole. The system just freezes and does not drop to ddb. With the snapshot from February 20 I did not observe these freezes. Outputs of lsusb -v and dmesg below. Remi Bus 000 Device 001: ID 1912: Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 9 idVendor 0x1912 idProduct 0x bcdDevice1.00 iManufacturer 1 Renesas iProduct2 xHCI root hub iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 (Missing must-be-set bit!) Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 13 bDescriptorType 42 nNbrPorts 4 wHubCharacteristic 0x Ganged power switching Ganged overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0x00 Hub Port Status: Port 1: .0900 Unknown Speed Recovery Port 2: .0900 Unknown Speed Recovery Port 3: .0900 Unknown Speed Recovery Port 4: .0900 Unknown Speed Recovery Device Status: 0x0001 Self Powered Bus 001 Device 001: ID 8086: Intel Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize064 idVendor 0x8086 Intel Corp. idProduct 0x bcdDevice1.00 iManufacturer 1 Intel iProduct2 EHCI root hub iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 (Missing must-be-set bit!) Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 12 Hub Descriptor: bLength 10 bDescriptorType 41 nNbrPorts 3 wHubCharacteristic 0x0002 No power switching (usb 1.0) Ganged overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 200 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0x00 Hub Port Status: Port 1: .0503 highspeed power enable connect Port 2: .0500 highspeed power Port 3: .0500 highspeed power Device Status: 0x0001 Self Powered Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0
