Hi,
On 5/11/2017 1:22 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> The device hangs at the end of the log.
I repeated the test with USB 3.0 IP version 2.90a and USB 3.1 IP version
1.60, and I found the same result where the TH is occasionally called
twice bac
Hi,
John Youn writes:
> The device hangs at the end of the log.
>>>
>>> I repeated the test with USB 3.0 IP version 2.90a and USB 3.1 IP version
>>> 1.60, and I found the same result where the TH is occasionally called
>>> twice back-to-back.
>>>
Right, found this in the logs. So t
Hi Felipe,
On 4/21/2017 10:26 AM, John Youn wrote:
> On 04/18/2017 05:47 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Thinh Nguyen writes:
(Thinh, for whatever I didn't receive your email via the list, replying
to myself)
>>>
>>> Could it be because of the attached file?
>>>
Felipe
On 04/18/2017 05:47 AM, Felipe Balbi wrote:
>
> Hi,
>
> Thinh Nguyen writes:
>>> (Thinh, for whatever I didn't receive your email via the list, replying
>>> to myself)
>>
>> Could it be because of the attached file?
>>
>>>
>>> Felipe Balbi writes:
> Hmm, can you apply this patch and provide o
Hi,
Thinh Nguyen writes:
>> (Thinh, for whatever I didn't receive your email via the list, replying
>> to myself)
>
> Could it be because of the attached file?
>
>>
>> Felipe Balbi writes:
Hmm, can you apply this patch and provide output when the failure
happens? I suggest setting up
From: Bjorn Helgaas
> Sent: 12 April 2017 16:05
...
> >> So we mask the interrupt in the TH and a short time later, the
> >> interrupt de-assertion packet is sent on PCIe bus and if that's not
> >> seen right away we may already have another call to TH before the BH
> >> gets scheduled.
> >
> > not
Hi Felipe,
On 4/11/2017 11:31 PM, Felipe Balbi wrote:
Hi,
(Thinh, for whatever I didn't receive your email via the list, replying
to myself)
Could it be because of the attached file?
Felipe Balbi writes:
Hmm, can you apply this patch and provide output when the failure
happens? I sugges
On Wed, Apr 12, 2017 at 1:13 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
John Youn writes:
>> Thinh Nguyen writes:
>>> The dwc3 driver can overwite its previous events if its top half IRQ
>>> handler gets invoked again before processing the events in the cache. We
>>>
On 04/11/2017 11:14 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
John Youn writes:
>> Thinh Nguyen writes:
>>> The dwc3 driver can overwite its previous events if its top half IRQ
>>> handler gets invoked again before processing the events in the cache. We
>>
>>
Hi,
(Thinh, for whatever I didn't receive your email via the list, replying
to myself)
Felipe Balbi writes:
>> Hmm, can you apply this patch and provide output when the failure
>> happens? I suggest setting up a 100MiB trace buffer. You don't need to
>> enable any tracers nor any event. trace_p
Hi,
John Youn writes:
>>> John Youn writes:
> Thinh Nguyen writes:
>> The dwc3 driver can overwite its previous events if its top half IRQ
>> handler gets invoked again before processing the events in the cache. We
>
> interrupts are masked, why would top half get invoked a
Hi,
John Youn writes:
>> John Youn writes:
Thinh Nguyen writes:
> The dwc3 driver can overwite its previous events if its top half IRQ
> handler gets invoked again before processing the events in the cache. We
interrupts are masked, why would top half get invoked again?
Hi,
John Youn writes:
Do you think we introduce this when adding evt->cache in TH?
Even without evt->cache we still could overwrite evt->count - so, was
that seen before evt->cache?
>>>
>>> The multiple TH calls could have happened even before we introduced
>>> evt->cache, but onl
On 04/11/2017 09:31 AM, John Youn wrote:
> On 04/11/2017 12:45 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> John Youn writes:
Thinh Nguyen writes:
> The dwc3 driver can overwite its previous events if its top half IRQ
> handler gets invoked again before processing the events in the cache.
On 04/11/2017 12:45 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>>> Thinh Nguyen writes:
The dwc3 driver can overwite its previous events if its top half IRQ
handler gets invoked again before processing the events in the cache. We
>>>
>>> interrupts are masked, why would top h
On 04/10/2017 11:58 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
Yes it will re-assert. The interrupt line will remain asserted as long
events remain in the buffer and it is not masked. So when we
eventually unmask, the interrupt will be reasserted again immediately.
>
Hi,
John Youn writes:
>> Thinh Nguyen writes:
>>> The dwc3 driver can overwite its previous events if its top half IRQ
>>> handler gets invoked again before processing the events in the cache. We
>>
>> interrupts are masked, why would top half get invoked again? Is this,
>> perhaps, related to
Hi,
John Youn writes:
>>> Yes it will re-assert. The interrupt line will remain asserted as long
>>> events remain in the buffer and it is not masked. So when we
>>> eventually unmask, the interrupt will be reasserted again immediately.
>>>
BTW, other option here could be using (like Baolin
On 04/10/2017 11:17 PM, Janusz Dziedzic wrote:
> On 10 April 2017 at 20:43, John Youn wrote:
>> On 04/08/2017 12:38 PM, Janusz Dziedzic wrote:
>>> 2017-04-08 1:57 GMT+02:00 Thinh Nguyen :
The dwc3 driver can overwite its previous events if its top half IRQ
handler gets invoked again befo
On 10 April 2017 at 20:43, John Youn wrote:
> On 04/08/2017 12:38 PM, Janusz Dziedzic wrote:
>> 2017-04-08 1:57 GMT+02:00 Thinh Nguyen :
>>> The dwc3 driver can overwite its previous events if its top half IRQ
>>> handler gets invoked again before processing the events in the cache. We
>>> see thi
On 04/09/2017 11:59 PM, Felipe Balbi wrote:
>
> Hi,
>
> Thinh Nguyen writes:
>> The dwc3 driver can overwite its previous events if its top half IRQ
>> handler gets invoked again before processing the events in the cache. We
>
> interrupts are masked, why would top half get invoked again? Is this,
On 04/08/2017 12:38 PM, Janusz Dziedzic wrote:
> 2017-04-08 1:57 GMT+02:00 Thinh Nguyen :
>> The dwc3 driver can overwite its previous events if its top half IRQ
>> handler gets invoked again before processing the events in the cache. We
>> see this as a hang in the file transfer and the host will
Hi,
Thinh Nguyen writes:
> The dwc3 driver can overwite its previous events if its top half IRQ
> handler gets invoked again before processing the events in the cache. We
interrupts are masked, why would top half get invoked again? Is this,
perhaps, related to DWC3 3.00a which has the "Interrup
2017-04-08 1:57 GMT+02:00 Thinh Nguyen :
> The dwc3 driver can overwite its previous events if its top half IRQ
> handler gets invoked again before processing the events in the cache. We
> see this as a hang in the file transfer and the host will attempt to
> reset the device. This shouldn't be pos
24 matches
Mail list logo
