RE: Problem with musb dma packet
> From: Bin Liu [mailto:b-...@ti.com] > On Thu, Oct 06, 2016 at 02:45:30PM +, Andrew Goodbody wrote: > > I am trying to investigate an issue on a TI Sitara CPU, AM3352 with > > the musb USB controller. > > > > The scenario is that a device has been in use and working correctly. > > The device is an Android device and is presenting as an MTP device. > > AM3352 musb is the host or device? Sounds like it is the host. Yes, musb is the host. > > That first session of use is finished and the port is reset but the > > device is not unplugged, so enumeration and configuration starts again > > How this happened? How do you control the host reset the device but not > re-enumerate it? Not what I said. The device is of course re-enumerated after the reset. There can be multiple sessions of use of the device, but these multiple sessions occur without unplugging. Each session starts with a reset and continues as normal from there, but with the Android MTP devices only the first session is successful. > > the next time it is needed. The transfers over EP0 using PIO all > > proceed as expected. The problem is the first bulk packet sent to EP1, > > which also happens to be the first dma packet. USBMON shows this > > packet as being sent. However a hardware analyser does not show this > > packet on the wire and of course there is no ACK either. Looking at > > the debug info from the musb driver I can see the dma being started > > and then the callback being called. MUSB_TXCSR_TXPKTRDY remains set as > > does MUSB_TXCSR_TXFIFONOTEMPTY so nothing else happens. The TXCSR > > register is 0x3403. The code is waiting for MUSB_TXCSR_TXPKTRDY to be > > cleared but that will not happen until an ACK is received. It just > > seems that the controller is not putting the packet onto the wire for > > some reason. > > Sounds to me that the cppi teamdown before/during bus reset was not > complete, so the channels are not in the ready state for next transfers. > > I don't have a better way to debug it, but you have to ensure the teardown > sequence does follow that in the normal device detach. If the issue still > happens, you would have to dump the cppi registers to see why the > channels are in the wrong state. > > > > > This is on 4.5.1. > > > > I would welcome some pointers on how to proceed to debug this or else > > any information on possible applicable errata and workarounds for > > this. > > It is more like software problem to me. > > Good luck. > > Regards, > -Bin. > > > > > Thanks, > > Andrew OK, I did some more digging on this. Firstly I found it also happens in PIO mode. I then put another hub in the chain. This time I see the packet on the wire between the hubs. The packet however never leaves the downstream hub to get to the device. So it looks like the device is somehow blocking the bus and preventing the packet being sent. As this can be caused by multiple different devices, although all Android MTP, and it can also be seen with a RasPi host, the fault looks to be in the Android MTP stack not expecting to be restarted without a complete unplug. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Problem with musb dma packet
Ping. > -Original Message- > > I am trying to investigate an issue on a TI Sitara CPU, AM3352 with the musb > USB controller. > > The scenario is that a device has been in use and working correctly. The > device is an Android device and is presenting as an MTP device. That first > session of use is finished and the port is reset but the device is not > unplugged, so enumeration and configuration starts again the next time it is > needed. The transfers over EP0 using PIO all proceed as expected. The > problem is the first bulk packet sent to EP1, which also happens to be the > first dma packet. USBMON shows this packet as being sent. However a > hardware analyser does not show this packet on the wire and of course > there is no ACK either. Looking at the debug info from the musb driver I can > see the dma being started and then the callback being called. > MUSB_TXCSR_TXPKTRDY remains set as does > MUSB_TXCSR_TXFIFONOTEMPTY so nothing else happens. The TXCSR > register is 0x3403. The code is waiting for MUSB_TXCSR_TXPKTRDY to be > cleared but that will not happen until an ACK is received. It just seems that > the controller is not putting the packet onto the wire for some reason. > > This is on 4.5.1. > > I would welcome some pointers on how to proceed to debug this or else any > information on possible applicable errata and workarounds for this. > > Thanks, > Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with musb dma packet
I am trying to investigate an issue on a TI Sitara CPU, AM3352 with the musb USB controller. The scenario is that a device has been in use and working correctly. The device is an Android device and is presenting as an MTP device. That first session of use is finished and the port is reset but the device is not unplugged, so enumeration and configuration starts again the next time it is needed. The transfers over EP0 using PIO all proceed as expected. The problem is the first bulk packet sent to EP1, which also happens to be the first dma packet. USBMON shows this packet as being sent. However a hardware analyser does not show this packet on the wire and of course there is no ACK either. Looking at the debug info from the musb driver I can see the dma being started and then the callback being called. MUSB_TXCSR_TXPKTRDY remains set as does MUSB_TXCSR_TXFIFONOTEMPTY so nothing else happens. The TXCSR register is 0x3403. The code is waiting for MUSB_TXCSR_TXPKTRDY to be cleared but that will not happen until an ACK is received. It just seems that the controller is not putting the packet onto the wire for some reason. This is on 4.5.1. I would welcome some pointers on how to proceed to debug this or else any information on possible applicable errata and workarounds for this. Thanks, Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: g_serial looses data in direction from device to host
> -Original Message- > Hello, > I am having some difficulties with kernel module Gadget Serial v2.4. > g_serial is used on ARM machine BeagleBone Black with Arch Linux 4.6.3-1 > which is communicating with host PC. I originally reported it here: > bugzilla.kernel.org/show_bug.cgi?id=121441 ... This could be the same issue that I submitted patches for, [1] and [2], and which I believe have been merged into 4.7rc4 Andrew [1] http://marc.info/?l=linux-usb=146407820413474=2 [2] http://marc.info/?l=linux-usb=146407825013486=2
[PATCH V3 2/2] usb: musb: Stop bulk endpoint while queue is rotated
Ensure that the endpoint is stopped by clearing REQPKT before
clearing DATAERR_NAKTIMEOUT before rotating the queue on the
dedicated bulk endpoint.
This addresses an issue where a race could result in the endpoint
receiving data before it was reprogrammed resulting in a warning
about such data from musb_rx_reinit before it was thrown away.
The data thrown away was a valid packet that had been correctly
ACKed which meant the host and device got out of sync.
Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com>
Cc: sta...@vger.kernel.org
---
V3 removed the old comment, moved the new comment in place of the old one
and updated it to better reference the programmers guide
V2 added comment about clearing REQPKT before DATAERR_NAKTIMEOUT
drivers/usb/musb/musb_host.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index e5b6aba..17421d0 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -994,9 +994,15 @@ static void musb_bulk_nak_timeout(struct musb *musb,
struct musb_hw_ep *ep,
if (is_in) {
dma = is_dma_capable() ? ep->rx_channel : NULL;
- /* clear nak timeout bit */
+ /*
+* Need to stop the transaction by clearing REQPKT first
+* then the NAK Timeout bit ref MUSBMHDRC USB 2.0 HIGH-SPEED
+* DUAL-ROLE CONTROLLER Programmer's Guide, section 9.2.2
+*/
rx_csr = musb_readw(epio, MUSB_RXCSR);
rx_csr |= MUSB_RXCSR_H_WZC_BITS;
+ rx_csr &= ~MUSB_RXCSR_H_REQPKT;
+ musb_writew(epio, MUSB_RXCSR, rx_csr);
rx_csr &= ~MUSB_RXCSR_DATAERROR;
musb_writew(epio, MUSB_RXCSR, rx_csr);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/2] usb: musb: Ensure rx reinit occurs for shared_fifo endpoints
shared_fifo endpoints would only get a previous tx state cleared
out, the rx state was only cleared for non shared_fifo endpoints
Change this so that the rx state is cleared for all endpoints.
This addresses an issue that resulted in rx packets being dropped
silently.
Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com>
Cc: sta...@vger.kernel.org
---
V3 no change
V2 removed debugging call
drivers/usb/musb/musb_host.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index b7a02ce..e5b6aba 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -594,14 +594,13 @@ musb_rx_reinit(struct musb *musb, struct musb_qh *qh, u8
epnum)
musb_writew(ep->regs, MUSB_TXCSR, 0);
/* scrub all previous state, clearing toggle */
- } else {
- csr = musb_readw(ep->regs, MUSB_RXCSR);
- if (csr & MUSB_RXCSR_RXPKTRDY)
- WARNING("rx%d, packet/%d ready?\n", ep->epnum,
- musb_readw(ep->regs, MUSB_RXCOUNT));
-
- musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
}
+ csr = musb_readw(ep->regs, MUSB_RXCSR);
+ if (csr & MUSB_RXCSR_RXPKTRDY)
+ WARNING("rx%d, packet/%d ready?\n", ep->epnum,
+ musb_readw(ep->regs, MUSB_RXCOUNT));
+
+ musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
/* target addr and (for multipoint) hub addr/port */
if (musb->is_multipoint) {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
> On 05/23/2016 04:40 PM, Sergei Shtylyov wrote:
>
> >>>> Ensure that the endpoint is stopped by clearing REQPKT before
> >>>> clearing DATAERR_NAKTIMEOUT before rotating the queue on the
> >>>> dedicated bulk endpoint.
> >>>> This addresses an issue where a race could result in the endpoint
> >>>> receiving data before it was reprogrammed resulting in a warning
> >>>> about such data from musb_rx_reinit before it was thrown away.
> >>>> The data thrown away was a valid packet that had been correctly
> >>>> ACKed which meant the host and device got out of sync.
> >>>>
> >>>> Signed-off-by: Andrew Goodbody
> <andrew.goodb...@cambrionix.com>
> >>>> Cc: sta...@vger.kernel.org
> >>>> ---
> >>>> V2 added comment about clearing REQPKT before
> DATAERR_NAKTIMEOUT
> >>>>
> >>>> drivers/usb/musb/musb_host.c | 6 ++
> >>>> 1 file changed, 6 insertions(+)
> >>>>
> >>>> diff --git a/drivers/usb/musb/musb_host.c
> >>>> b/drivers/usb/musb/musb_host.c index 2966596..676cb98 100644
> >>>> --- a/drivers/usb/musb/musb_host.c
> >>>> +++ b/drivers/usb/musb/musb_host.c
> >>>> @@ -997,6 +997,12 @@ static void musb_bulk_nak_timeout(struct
> musb
> >>> *musb, struct musb_hw_ep *ep,
> >>>> /* clear nak timeout bit */
> >>>> rx_csr = musb_readw(epio, MUSB_RXCSR);
> >>>> rx_csr |= MUSB_RXCSR_H_WZC_BITS;
> >>>> +/*
> >>>> + * Need to stop the transaction by clearing REQPKT before
> >>>
> >>> Transcation? Maybe transfer?
> >>
> >> The quote from the TRM is "If the DATAERR_NAKTIMEOUT bit is set, the
> >> controller can be directed either to continue trying this transaction
> >> (until it times out again) by clearing the DATAERR_NAKTIMEOUT bit or
> >> to abort the transaction by clearing REQPKT bit before clearing the
> DATAERR_NAKTIMEOUT bit."
> >> So 'transaction' is correct.
> >
> >OK.
> >
> >>>> + * DATAERR_NAKTIMEOUT ref TRM section 16.3.8.2.2.1.2
> >>>
> >>> Which TRM? Do you understand that the MUSB core is used by
> >>> multiple SoCs?
> >>> I'd recommend referring just to the "abstract" manual or the MUSB
> >>> programmer's guide (section 9.2.2 if you want an exact ref.).
> >
> >> That would be the AM335x Sitara Processors TRM. I don't have the MUSB
> >> programmer's guide, is it available online somewhere?
> >
> >AFAIK, no.
> >
> >> I do not understand what you mean by the "abstract" manual.
> >
> >Just saying "the manual" or "the manuals".
> >
> >> Would you be OK with "ref MUSB Programmer's Guide section 9.2.2"
> >
> >Yes.
>
> The full document name is "MUSBMHDRC USB 2.0 HIGH-SPEED DUAL-ROLE
> CONTROLLER Programmer's Guide".
I moved the comment up to replace the one at the top so the patch now looks
like this
if (is_in) {
dma = is_dma_capable() ? ep->rx_channel : NULL;
- /* clear nak timeout bit */
+ /*
+* Need to stop the transaction by clearing REQPKT first
+* then the NAK Timeout bit ref MUSBMHDRC USB 2.0 HIGH-SPEED
+* DUAL-ROLE CONTROLLER Programmer's Guide, section 9.2.2
+*/
rx_csr = musb_readw(epio, MUSB_RXCSR);
rx_csr |= MUSB_RXCSR_H_WZC_BITS;
+ rx_csr &= ~MUSB_RXCSR_H_REQPKT;
+ musb_writew(epio, MUSB_RXCSR, rx_csr);
rx_csr &= ~MUSB_RXCSR_DATAERROR;
musb_writew(epio, MUSB_RXCSR, rx_csr);
Are you OK with that now?
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] > > Hello. > > On 5/23/2016 3:00 PM, Andrew Goodbody wrote: > > > Ensure that the endpoint is stopped by clearing REQPKT before clearing > > DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk > > endpoint. > > This addresses an issue where a race could result in the endpoint > > receiving data before it was reprogrammed resulting in a warning about > > such data from musb_rx_reinit before it was thrown away. > > The data thrown away was a valid packet that had been correctly ACKed > > which meant the host and device got out of sync. > > > > Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com> > > Cc: sta...@vger.kernel.org > > --- > > V2 added comment about clearing REQPKT before DATAERR_NAKTIMEOUT > > > > drivers/usb/musb/musb_host.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/usb/musb/musb_host.c > > b/drivers/usb/musb/musb_host.c index 2966596..676cb98 100644 > > --- a/drivers/usb/musb/musb_host.c > > +++ b/drivers/usb/musb/musb_host.c > > @@ -997,6 +997,12 @@ static void musb_bulk_nak_timeout(struct musb > *musb, struct musb_hw_ep *ep, > > /* clear nak timeout bit */ > > rx_csr = musb_readw(epio, MUSB_RXCSR); > > rx_csr |= MUSB_RXCSR_H_WZC_BITS; > > + /* > > +* Need to stop the transaction by clearing REQPKT before > > Transcation? Maybe transfer? The quote from the TRM is "If the DATAERR_NAKTIMEOUT bit is set, the controller can be directed either to continue trying this transaction (until it times out again) by clearing the DATAERR_NAKTIMEOUT bit or to abort the transaction by clearing REQPKT bit before clearing the DATAERR_NAKTIMEOUT bit." So 'transaction' is correct. > > +* DATAERR_NAKTIMEOUT ref TRM section 16.3.8.2.2.1.2 > > Which TRM? Do you understand that the MUSB core is used by multiple > SoCs? > I'd recommend referring just to the "abstract" manual or the MUSB > programmer's guide (section 9.2.2 if you want an exact ref.). That would be the AM335x Sitara Processors TRM. I don't have the MUSB programmer's guide, is it available online somewhere? I do not understand what you mean by the "abstract" manual. Would you be OK with "ref MUSB Programmer's Guide section 9.2.2" Andrew > [...] > > MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/2] usb: musb: Ensure rx reinit occurs for shared_fifo endpoints
shared_fifo endpoints would only get a previous tx state cleared
out, the rx state was only cleared for non shared_fifo endpoints
Change this so that the rx state is cleared for all endpoints.
This addresses an issue that resulted in rx packets being dropped
silently.
Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com>
Cc: sta...@vger.kernel.org
---
V2 removed debugging call
drivers/usb/musb/musb_host.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 2f8ad7f..2966596 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -594,14 +594,13 @@ musb_rx_reinit(struct musb *musb, struct musb_qh *qh, u8
epnum)
musb_writew(ep->regs, MUSB_TXCSR, 0);
/* scrub all previous state, clearing toggle */
- } else {
- csr = musb_readw(ep->regs, MUSB_RXCSR);
- if (csr & MUSB_RXCSR_RXPKTRDY)
- WARNING("rx%d, packet/%d ready?\n", ep->epnum,
- musb_readw(ep->regs, MUSB_RXCOUNT));
-
- musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
}
+ csr = musb_readw(ep->regs, MUSB_RXCSR);
+ if (csr & MUSB_RXCSR_RXPKTRDY)
+ WARNING("rx%d, packet/%d ready?\n", ep->epnum,
+ musb_readw(ep->regs, MUSB_RXCOUNT));
+
+ musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
/* target addr and (for multipoint) hub addr/port */
if (musb->is_multipoint) {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/2] usb: musb: Stop bulk endpoint while queue is rotated
Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was reprogrammed resulting in a warning about such data from musb_rx_reinit before it was thrown away. The data thrown away was a valid packet that had been correctly ACKed which meant the host and device got out of sync. Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com> Cc: sta...@vger.kernel.org --- V2 added comment about clearing REQPKT before DATAERR_NAKTIMEOUT drivers/usb/musb/musb_host.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index 2966596..676cb98 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -997,6 +997,12 @@ static void musb_bulk_nak_timeout(struct musb *musb, struct musb_hw_ep *ep, /* clear nak timeout bit */ rx_csr = musb_readw(epio, MUSB_RXCSR); rx_csr |= MUSB_RXCSR_H_WZC_BITS; + /* +* Need to stop the transaction by clearing REQPKT before +* DATAERR_NAKTIMEOUT ref TRM section 16.3.8.2.2.1.2 +*/ + rx_csr &= ~MUSB_RXCSR_H_REQPKT; + musb_writew(epio, MUSB_RXCSR, rx_csr); rx_csr &= ~MUSB_RXCSR_DATAERROR; musb_writew(epio, MUSB_RXCSR, rx_csr); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/2] usb: musb: fix dropped packets
The musb driver can drop rx packets when heavily loaded. These two patches address two issues that can cause this. Both issues arose when an endpoint was reprogrammed. The first patch is a logic bug that resulted in a shared_fifo in rx mode not having its state cleared out. The second patch fixes a race condition caused by not stopping the dedicated endpoint for bulk packets before rotating its queue which allowed a packet to be recieved and then thrown away. V2 added a comment and removed debugging code Andrew Goodbody (2): usb: musb: Ensure rx reinit occurs for shared_fifo endpoints usb: musb: Stop bulk endpoint while queue is rotated drivers/usb/musb/musb_host.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] usb: musb: Stop bulk endpoint while queue is rotated
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] > On 05/20/2016 08:06 PM, Andrew Goodbody wrote: > > >>> Ensure that the endpoint is stopped by clearing REQPKT before > >>> clearing DATAERR_NAKTIMEOUT before rotating the queue on the > >>> dedicated bulk endpoint. > >>> This addresses an issue where a race could result in the endpoint > >>> receiving data before it was reprogrammed resulting in a warning > >>> about such data from musb_rx_reinit before it was thrown away. > >>> The data thrown away was a valid packet that had been correctly > >>> ACKed which meant the host and device got out of sync. > >>> > >>> Signed-off-by: Andrew Goodbody > <andrew.goodb...@cambrionix.com> > >>> Cc: sta...@vger.kernel.org > >>> --- > >>> drivers/usb/musb/musb_host.c | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/drivers/usb/musb/musb_host.c > >>> b/drivers/usb/musb/musb_host.c index 30e0d65..777ff30 100644 > >>> --- a/drivers/usb/musb/musb_host.c > >>> +++ b/drivers/usb/musb/musb_host.c > >>> @@ -999,6 +999,8 @@ static void musb_bulk_nak_timeout(struct musb > >> *musb, struct musb_hw_ep *ep, > >>> /* clear nak timeout bit */ > >>> rx_csr = musb_readw(epio, MUSB_RXCSR); > >>> rx_csr |= MUSB_RXCSR_H_WZC_BITS; > >>> + rx_csr &= ~MUSB_RXCSR_H_REQPKT; > >>> + musb_writew(epio, MUSB_RXCSR, rx_csr); > >>> rx_csr &= ~MUSB_RXCSR_DATAERROR; > >>> musb_writew(epio, MUSB_RXCSR, rx_csr); > >> > >> Can we not clear both in one write? > > > > Section 16.3.8.2.2.1.2 of the TRM says to clear REQPKT before > DATAERR_NAKTIMEOUT. > > Right, the MUSB programmer's guide also says that. Then a comment > wouldn't hurt here. I'll add that for v2, thanks. Andrew > > Andrew > > MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] usb: musb: Stop bulk endpoint while queue is rotated
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] > On 05/20/2016 05:51 PM, Andrew Goodbody wrote: > > > Ensure that the endpoint is stopped by clearing REQPKT before clearing > > DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk > > endpoint. > > This addresses an issue where a race could result in the endpoint > > receiving data before it was reprogrammed resulting in a warning about > > such data from musb_rx_reinit before it was thrown away. > > The data thrown away was a valid packet that had been correctly ACKed > > which meant the host and device got out of sync. > > > > Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com> > > Cc: sta...@vger.kernel.org > > --- > > drivers/usb/musb/musb_host.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/usb/musb/musb_host.c > > b/drivers/usb/musb/musb_host.c index 30e0d65..777ff30 100644 > > --- a/drivers/usb/musb/musb_host.c > > +++ b/drivers/usb/musb/musb_host.c > > @@ -999,6 +999,8 @@ static void musb_bulk_nak_timeout(struct musb > *musb, struct musb_hw_ep *ep, > > /* clear nak timeout bit */ > > rx_csr = musb_readw(epio, MUSB_RXCSR); > > rx_csr |= MUSB_RXCSR_H_WZC_BITS; > > + rx_csr &= ~MUSB_RXCSR_H_REQPKT; > > + musb_writew(epio, MUSB_RXCSR, rx_csr); > > rx_csr &= ~MUSB_RXCSR_DATAERROR; > > musb_writew(epio, MUSB_RXCSR, rx_csr); > > Can we not clear both in one write? Section 16.3.8.2.2.1.2 of the TRM says to clear REQPKT before DATAERR_NAKTIMEOUT. Andrew > [...] > > MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] usb: musb: Ensure rx reinit occurs for shared_fifo endpoints
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
>
> Hello.
>
> On 05/20/2016 05:51 PM, Andrew Goodbody wrote:
>
> > shared_fifo endpoints would only get a previous tx state cleared out,
> > the rx state was only cleared for non shared_fifo endpoints Change
> > this so that the rx state is cleared for all endpoints.
> > This addresses an issue that resulted in rx packets being dropped
> > silently.
> >
> > Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com>
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/usb/musb/musb_host.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/usb/musb/musb_host.c
> > b/drivers/usb/musb/musb_host.c index 2f8ad7f..30e0d65 100644
> > --- a/drivers/usb/musb/musb_host.c
> > +++ b/drivers/usb/musb/musb_host.c
> > @@ -594,14 +594,15 @@ musb_rx_reinit(struct musb *musb, struct
> musb_qh *qh, u8 epnum)
> > musb_writew(ep->regs, MUSB_TXCSR, 0);
> >
> > /* scrub all previous state, clearing toggle */
> > - } else {
> > - csr = musb_readw(ep->regs, MUSB_RXCSR);
> > - if (csr & MUSB_RXCSR_RXPKTRDY)
> > - WARNING("rx%d, packet/%d ready?\n", ep-
> >epnum,
> > - musb_readw(ep->regs, MUSB_RXCOUNT));
> > -
> > - musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
> > }
> > + csr = musb_readw(ep->regs, MUSB_RXCSR);
> > + if (csr & MUSB_RXCSR_RXPKTRDY) {
> > + WARNING("rx%d, packet/%d ready?\n", ep->epnum,
> > + musb_readw(ep->regs, MUSB_RXCOUNT));
> > + urb_qh_dump(musb);
>
> I'm not seeing this function anywhere... debugging leftover?
Sorry, yes, my bad. I'll remove it for v2.
Andrew
> > + }
> > +
> > + musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
> >
> > /* target addr and (for multipoint) hub addr/port */
> > if (musb->is_multipoint) {
>
> MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] usb: musb: fix dropped packets
The musb driver can drop rx packets when heavily loaded. These two patches address two issues that can cause this. Both issues arose when an endpoint was reprogrammed. The first patch is a logic bug that resulted in a shared_fifo in rx mode not having its state cleared out. The second patch fixes a race condition caused by not stopping the dedicated endpoint for bulk packets before rotating its queue which allowed a packet to be recieved and then thrown away. Andrew Goodbody (2): usb: musb: Ensure rx reinit occurs for shared_fifo endpoints usb: musb: Stop bulk endpoint while queue is rotated drivers/usb/musb/musb_host.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: musb: Ensure rx reinit occurs for shared_fifo endpoints
shared_fifo endpoints would only get a previous tx state cleared
out, the rx state was only cleared for non shared_fifo endpoints
Change this so that the rx state is cleared for all endpoints.
This addresses an issue that resulted in rx packets being dropped
silently.
Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com>
Cc: sta...@vger.kernel.org
---
drivers/usb/musb/musb_host.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 2f8ad7f..30e0d65 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -594,14 +594,15 @@ musb_rx_reinit(struct musb *musb, struct musb_qh *qh, u8
epnum)
musb_writew(ep->regs, MUSB_TXCSR, 0);
/* scrub all previous state, clearing toggle */
- } else {
- csr = musb_readw(ep->regs, MUSB_RXCSR);
- if (csr & MUSB_RXCSR_RXPKTRDY)
- WARNING("rx%d, packet/%d ready?\n", ep->epnum,
- musb_readw(ep->regs, MUSB_RXCOUNT));
-
- musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
}
+ csr = musb_readw(ep->regs, MUSB_RXCSR);
+ if (csr & MUSB_RXCSR_RXPKTRDY) {
+ WARNING("rx%d, packet/%d ready?\n", ep->epnum,
+ musb_readw(ep->regs, MUSB_RXCOUNT));
+ urb_qh_dump(musb);
+ }
+
+ musb_h_flush_rxfifo(ep, MUSB_RXCSR_CLRDATATOG);
/* target addr and (for multipoint) hub addr/port */
if (musb->is_multipoint) {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: musb: Stop bulk endpoint while queue is rotated
Ensure that the endpoint is stopped by clearing REQPKT before clearing DATAERR_NAKTIMEOUT before rotating the queue on the dedicated bulk endpoint. This addresses an issue where a race could result in the endpoint receiving data before it was reprogrammed resulting in a warning about such data from musb_rx_reinit before it was thrown away. The data thrown away was a valid packet that had been correctly ACKed which meant the host and device got out of sync. Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com> Cc: sta...@vger.kernel.org --- drivers/usb/musb/musb_host.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index 30e0d65..777ff30 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -999,6 +999,8 @@ static void musb_bulk_nak_timeout(struct musb *musb, struct musb_hw_ep *ep, /* clear nak timeout bit */ rx_csr = musb_readw(epio, MUSB_RXCSR); rx_csr |= MUSB_RXCSR_H_WZC_BITS; + rx_csr &= ~MUSB_RXCSR_H_REQPKT; + musb_writew(epio, MUSB_RXCSR, rx_csr); rx_csr &= ~MUSB_RXCSR_DATAERROR; musb_writew(epio, MUSB_RXCSR, rx_csr); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MUSB driver on AM3352 dropping USB packets
> From: Bin Liu [mailto:b-...@ti.com] > Hi, > > On Fri, May 06, 2016 at 10:41:46AM +0000, Andrew Goodbody wrote: > > > From: Bin Liu [mailto:b-...@ti.com] > > > On Thu, May 05, 2016 at 04:02:55PM +, Andrew Goodbody wrote: > > > > > From: Bin Liu [mailto:b-...@ti.com] On Thu, May 05, 2016 at > > > > > 03:12:00PM +, Andrew Goodbody wrote: > > > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > > > > > On Thu, May 05, 2016 at 12:22:33PM +, Andrew Goodbody > wrote: > > > > > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > > > > > > > > > On Wed, May 04, 2016 at 03:48:50PM +, Andrew > > > > > > > > > Goodbody > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I have been investigating communication issues with iPads. > > > > > > > > > > When the system is busy it seems that the musb driver > > > > > > > > > > is silently dropping occasional packets. I have a > > > > > > > > > > usbmon trace that does not show the packet and I have > > > > > > > > > > a trace from a hardware USB analyser that does show > > > > > > > > > > the packet. So the device is correctly sending the > > > > > > > > > > packet, it is even being ACKed, but it is not passed up to > > > > > > > > > > the > application. > > > > > > > > > > The packet is a bulk transfer packet of 20 bytes. Can > > > > > > > > > > anyone please give me pointers to where to go looking > > > > > > > > > > for the problem? The syslog shows > > > > > nothing relevant. > > > > > > > > > > > > > > > > > > What is the part number on the am3352 chip? > > > > > > > > > > > > > > > > AM3352BZCZ100 > > > > > > > > > > > > > > > > > What kernel version do you use? > > > > > > > > > > > > > > > > 4.5.0 > > > > > > > > > > > > > > > > > Is musb cppi dma enabled? If so, does the problem still > > > > > > > > > happen when CPPI disabled? > > > > > > > > > > > > > > > > Yes. Yes. When testing with PIO I did get the message "Rx > > > > > > > > interrupt with no > > > > > > > errors or packet!". > > > > > > > > > > > > > > > > > First try to turn on dynamic debug log in musb_host.c to > > > > > > > > > check if musb receives the packet or not. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > -Bin. > > > > > > > > > > > > > > > > I am having problems doing this. If I enable the whole > > > > > > > > file then I get lots of messages on the console about > > > > > > > > /dev/kmsg buffer overrun. There are more then 26 million > > > > > > > > packets in the hardware trace and I have not worked out > > > > > > > > how to correlate any of the possible message from dynamic > > > > > > > > debug with those packets even when I enable some of the > > > > > > > > dynamic debug lines. I can see a few messages about "DMA > > > > > > > > complete but packet still in FIFO, CSR 2103" and just the > > > > > occasional "extra TX2 ready, csr 2100" > > > > > > > > when I enable some of the lines for dynamic debug. > > > > > > > > > > > > > > Well, this issue would not be easy to debug. Is this with > > > > > > > your custom > > > > > board? > > > > > > > If so, have you run EyeDiagram test to rule out signal > > > > > > > integrity problem? Are you able to reproduce it with any TI > > > > > > > EVM, such as Beaglebone Black? If so, please explain the > > > > > > > detail of the test case, I cou
RE: MUSB driver on AM3352 dropping USB packets
> -Original Message- > > From: Bin Liu [mailto:b-...@ti.com] > > On Thu, May 05, 2016 at 04:02:55PM +, Andrew Goodbody wrote: > > > > From: Bin Liu [mailto:b-...@ti.com] On Thu, May 05, 2016 at > > > > 03:12:00PM +, Andrew Goodbody wrote: > > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > > > On Thu, May 05, 2016 at 12:22:33PM +, Andrew Goodbody > wrote: > > > > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > > > > > > > On Wed, May 04, 2016 at 03:48:50PM +, Andrew Goodbody > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I have been investigating communication issues with iPads. > > > > > > > > > When the system is busy it seems that the musb driver is > > > > > > > > > silently dropping occasional packets. I have a usbmon > > > > > > > > > trace that does not show the packet and I have a trace > > > > > > > > > from a hardware USB analyser that does show the packet. > > > > > > > > > So the device is correctly sending the packet, it is > > > > > > > > > even being ACKed, but it is not passed up to the application. > > > > > > > > > The packet is a bulk transfer packet of 20 bytes. Can > > > > > > > > > anyone please give me pointers to where to go looking > > > > > > > > > for the problem? The syslog shows > > > > nothing relevant. > > > > > > > > > > > > > > > > What is the part number on the am3352 chip? > > > > > > > > > > > > > > AM3352BZCZ100 > > > > > > > > > > > > > > > What kernel version do you use? > > > > > > > > > > > > > > 4.5.0 > > > > > > > > > > > > > > > Is musb cppi dma enabled? If so, does the problem still > > > > > > > > happen when CPPI disabled? > > > > > > > > > > > > > > Yes. Yes. When testing with PIO I did get the message "Rx > > > > > > > interrupt with no > > > > > > errors or packet!". > > > > > > > > > > > > > > > First try to turn on dynamic debug log in musb_host.c to > > > > > > > > check if musb receives the packet or not. > > > > > > > > > > > > > > > > Regards, > > > > > > > > -Bin. > > > > > > > > > > > > > > I am having problems doing this. If I enable the whole file > > > > > > > then I get lots of messages on the console about /dev/kmsg > > > > > > > buffer overrun. There are more then 26 million packets in > > > > > > > the hardware trace and I have not worked out how to > > > > > > > correlate any of the possible message from dynamic debug > > > > > > > with those packets even when I enable some of the dynamic > > > > > > > debug lines. I can see a few messages about "DMA complete > > > > > > > but packet still in FIFO, CSR 2103" and just the > > > > occasional "extra TX2 ready, csr 2100" > > > > > > > when I enable some of the lines for dynamic debug. > > > > > > > > > > > > Well, this issue would not be easy to debug. Is this with your > > > > > > custom > > > > board? > > > > > > If so, have you run EyeDiagram test to rule out signal > > > > > > integrity problem? Are you able to reproduce it with any TI > > > > > > EVM, such as Beaglebone Black? If so, please explain the > > > > > > detail of the test case, I could try to reproduce it on my side. > > > > > > > > > > Yes this is on a custom board and yes we did EyeDiagram tests. > > > > > Also the ACK from the controller is seen, so that should rule > > > > > out signal integrity issues. I have just reproduced this on the > > > > > Beaglebone Black using the latest TI SDK. Do you have access to > > > > > 16 iPads with lightning connectors and do you have a Mac running > 10.10.x?
RE: MUSB driver on AM3352 dropping USB packets
> From: Bin Liu [mailto:b-...@ti.com] > On Thu, May 05, 2016 at 04:02:55PM +, Andrew Goodbody wrote: > > > From: Bin Liu [mailto:b-...@ti.com] > > > On Thu, May 05, 2016 at 03:12:00PM +, Andrew Goodbody wrote: > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > On Thu, May 05, 2016 at 12:22:33PM +, Andrew Goodbody wrote: > > > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > > > > > On Wed, May 04, 2016 at 03:48:50PM +, Andrew Goodbody > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I have been investigating communication issues with iPads. > > > > > > > > When the system is busy it seems that the musb driver is > > > > > > > > silently dropping occasional packets. I have a usbmon > > > > > > > > trace that does not show the packet and I have a trace > > > > > > > > from a hardware USB analyser that does show the packet. So > > > > > > > > the device is correctly sending the packet, it is even > > > > > > > > being ACKed, but it is not passed up to the application. > > > > > > > > The packet is a bulk transfer packet of 20 bytes. Can > > > > > > > > anyone please give me pointers to where to go looking for > > > > > > > > the problem? The syslog shows > > > nothing relevant. > > > > > > > > > > > > > > What is the part number on the am3352 chip? > > > > > > > > > > > > AM3352BZCZ100 > > > > > > > > > > > > > What kernel version do you use? > > > > > > > > > > > > 4.5.0 > > > > > > > > > > > > > Is musb cppi dma enabled? If so, does the problem still > > > > > > > happen when CPPI disabled? > > > > > > > > > > > > Yes. Yes. When testing with PIO I did get the message "Rx > > > > > > interrupt with no > > > > > errors or packet!". > > > > > > > > > > > > > First try to turn on dynamic debug log in musb_host.c to > > > > > > > check if musb receives the packet or not. > > > > > > > > > > > > > > Regards, > > > > > > > -Bin. > > > > > > > > > > > > I am having problems doing this. If I enable the whole file > > > > > > then I get lots of messages on the console about /dev/kmsg > > > > > > buffer overrun. There are more then 26 million packets in the > > > > > > hardware trace and I have not worked out how to correlate any > > > > > > of the possible message from dynamic debug with those packets > > > > > > even when I enable some of the dynamic debug lines. I can see > > > > > > a few messages about "DMA complete but packet still in FIFO, > > > > > > CSR 2103" and just the > > > occasional "extra TX2 ready, csr 2100" > > > > > > when I enable some of the lines for dynamic debug. > > > > > > > > > > Well, this issue would not be easy to debug. Is this with your > > > > > custom > > > board? > > > > > If so, have you run EyeDiagram test to rule out signal integrity > > > > > problem? Are you able to reproduce it with any TI EVM, such as > > > > > Beaglebone Black? If so, please explain the detail of the test > > > > > case, I could try to reproduce it on my side. > > > > > > > > Yes this is on a custom board and yes we did EyeDiagram tests. > > > > Also the ACK from the controller is seen, so that should rule out > > > > signal integrity issues. I have just reproduced this on the > > > > Beaglebone Black using the latest TI SDK. Do you have access to 16 > > > > iPads with lightning connectors and do you have a Mac running 10.10.x? > > > > > > No, I don't have those :( > > > > > > 16 devices connecting to musb sounds too many. what is the ep info > > > in the descriptor of the ipad device? > > > > T: Bus=02 Lev=04 Prnt=06 Port=06 Cnt=07 Dev#= 19 Spd=480 MxCh= 0 > > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 4 > > P: Vendor=05ac
RE: MUSB driver on AM3352 dropping USB packets
> From: Bin Liu [mailto:b-...@ti.com] > On Thu, May 05, 2016 at 03:12:00PM +, Andrew Goodbody wrote: > > > From: Bin Liu [mailto:b-...@ti.com] > > > Hi, > > > > > > On Thu, May 05, 2016 at 12:22:33PM +, Andrew Goodbody wrote: > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > On Wed, May 04, 2016 at 03:48:50PM +, Andrew Goodbody > wrote: > > > > > > Hi, > > > > > > > > > > > > I have been investigating communication issues with iPads. > > > > > > When the system is busy it seems that the musb driver is > > > > > > silently dropping occasional packets. I have a usbmon trace > > > > > > that does not show the packet and I have a trace from a > > > > > > hardware USB analyser that does show the packet. So the device > > > > > > is correctly sending the packet, it is even being ACKed, but > > > > > > it is not passed up to the application. The packet is a bulk > > > > > > transfer packet of 20 bytes. Can anyone please give me > > > > > > pointers to where to go looking for the problem? The syslog shows > nothing relevant. > > > > > > > > > > What is the part number on the am3352 chip? > > > > > > > > AM3352BZCZ100 > > > > > > > > > What kernel version do you use? > > > > > > > > 4.5.0 > > > > > > > > > Is musb cppi dma enabled? If so, does the problem still happen > > > > > when CPPI disabled? > > > > > > > > Yes. Yes. When testing with PIO I did get the message "Rx > > > > interrupt with no > > > errors or packet!". > > > > > > > > > First try to turn on dynamic debug log in musb_host.c to check > > > > > if musb receives the packet or not. > > > > > > > > > > Regards, > > > > > -Bin. > > > > > > > > I am having problems doing this. If I enable the whole file then I > > > > get lots of messages on the console about /dev/kmsg buffer > > > > overrun. There are more then 26 million packets in the hardware > > > > trace and I have not worked out how to correlate any of the > > > > possible message from dynamic debug with those packets even when I > > > > enable some of the dynamic debug lines. I can see a few messages > > > > about "DMA complete but packet still in FIFO, CSR 2103" and just the > occasional "extra TX2 ready, csr 2100" > > > > when I enable some of the lines for dynamic debug. > > > > > > Well, this issue would not be easy to debug. Is this with your custom > board? > > > If so, have you run EyeDiagram test to rule out signal integrity > > > problem? Are you able to reproduce it with any TI EVM, such as > > > Beaglebone Black? If so, please explain the detail of the test case, > > > I could try to reproduce it on my side. > > > > Yes this is on a custom board and yes we did EyeDiagram tests. Also > > the ACK from the controller is seen, so that should rule out signal > > integrity issues. I have just reproduced this on the Beaglebone Black > > using the latest TI SDK. Do you have access to 16 iPads with lightning > > connectors and do you have a Mac running 10.10.x? > > No, I don't have those :( > > 16 devices connecting to musb sounds too many. what is the ep info in the > descriptor of the ipad device? T: Bus=02 Lev=04 Prnt=06 Port=06 Cnt=07 Dev#= 19 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 4 P: Vendor=05ac ProdID=12ab Rev= 3.40 S: Manufacturer=Apple Inc. S: Product=iPad S: SerialNumber=1da5f4610eafb36fa1e9eead80a56cb2db11dfce C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver= E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=1250us E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=64ms C: #Ifs= 3 Cfg#= 2 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver= I: If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver= I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver= E: Ad=81(I) Atr=01(Isoc) MxPS= 192 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver= E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=125us C:* #Ifs= 2 Cfg#= 3 Atr=c0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=1250us E: Ad=81(I) Atr=02(Bulk) M
RE: MUSB driver on AM3352 dropping USB packets
> From: Bin Liu [mailto:b-...@ti.com] > Hi, > > On Thu, May 05, 2016 at 12:22:33PM +0000, Andrew Goodbody wrote: > > > From: Bin Liu [mailto:b-...@ti.com] > > > Hi, > > > > > > On Wed, May 04, 2016 at 03:48:50PM +, Andrew Goodbody wrote: > > > > Hi, > > > > > > > > I have been investigating communication issues with iPads. When > > > > the system is busy it seems that the musb driver is silently > > > > dropping occasional packets. I have a usbmon trace that does not > > > > show the packet and I have a trace from a hardware USB analyser > > > > that does show the packet. So the device is correctly sending the > > > > packet, it is even being ACKed, but it is not passed up to the > > > > application. The packet is a bulk transfer packet of 20 bytes. Can > > > > anyone please give me pointers to where to go looking for the > > > > problem? The syslog shows nothing relevant. > > > > > > What is the part number on the am3352 chip? > > > > AM3352BZCZ100 > > > > > What kernel version do you use? > > > > 4.5.0 > > > > > Is musb cppi dma enabled? If so, does the problem still happen when > > > CPPI disabled? > > > > Yes. Yes. When testing with PIO I did get the message "Rx interrupt with no > errors or packet!". > > > > > First try to turn on dynamic debug log in musb_host.c to check if > > > musb receives the packet or not. > > > > > > Regards, > > > -Bin. > > > > I am having problems doing this. If I enable the whole file then I get > > lots of messages on the console about /dev/kmsg buffer overrun. There > > are more then 26 million packets in the hardware trace and I have not > > worked out how to correlate any of the possible message from dynamic > > debug with those packets even when I enable some of the dynamic debug > > lines. I can see a few messages about "DMA complete but packet still > > in FIFO, CSR 2103" and just the occasional "extra TX2 ready, csr 2100" > > when I enable some of the lines for dynamic debug. > > Well, this issue would not be easy to debug. Is this with your custom board? > If so, have you run EyeDiagram test to rule out signal integrity problem? Are > you able to reproduce it with any TI EVM, such as Beaglebone Black? If so, > please explain the detail of the test case, I could try to reproduce it on my > side. Yes this is on a custom board and yes we did EyeDiagram tests. Also the ACK from the controller is seen, so that should rule out signal integrity issues. I have just reproduced this on the Beaglebone Black using the latest TI SDK. Do you have access to 16 iPads with lightning connectors and do you have a Mac running 10.10.x? > > > > Andrew > > Regards, > -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: MUSB driver on AM3352 dropping USB packets
> From: Bin Liu [mailto:b-...@ti.com] > Hi, > > On Wed, May 04, 2016 at 03:48:50PM +0000, Andrew Goodbody wrote: > > Hi, > > > > I have been investigating communication issues with iPads. When the > > system is busy it seems that the musb driver is silently dropping > > occasional packets. I have a usbmon trace that does not show the > > packet and I have a trace from a hardware USB analyser that does show > > the packet. So the device is correctly sending the packet, it is even > > being ACKed, but it is not passed up to the application. The packet is > > a bulk transfer packet of 20 bytes. Can anyone please give me pointers > > to where to go looking for the problem? The syslog shows nothing > > relevant. > > What is the part number on the am3352 chip? AM3352BZCZ100 > What kernel version do you use? 4.5.0 > Is musb cppi dma enabled? If so, does the problem still happen when CPPI > disabled? Yes. Yes. When testing with PIO I did get the message "Rx interrupt with no errors or packet!". > First try to turn on dynamic debug log in musb_host.c to check if musb > receives the packet or not. > > Regards, > -Bin. I am having problems doing this. If I enable the whole file then I get lots of messages on the console about /dev/kmsg buffer overrun. There are more then 26 million packets in the hardware trace and I have not worked out how to correlate any of the possible message from dynamic debug with those packets even when I enable some of the dynamic debug lines. I can see a few messages about "DMA complete but packet still in FIFO, CSR 2103" and just the occasional "extra TX2 ready, csr 2100" when I enable some of the lines for dynamic debug. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MUSB driver on AM3352 dropping USB packets
Hi, I have been investigating communication issues with iPads. When the system is busy it seems that the musb driver is silently dropping occasional packets. I have a usbmon trace that does not show the packet and I have a trace from a hardware USB analyser that does show the packet. So the device is correctly sending the packet, it is even being ACKed, but it is not passed up to the application. The packet is a bulk transfer packet of 20 bytes. Can anyone please give me pointers to where to go looking for the problem? The syslog shows nothing relevant. Thanks, Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: usbip: Fix possible deadlocks reported by lockdep
Change spin_lock calls to spin_lock_irqsave to prevent
attmpted recursive lock taking in interrupt context.
This patch fixes Bug 109351
https://bugzilla.kernel.org/show_bug.cgi?id=109351
Signed-off-by: Andrew Goodbody <andrew.goodb...@cambrionix.com>
---
drivers/usb/usbip/usbip_event.c | 5 ++-
drivers/usb/usbip/vhci_hcd.c| 88 -
drivers/usb/usbip/vhci_rx.c | 30 --
drivers/usb/usbip/vhci_sysfs.c | 19 +
drivers/usb/usbip/vhci_tx.c | 14 ---
5 files changed, 91 insertions(+), 65 deletions(-)
diff --git a/drivers/usb/usbip/usbip_event.c b/drivers/usb/usbip/usbip_event.c
index 64933b9..2580a32 100644
--- a/drivers/usb/usbip/usbip_event.c
+++ b/drivers/usb/usbip/usbip_event.c
@@ -117,11 +117,12 @@ EXPORT_SYMBOL_GPL(usbip_event_add);
int usbip_event_happened(struct usbip_device *ud)
{
int happened = 0;
+ unsigned long flags;
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
if (ud->event != 0)
happened = 1;
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
return happened;
}
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 7fbe19d..fca5110 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -121,9 +121,11 @@ static void dump_port_status_diff(u32 prev_status, u32
new_status)
void rh_port_connect(int rhport, enum usb_device_speed speed)
{
+ unsigned long flags;
+
usbip_dbg_vhci_rh("rh_port_connect %d\n", rhport);
- spin_lock(_controller->lock);
+ spin_lock_irqsave(_controller->lock, flags);
the_controller->port_status[rhport] |= USB_PORT_STAT_CONNECTION
| (1 << USB_PORT_FEAT_C_CONNECTION);
@@ -139,22 +141,24 @@ void rh_port_connect(int rhport, enum usb_device_speed
speed)
break;
}
- spin_unlock(_controller->lock);
+ spin_unlock_irqrestore(_controller->lock, flags);
usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
}
static void rh_port_disconnect(int rhport)
{
+ unsigned long flags;
+
usbip_dbg_vhci_rh("rh_port_disconnect %d\n", rhport);
- spin_lock(_controller->lock);
+ spin_lock_irqsave(_controller->lock, flags);
the_controller->port_status[rhport] &= ~USB_PORT_STAT_CONNECTION;
the_controller->port_status[rhport] |=
(1 << USB_PORT_FEAT_C_CONNECTION);
- spin_unlock(_controller->lock);
+ spin_unlock_irqrestore(_controller->lock, flags);
usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
}
@@ -182,13 +186,14 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
int retval;
int rhport;
int changed = 0;
+ unsigned long flags;
retval = DIV_ROUND_UP(VHCI_NPORTS + 1, 8);
memset(buf, 0, retval);
vhci = hcd_to_vhci(hcd);
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
if (!HCD_HW_ACCESSIBLE(hcd)) {
usbip_dbg_vhci_rh("hw accessible flag not on?\n");
goto done;
@@ -209,7 +214,7 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
usb_hcd_resume_root_hub(hcd);
done:
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
return changed ? retval : 0;
}
@@ -231,6 +236,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
struct vhci_hcd *dum;
int retval = 0;
int rhport;
+ unsigned long flags;
u32 prev_port_status[VHCI_NPORTS];
@@ -249,7 +255,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
dum = hcd_to_vhci(hcd);
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
/* store old status and compare now and old later */
if (usbip_dbg_flag_vhci_rh) {
@@ -403,7 +409,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
}
usbip_dbg_vhci_rh(" bye\n");
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
return retval;
}
@@ -426,6 +432,7 @@ static void vhci_tx_urb(struct urb *urb)
{
struct vhci_device *vdev = get_vdev(urb->dev);
struct vhci_priv *priv;
+ unsigned long flags;
if (!vdev) {
pr_err("could not get virtual device");
@@ -438,7 +445,7 @@ static void vhci_tx_urb(struct urb *urb)
return;
}
- spin_lock(>priv_lock);
+ spin_lock_irqsave(>priv_lock, flags);
priv->seqnum = atomic_inc_return(_controller->seqnum);
if (priv->seqnum == 0x)
RE: Deadlock in USB/IP driver
Is there anyone who can help me with this deadlock? Thanks, Andrew > -Original Message- > From: Andrew Goodbody > Sent: 14 December 2015 16:23 > To: linux-usb@vger.kernel.org > Subject: Deadlock in USB/IP driver > > https://bugzilla.kernel.org/show_bug.cgi?id=109351 > > I posted the log snippet to this list on Friday with no response so far, so I > filed > a bug on it. Greg Kroah-Hartman responded to the bug to ask me to post on > this list. > Outlook messed up the text formatting from the syslog on my first attempt > so I am simply attaching the file this time. > > Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Deadlock in USB/IP driver
https://bugzilla.kernel.org/show_bug.cgi?id=109351
I posted the log snippet to this list on Friday with no response so far, so I
filed a bug on it. Greg Kroah-Hartman responded to the bug to ask me to post on
this list.
Outlook messed up the text formatting from the syslog on my first attempt so I
am simply attaching the file this time.
Andrew
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.497958] usbip_core: USB/IP Core v1.0.0
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.499707] vhci_hcd vhci_hcd: USB/IP
Virtual Host Controller
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.499713] vhci_hcd vhci_hcd: new USB bus
registered, assigned bus number 3
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501600] usb usb3: New USB device
found, idVendor=1d6b, idProduct=0002
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501602] usb usb3: New USB device
strings: Mfr=3, Product=2, SerialNumber=1
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501604] usb usb3: Product: USB/IP
Virtual Host Controller
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501605] usb usb3: Manufacturer: Linux
4.3.0-040300-generic vhci_hcd
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501606] usb usb3: SerialNumber:
vhci_hcd
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.502978] hub 3-0:1.0: USB hub found
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.503138] hub 3-0:1.0: 8 ports detected
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.504814] vhci_hcd: USB/IP 'Virtual'
Host Controller (VHCI) Driver v1.0.0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.195937] vhci_hcd vhci_hcd: rhport(0)
sockfd(15) devid(4) speed(2) speed_str(full-speed)
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304076]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304079]
=
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304080] [ INFO: inconsistent lock
state ]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304082] 4.3.0-040300-generic
#201511020846 Tainted: GE
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304083]
-
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304084] inconsistent {SOFTIRQ-ON-W} ->
{IN-SOFTIRQ-W} usage.
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304085] swapper/0/0
[HC0[0]:SC1[1]:HE1:SE0] takes:
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304086]
(&(>lock)->rlock){+.?...}, at: []
vhci_hub_status+0x34/0x170 [vhci_hcd]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304091] {SOFTIRQ-ON-W} state was
registered at:
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304092] []
__lock_acquire+0x831/0x1b40
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304095] []
lock_acquire+0xaf/0x130
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304097] []
_raw_spin_lock+0x31/0x40
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304100] []
vhci_hub_control+0x69/0x9a0 [vhci_hcd]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304102] []
usb_hcd_submit_urb+0x757/0xaa0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304105] []
usb_submit_urb.part.6+0x2f0/0x550
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304107] []
usb_submit_urb+0x62/0x70
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304109] []
usb_start_wait_urb+0x74/0x180
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304111] []
usb_control_msg+0xc1/0x100
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304113] []
hub_configure+0x129/0xba0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304114] []
hub_probe+0x2b4/0x340
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304116] []
usb_probe_interface+0x1bb/0x2e0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304117] []
driver_probe_device+0x224/0x490
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304120] []
__device_attach_driver+0x71/0xa0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304122] []
bus_for_each_drv+0x5d/0x90
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304124] []
__device_attach+0xbc/0x140
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304126] []
device_initial_probe+0x13/0x20
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304128] []
bus_probe_device+0xa3/0xb0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304129] []
device_add+0x40d/0x690
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304131] []
usb_set_configuration+0x50a/0x8e0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304133] []
generic_probe+0x2e/0x80
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304136] []
usb_probe_device+0x32/0x70
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304137] []
driver_probe_device+0x224/0x490
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304139] []
__device_attach_driver+0x71/0xa0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304141] []
bus_for_each_drv+0x5d/0x90
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304142] []
__device_attach+0xbc/0x140
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304144] []
device_initial_probe+0x13/0x20
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304146] []
bus_probe_device+0xa3/0xb0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304147] []
device_add+0x40d/0x690
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304149] []
usb_new_device+0x277/0x4b0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304150] []
usb_add_hcd+0x582/0x970
Dec 10 15:03:34
Locking problem in USB/IP
I have an application using the USB/IP drivers and I turned on the lock
debugging and checking options in the kernel.
I now get this deadlock report in syslog
Dec 11 15:03:20 cbrx-fw01 kernel: [ 220.497958] usbip_core: USB/IP Core v1.0.0
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.499707] vhci_hcd vhci_hcd: USB/IP
Virtual Host Controller
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.499713] vhci_hcd vhci_hcd: new USB bus
registered, assigned bus number 3
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501600] usb usb3: New USB device
found, idVendor=1d6b, idProduct=0002
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501602] usb usb3: New USB device
strings: Mfr=3, Product=2, SerialNumber=1
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501604] usb usb3: Product: USB/IP
Virtual Host Controller
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501605] usb usb3: Manufacturer: Linux
4.3.0-040300-generic vhci_hcd
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.501606] usb usb3: SerialNumber:
vhci_hcd
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.502978] hub 3-0:1.0: USB hub found
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.503138] hub 3-0:1.0: 8 ports detected
Dec 10 15:03:20 cbrx-fw01 kernel: [ 220.504814] vhci_hcd: USB/IP 'Virtual'
Host Controller (VHCI) Driver v1.0.0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.195937] vhci_hcd vhci_hcd: rhport(0)
sockfd(15) devid(4) speed(2) speed_str(full-speed)
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304076]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304079]
=
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304080] [ INFO: inconsistent lock
state ]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304082] 4.3.0-040300-generic
#201511020846 Tainted: GE
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304083]
-
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304084] inconsistent {SOFTIRQ-ON-W} ->
{IN-SOFTIRQ-W} usage.
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304085] swapper/0/0
[HC0[0]:SC1[1]:HE1:SE0] takes:
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304086]
(&(>lock)->rlock){+.?...}, at: []
vhci_hub_status+0x34/0x170 [vhci_hcd]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304091] {SOFTIRQ-ON-W} state was
registered at:
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304092] []
__lock_acquire+0x831/0x1b40
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304095] []
lock_acquire+0xaf/0x130
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304097] []
_raw_spin_lock+0x31/0x40
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304100] []
vhci_hub_control+0x69/0x9a0 [vhci_hcd]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304102] []
usb_hcd_submit_urb+0x757/0xaa0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304105] []
usb_submit_urb.part.6+0x2f0/0x550
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304107] []
usb_submit_urb+0x62/0x70
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304109] []
usb_start_wait_urb+0x74/0x180
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304111] []
usb_control_msg+0xc1/0x100
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304113] []
hub_configure+0x129/0xba0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304114] []
hub_probe+0x2b4/0x340
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304116] []
usb_probe_interface+0x1bb/0x2e0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304117] []
driver_probe_device+0x224/0x490
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304120] []
__device_attach_driver+0x71/0xa0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304122] []
bus_for_each_drv+0x5d/0x90
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304124] []
__device_attach+0xbc/0x140
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304126] []
device_initial_probe+0x13/0x20
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304128] []
bus_probe_device+0xa3/0xb0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304129] []
device_add+0x40d/0x690
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304131] []
usb_set_configuration+0x50a/0x8e0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304133] []
generic_probe+0x2e/0x80
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304136] []
usb_probe_device+0x32/0x70
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304137] []
driver_probe_device+0x224/0x490
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304139] []
__device_attach_driver+0x71/0xa0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304141] []
bus_for_each_drv+0x5d/0x90
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304142] []
__device_attach+0xbc/0x140
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304144] []
device_initial_probe+0x13/0x20
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304146] []
bus_probe_device+0xa3/0xb0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304147] []
device_add+0x40d/0x690
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304149] []
usb_new_device+0x277/0x4b0
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304150] []
usb_add_hcd+0x582/0x970
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304152] []
vhci_hcd_probe+0x6b/0x110 [vhci_hcd]
Dec 10 15:03:34 cbrx-fw01 kernel: [ 234.304154] []
platform_drv_probe+0x34/0x90
Dec 10 15:03:34 cbrx-fw01 kernel: [
