Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
On Thursday 08 February 2018 02:24 PM, Niklas Cassel wrote:
> On 16/11/17 13:26, Vignesh R wrote:
>> +linux-pci
>>
>> Hi Chris,
>>
>> On Thursday 16 November 2017 05:20 PM, Quadros, Roger wrote:
>>> +Vignesh
>>>
>>> On 13/09/17 17:26, Chris Welch wrote:
We are developing a product based on the TI AM5728 EVM. The product
utilizes a TUSB7340 PCIe USB host for additional ports. The TUSB7340 is
detected and setup properly and works OK with low data rate devices.
However, hot plugging a Realtek USB network adapter and doing Ethernet
transfer bandwidth testing using iperf3 causes the TUSB7340 host to be
locked out. The TUSB7340 host appears to no longer communicate and the
logging indicates xhci_hcd :01:00.0: HC died; cleaning up. Same issue
occurs with another USB Ethernet adapter I tried (Asus).
We looked at using another host and found a mini PCIe card that utilizes
the µPD720201 and can be directly installed on the TI AM5728 EVM. The
card is detected properly and we reran the transfer test. The uPD720201
gets locks out with the same problem.
The AM5728 testing was performed using the TI SD card stock
am57xx-evm-linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050,
and it reports that it is using the TI AM572x EVM Rev A3 device tree.
It shows the following logging when it fails (this is with the TI EVM and
uPD720201).
[ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop
endpoint command.
[ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host.
[ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108
[ 630.425667] r8152 2-4:1.0 enp1s0u4: Tx status -108
[ 630.430483] r8152 2-4:1.0 enp1s0u4: Tx status -108
[ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx status -108
[ 630.440122] xhci_hcd :01:00.0: HC died; cleaning up
[ 630.453961] usb 2-4: USB disconnect, device number 2
The problem appears to be a general driver issue given we get the same
problem with both the TUSB7340 and the µPD720201.
>>
>> Seems like PCIe driver is missing MSI IRQs leading to stall.
>> Reading xHCI registers via PCIe mem space confirms this.
>>
>> I see two problems wrt MSI handling:
>> Since commit 8c934095fa2f3 ("PCI: dwc: Clear MSI interrupt status after it
>> is handled, not before"),
>> dwc clears MSI status after calling EP's IRQ handler. But, it happens that
>> another MSI interrupt is
>> raised just at the end of EP's IRQ handler and before clearing MSI status.
>> This will result in loss of new MSI IRQ as we clear the MSI IRQ status
>> without handling.
>>
>> Another problem appears to be wrt dra7xx PCIe wrapper:
>> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI does not seem to catch MSI IRQs unless,
>> its ensured that PCIE_MSI_INTR0_STATUS register read returns 0.
>>
>> So, could you try reverting commit 8c934095fa2f3 and
>> also apply below patch and let me know if that fixes the issue?
>
> Hello Vignesh,
>
> It is not only dra7xx that is affected by this bug,
> all other DWC based drivers as well.
>
> I suggest that we either:
> Revert 8c934095fa2f ("PCI: dwc: Clear MSI interrupt status after it is
> handled,
> not before")
I will send a revert soon.
> or
> You implement a generic solution
> (i.e. in drivers/pci/dwc/pcie-designware-host.c)
> rather than just a dra7xx specific solution.
Reverting 8c934095fa2f should unblock all other DWC drivers. For dra7xx,
I will send separate patches to fix TI dra7xx specific wrapper level IRQ
handler.
>> ---
>>
>> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
>> index e77a4ceed74c..8280abc56f30 100644
>> --- a/drivers/pci/dwc/pci-dra7xx.c
>> +++ b/drivers/pci/dwc/pci-dra7xx.c
>> @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int
>> irq, void *arg)
>> u32 reg;
>>
>> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>> + dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>
>> switch (reg) {
>> case MSI:
>> - dw_handle_msi_irq(pp);
>> + /*
>> +* Need to make sure no MSI IRQs are pending before
>> +* exiting handler, else the wrapper will not catch new
>> +* IRQs. So loop around till dw_handle_msi_irq() returns
>> +* IRQ_NONE
>> +*/
>> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
>> break;
>> case INTA:
>> case INTB:
>> @@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
>> void *arg)
>> break;
>> }
>>
>> - dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>> -
>> return IRQ_HANDLED;
>> }
>>
>>
>>
>>
--
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe
Re: Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
On 16/11/17 13:26, Vignesh R wrote:
> +linux-pci
>
> Hi Chris,
>
> On Thursday 16 November 2017 05:20 PM, Quadros, Roger wrote:
>> +Vignesh
>>
>> On 13/09/17 17:26, Chris Welch wrote:
>>> We are developing a product based on the TI AM5728 EVM. The product
>>> utilizes a TUSB7340 PCIe USB host for additional ports. The TUSB7340 is
>>> detected and setup properly and works OK with low data rate devices.
>>> However, hot plugging a Realtek USB network adapter and doing Ethernet
>>> transfer bandwidth testing using iperf3 causes the TUSB7340 host to be
>>> locked out. The TUSB7340 host appears to no longer communicate and the
>>> logging indicates xhci_hcd :01:00.0: HC died; cleaning up. Same issue
>>> occurs with another USB Ethernet adapter I tried (Asus).
>>>
>>> We looked at using another host and found a mini PCIe card that utilizes
>>> the µPD720201 and can be directly installed on the TI AM5728 EVM. The card
>>> is detected properly and we reran the transfer test. The uPD720201 gets
>>> locks out with the same problem.
>>>
>>> The AM5728 testing was performed using the TI SD card stock
>>> am57xx-evm-linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and
>>> it reports that it is using the TI AM572x EVM Rev A3 device tree.
>>>
>>> It shows the following logging when it fails (this is with the TI EVM and
>>> uPD720201).
>>>
>>> [ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop
>>> endpoint command.
>>> [ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host.
>>> [ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [ 630.425667] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [ 630.430483] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [ 630.440122] xhci_hcd :01:00.0: HC died; cleaning up
>>> [ 630.453961] usb 2-4: USB disconnect, device number 2
>>>
>>> The problem appears to be a general driver issue given we get the same
>>> problem with both the TUSB7340 and the µPD720201.
>
> Seems like PCIe driver is missing MSI IRQs leading to stall.
> Reading xHCI registers via PCIe mem space confirms this.
>
> I see two problems wrt MSI handling:
> Since commit 8c934095fa2f3 ("PCI: dwc: Clear MSI interrupt status after it is
> handled, not before"),
> dwc clears MSI status after calling EP's IRQ handler. But, it happens that
> another MSI interrupt is
> raised just at the end of EP's IRQ handler and before clearing MSI status.
> This will result in loss of new MSI IRQ as we clear the MSI IRQ status
> without handling.
>
> Another problem appears to be wrt dra7xx PCIe wrapper:
> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI does not seem to catch MSI IRQs unless,
> its ensured that PCIE_MSI_INTR0_STATUS register read returns 0.
>
> So, could you try reverting commit 8c934095fa2f3 and
> also apply below patch and let me know if that fixes the issue?
Hello Vignesh,
It is not only dra7xx that is affected by this bug,
all other DWC based drivers as well.
I suggest that we either:
Revert 8c934095fa2f ("PCI: dwc: Clear MSI interrupt status after it is handled,
not before")
or
You implement a generic solution
(i.e. in drivers/pci/dwc/pcie-designware-host.c)
rather than just a dra7xx specific solution.
Regards,
Niklas
>
> ---
>
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index e77a4ceed74c..8280abc56f30 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
> void *arg)
> u32 reg;
>
> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
> + dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>
> switch (reg) {
> case MSI:
> - dw_handle_msi_irq(pp);
> + /*
> +* Need to make sure no MSI IRQs are pending before
> +* exiting handler, else the wrapper will not catch new
> +* IRQs. So loop around till dw_handle_msi_irq() returns
> +* IRQ_NONE
> +*/
> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
> break;
> case INTA:
> case INTB:
> @@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
> void *arg)
> break;
> }
>
> - dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
> -
> return IRQ_HANDLED;
> }
>
>
>
>
--
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: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
> -Original Message-
> From: Vignesh R [mailto:vigne...@ti.com]
> Sent: Wednesday, November 22, 2017 5:41 AM
> To: Chris Welch <chris.we...@viavisolutions.com>; Quadros, Roger
> <rog...@ti.com>
> Cc: linux-usb@vger.kernel.org; linux-...@vger.kernel.org; Joao Pinto
> <jpi...@synopsys.com>; KISHON VIJAY ABRAHAM <kis...@ti.com>
> Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
>
>
>
> On Tuesday 21 November 2017 08:20 PM, Chris Welch wrote:
> >
> >
> >> -Original Message-
> >> From: Vignesh R [mailto:vigne...@ti.com]
> >> Sent: Tuesday, November 21, 2017 12:48 AM
> >> To: Roger Quadros <rog...@ti.com>
> >> Cc: Chris Welch <chris.we...@viavisolutions.com>;
> >> linux-usb@vger.kernel.org; linux-...@vger.kernel.org; Joao Pinto
> >> <jpi...@synopsys.com>; KISHON VIJAY ABRAHAM <kis...@ti.com>
> >> Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and
> >> µPD720201
> >>
> >>
> >>
> >> On Monday 20 November 2017 07:01 PM, Roger Quadros wrote:
> >>> On 20/11/17 15:19, Vignesh R wrote:
> >>>>
> >>>>
> >>>> On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
> >>>> [...]
> >>>>>>
> >>>>>> So, could you try reverting commit 8c934095fa2f3 and also apply
> >>>>>> below patch and let me know if that fixes the issue?
> >>>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> diff --git a/drivers/pci/dwc/pci-dra7xx.c
> >>>>>> b/drivers/pci/dwc/pci-dra7xx.c index e77a4ceed74c..8280abc56f30
> >>>>>> 100644
> >>>>>> --- a/drivers/pci/dwc/pci-dra7xx.c
> >>>>>> +++ b/drivers/pci/dwc/pci-dra7xx.c
> >>>>>> @@ -259,10 +259,17 @@ static irqreturn_t
> >> dra7xx_pcie_msi_irq_handler(int irq, void *arg)
> >>>>>> u32 reg;
> >>>>>>
> >>>>>> reg = dra7xx_pcie_readl(dra7xx,
> >>>>>> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
> >>>>>> + dra7xx_pcie_writel(dra7xx,
> >>>>>> + PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
> >>>>>>
> >>>>>> switch (reg) {
> >>>>>> case MSI:
> >>>>>> - dw_handle_msi_irq(pp);
> >>>>>> + /*
> >>>>>> +* Need to make sure no MSI IRQs are pending before
> >>>>>> +* exiting handler, else the wrapper will not catch new
> >>>>>> +* IRQs. So loop around till dw_handle_msi_irq()
> >>>>>> returns
> >>>>>> +* IRQ_NONE
> >>>>>> +*/
> >>>>>> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
> >
> > The patch looks good, I haven't had a failure in a few days of testing.
> >
> > You should also look at incorporating the following that I needed to change
> > to
> get our product working. The first change fixes a miss by one error with the
> interrupt lines.
> >
> > The second change extends a patch you developed for errata i870 but we
> found is applicable to RC operation as well as EPs. Thanks very much for your
> help!
>
> BTW, do you have a test case which fails w/o errata i870 workaround?
Yes, we have a PEX8606 PCI switch attached to the RC which fails to probe if
the i870 workaround is not used.
The code picks up the wrong class for the switch if the work around is not in
place.
>
>
> --
> Regards
> Vignesh
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
On Tuesday 21 November 2017 08:20 PM, Chris Welch wrote:
>
>
>> -Original Message-
>> From: Vignesh R [mailto:vigne...@ti.com]
>> Sent: Tuesday, November 21, 2017 12:48 AM
>> To: Roger Quadros <rog...@ti.com>
>> Cc: Chris Welch <chris.we...@viavisolutions.com>; linux-usb@vger.kernel.org;
>> linux-...@vger.kernel.org; Joao Pinto <jpi...@synopsys.com>; KISHON VIJAY
>> ABRAHAM <kis...@ti.com>
>> Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
>>
>>
>>
>> On Monday 20 November 2017 07:01 PM, Roger Quadros wrote:
>>> On 20/11/17 15:19, Vignesh R wrote:
>>>>
>>>>
>>>> On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
>>>> [...]
>>>>>>
>>>>>> So, could you try reverting commit 8c934095fa2f3 and also apply
>>>>>> below patch and let me know if that fixes the issue?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> diff --git a/drivers/pci/dwc/pci-dra7xx.c
>>>>>> b/drivers/pci/dwc/pci-dra7xx.c index e77a4ceed74c..8280abc56f30
>>>>>> 100644
>>>>>> --- a/drivers/pci/dwc/pci-dra7xx.c
>>>>>> +++ b/drivers/pci/dwc/pci-dra7xx.c
>>>>>> @@ -259,10 +259,17 @@ static irqreturn_t
>> dra7xx_pcie_msi_irq_handler(int irq, void *arg)
>>>>>> u32 reg;
>>>>>>
>>>>>> reg = dra7xx_pcie_readl(dra7xx,
>>>>>> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>>>>>> + dra7xx_pcie_writel(dra7xx,
>>>>>> + PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>>>>>
>>>>>> switch (reg) {
>>>>>> case MSI:
>>>>>> - dw_handle_msi_irq(pp);
>>>>>> + /*
>>>>>> +* Need to make sure no MSI IRQs are pending before
>>>>>> +* exiting handler, else the wrapper will not catch new
>>>>>> +* IRQs. So loop around till dw_handle_msi_irq() returns
>>>>>> +* IRQ_NONE
>>>>>> +*/
>>>>>> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
>
> The patch looks good, I haven't had a failure in a few days of testing.
>
> You should also look at incorporating the following that I needed to change
> to get our product working. The first change fixes a miss by one error with
> the interrupt lines.
>
> The second change extends a patch you developed for errata i870 but we found
> is applicable to RC operation as well as EPs. Thanks very much for your help!
BTW, do you have a test case which fails w/o errata i870 workaround?
--
Regards
Vignesh
--
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: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
On Tuesday 21 November 2017 08:20 PM, Chris Welch wrote:
>
>
>> -Original Message-
>> From: Vignesh R [mailto:vigne...@ti.com]
>> Sent: Tuesday, November 21, 2017 12:48 AM
>> To: Roger Quadros <rog...@ti.com>
>> Cc: Chris Welch <chris.we...@viavisolutions.com>; linux-usb@vger.kernel.org;
>> linux-...@vger.kernel.org; Joao Pinto <jpi...@synopsys.com>; KISHON VIJAY
>> ABRAHAM <kis...@ti.com>
>> Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
>>
>>
>>
>> On Monday 20 November 2017 07:01 PM, Roger Quadros wrote:
>>> On 20/11/17 15:19, Vignesh R wrote:
>>>>
>>>>
>>>> On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
>>>> [...]
>>>>>>
>>>>>> So, could you try reverting commit 8c934095fa2f3 and also apply
>>>>>> below patch and let me know if that fixes the issue?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> diff --git a/drivers/pci/dwc/pci-dra7xx.c
>>>>>> b/drivers/pci/dwc/pci-dra7xx.c index e77a4ceed74c..8280abc56f30
>>>>>> 100644
>>>>>> --- a/drivers/pci/dwc/pci-dra7xx.c
>>>>>> +++ b/drivers/pci/dwc/pci-dra7xx.c
>>>>>> @@ -259,10 +259,17 @@ static irqreturn_t
>> dra7xx_pcie_msi_irq_handler(int irq, void *arg)
>>>>>> u32 reg;
>>>>>>
>>>>>> reg = dra7xx_pcie_readl(dra7xx,
>>>>>> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>>>>>> + dra7xx_pcie_writel(dra7xx,
>>>>>> + PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>>>>>
>>>>>> switch (reg) {
>>>>>> case MSI:
>>>>>> - dw_handle_msi_irq(pp);
>>>>>> + /*
>>>>>> +* Need to make sure no MSI IRQs are pending before
>>>>>> +* exiting handler, else the wrapper will not catch new
>>>>>> +* IRQs. So loop around till dw_handle_msi_irq() returns
>>>>>> +* IRQ_NONE
>>>>>> +*/
>>>>>> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
>
> The patch looks good, I haven't had a failure in a few days of testing.
Thanks for testing! I will submit patches formally with some minor tweaks.
>
> You should also look at incorporating the following that I needed to change
> to get our product working. The first change fixes a miss by one error with
> the interrupt lines.
Yeah, this is a known issue and has been discussed[1] before. We are
exploring better solution
>
> The second change extends a patch you developed for errata i870 but we found
> is applicable to RC operation as well as EPs. Thanks very much for your help!
Thanks for pointing that out, will submit a patch for errata workaround.
[1] https://lkml.org/lkml/2016/9/14/241
Regards
Vignesh
>
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> old mode 100644
> new mode 100755
> index defa272..6245d89
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -238,8 +238,8 @@ static int dra7xx_pcie_init_irq_domain(struct pcie_port
> *pp)
> dev_err(dev, "No PCIe Intc node found\n");
> return -ENODEV;
> }
> -
> - dra7xx->irq_domain = irq_domain_add_linear(pcie_intc_node, 4,
> +// PCI interrupt lines start at 1 not zero so need to add 1
> + dra7xx->irq_domain = irq_domain_add_linear(pcie_intc_node, 4 + 1,
>_domain_ops, pp);
> if (!dra7xx->irq_domain) {
> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> @@ -706,10 +706,16 @@ static int __init dra7xx_pcie_probe(struct
> platform_device *pdev)
> dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
>DEVICE_TYPE_RC);
>
> + // Errata i870 applies to RC as well as EP
> + ret = dra7xx_pcie_ep_legacy_mode(dev);
> + if (ret)
> + goto err_gpio;
> +
> ret = dra7xx_add_pcie_port(dra7xx, pdev);
> if (ret < 0)
> goto err_gpio;
> break;
>
>
>>>>>
>>>>> To avoid this kind of looping, shouldn't we be disabling all IRQ
>>>>> events while the i
RE: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
> -Original Message-
> From: Vignesh R [mailto:vigne...@ti.com]
> Sent: Tuesday, November 21, 2017 12:48 AM
> To: Roger Quadros <rog...@ti.com>
> Cc: Chris Welch <chris.we...@viavisolutions.com>; linux-usb@vger.kernel.org;
> linux-...@vger.kernel.org; Joao Pinto <jpi...@synopsys.com>; KISHON VIJAY
> ABRAHAM <kis...@ti.com>
> Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
>
>
>
> On Monday 20 November 2017 07:01 PM, Roger Quadros wrote:
> > On 20/11/17 15:19, Vignesh R wrote:
> >>
> >>
> >> On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
> >> [...]
> >>>>
> >>>> So, could you try reverting commit 8c934095fa2f3 and also apply
> >>>> below patch and let me know if that fixes the issue?
> >>>>
> >>>> ---
> >>>>
> >>>> diff --git a/drivers/pci/dwc/pci-dra7xx.c
> >>>> b/drivers/pci/dwc/pci-dra7xx.c index e77a4ceed74c..8280abc56f30
> >>>> 100644
> >>>> --- a/drivers/pci/dwc/pci-dra7xx.c
> >>>> +++ b/drivers/pci/dwc/pci-dra7xx.c
> >>>> @@ -259,10 +259,17 @@ static irqreturn_t
> dra7xx_pcie_msi_irq_handler(int irq, void *arg)
> >>>> u32 reg;
> >>>>
> >>>> reg = dra7xx_pcie_readl(dra7xx,
> >>>> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
> >>>> + dra7xx_pcie_writel(dra7xx,
> >>>> + PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
> >>>>
> >>>> switch (reg) {
> >>>> case MSI:
> >>>> - dw_handle_msi_irq(pp);
> >>>> + /*
> >>>> +* Need to make sure no MSI IRQs are pending before
> >>>> +* exiting handler, else the wrapper will not catch new
> >>>> +* IRQs. So loop around till dw_handle_msi_irq() returns
> >>>> +* IRQ_NONE
> >>>> +*/
> >>>> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
The patch looks good, I haven't had a failure in a few days of testing.
You should also look at incorporating the following that I needed to change to
get our product working. The first change fixes a miss by one error with the
interrupt lines.
The second change extends a patch you developed for errata i870 but we found is
applicable to RC operation as well as EPs. Thanks very much for your help!
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
old mode 100644
new mode 100755
index defa272..6245d89
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -238,8 +238,8 @@ static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
dev_err(dev, "No PCIe Intc node found\n");
return -ENODEV;
}
-
- dra7xx->irq_domain = irq_domain_add_linear(pcie_intc_node, 4,
+// PCI interrupt lines start at 1 not zero so need to add 1
+ dra7xx->irq_domain = irq_domain_add_linear(pcie_intc_node, 4 + 1,
_domain_ops, pp);
if (!dra7xx->irq_domain) {
dev_err(dev, "Failed to get a INTx IRQ domain\n");
@@ -706,10 +706,16 @@ static int __init dra7xx_pcie_probe(struct
platform_device *pdev)
dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
DEVICE_TYPE_RC);
+ // Errata i870 applies to RC as well as EP
+ ret = dra7xx_pcie_ep_legacy_mode(dev);
+ if (ret)
+ goto err_gpio;
+
ret = dra7xx_add_pcie_port(dra7xx, pdev);
if (ret < 0)
goto err_gpio;
break;
> >>>
> >>> To avoid this kind of looping, shouldn't we be disabling all IRQ
> >>> events while the interrupt handler is running and enable them just
> >>> before we return from the hardirq handler?
> >>
> >> IIUC, you are saying to disable all MSIs at PCIe designware core
> >> level, then call dw_handle_msi_irq() and then enable MSIs after
> >> hardirq returns. But, the problem is if PCIe EP raises another MSI
> >> after the call to EP's handler but before re-enabling MSIs, then it
> >> will be ignored as IRQs are not yet enabled.
> >> Ideally, EP's support Per Vector Masking(PVM) which allow RC to
> >> prevent EP from sending MSI messages for sometime. But,
> >> unfortunately, the cards mentioned here don't support this feature.
> >
> > I'm
Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
On Monday 20 November 2017 07:01 PM, Roger Quadros wrote:
> On 20/11/17 15:19, Vignesh R wrote:
>>
>>
>> On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
>> [...]
So, could you try reverting commit 8c934095fa2f3 and
also apply below patch and let me know if that fixes the issue?
---
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index e77a4ceed74c..8280abc56f30 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int
irq, void *arg)
u32 reg;
reg = dra7xx_pcie_readl(dra7xx,
PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
+ dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI,
reg);
switch (reg) {
case MSI:
- dw_handle_msi_irq(pp);
+ /*
+* Need to make sure no MSI IRQs are pending before
+* exiting handler, else the wrapper will not catch new
+* IRQs. So loop around till dw_handle_msi_irq() returns
+* IRQ_NONE
+*/
+ while (dw_handle_msi_irq(pp) != IRQ_NONE);
>>>
>>> To avoid this kind of looping, shouldn't we be disabling all IRQ events
>>> while
>>> the interrupt handler is running and enable them just before we return from
>>> the hardirq
>>> handler?
>>
>> IIUC, you are saying to disable all MSIs at PCIe designware core level,
>> then call dw_handle_msi_irq() and then enable MSIs after hardirq
>> returns. But, the problem is if PCIe EP raises another MSI after the
>> call to EP's handler but before re-enabling MSIs, then it will be
>> ignored as IRQs are not yet enabled.
>> Ideally, EP's support Per Vector Masking(PVM) which allow RC to prevent
>> EP from sending MSI messages for sometime. But, unfortunately, the cards
>> mentioned here don't support this feature.
>
> I'm not aware of MSIs.
>
> But for any typical hardware, there should be an interrupt event enable
> register and an
> interrupt mask register.
>
> In the IRQ handler, we mask the interrupt but still keep the interrupt events
> enabled so that
> they can be latched during the time the interrupt was masked.
>
> When the interrupt is unmasked at end of the IRQ handler, it should
> re-trigger the interrupt
> if any events were latched and pending.
>
> This way you don't need to keep checking for any pending events in the IRQ
> handler.
>
Thanks for the suggestion! I tried using interrupt masking at designware
level. But, unfortunately that does not help and my test cases still fail.
Seems like designware MSI status register is a non-masked status and
dra7xx specific wrapper seems to be relying on this non-masked status to
raise IRQ(instead of actual IRQ signal of designware) to CPU. There is
very little documentation in the TRM wrt how wrapper forwards designware
IRQ status to CPU.
So, at best, I will add a check in the above while() loop and break and
exit IRQ handler, lets say after 1K loops.
--
Regards
Vignesh
--
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: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
On 20/11/17 15:19, Vignesh R wrote:
>
>
> On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
> [...]
>>>
>>> So, could you try reverting commit 8c934095fa2f3 and
>>> also apply below patch and let me know if that fixes the issue?
>>>
>>> ---
>>>
>>> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
>>> index e77a4ceed74c..8280abc56f30 100644
>>> --- a/drivers/pci/dwc/pci-dra7xx.c
>>> +++ b/drivers/pci/dwc/pci-dra7xx.c
>>> @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int
>>> irq, void *arg)
>>> u32 reg;
>>>
>>> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>>> + dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>>
>>> switch (reg) {
>>> case MSI:
>>> - dw_handle_msi_irq(pp);
>>> + /*
>>> +* Need to make sure no MSI IRQs are pending before
>>> +* exiting handler, else the wrapper will not catch new
>>> +* IRQs. So loop around till dw_handle_msi_irq() returns
>>> +* IRQ_NONE
>>> +*/
>>> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
>>
>> To avoid this kind of looping, shouldn't we be disabling all IRQ events while
>> the interrupt handler is running and enable them just before we return from
>> the hardirq
>> handler?
>
> IIUC, you are saying to disable all MSIs at PCIe designware core level,
> then call dw_handle_msi_irq() and then enable MSIs after hardirq
> returns. But, the problem is if PCIe EP raises another MSI after the
> call to EP's handler but before re-enabling MSIs, then it will be
> ignored as IRQs are not yet enabled.
> Ideally, EP's support Per Vector Masking(PVM) which allow RC to prevent
> EP from sending MSI messages for sometime. But, unfortunately, the cards
> mentioned here don't support this feature.
I'm not aware of MSIs.
But for any typical hardware, there should be an interrupt event enable
register and an
interrupt mask register.
In the IRQ handler, we mask the interrupt but still keep the interrupt events
enabled so that
they can be latched during the time the interrupt was masked.
When the interrupt is unmasked at end of the IRQ handler, it should re-trigger
the interrupt
if any events were latched and pending.
This way you don't need to keep checking for any pending events in the IRQ
handler.
>
>>
>>
>>> break;
>>> case INTA:
>>> case INTB:
>>> @@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
>>> void *arg)
>>> break;
>>> }
>>>
>>> - dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>> -
>>> return IRQ_HANDLED;
>>> }
>>>
>>>
>>>
>>>
>>
>
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
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: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
[...]
>>
>> So, could you try reverting commit 8c934095fa2f3 and
>> also apply below patch and let me know if that fixes the issue?
>>
>> ---
>>
>> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
>> index e77a4ceed74c..8280abc56f30 100644
>> --- a/drivers/pci/dwc/pci-dra7xx.c
>> +++ b/drivers/pci/dwc/pci-dra7xx.c
>> @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int
>> irq, void *arg)
>> u32 reg;
>>
>> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>> + dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>
>> switch (reg) {
>> case MSI:
>> - dw_handle_msi_irq(pp);
>> + /*
>> +* Need to make sure no MSI IRQs are pending before
>> +* exiting handler, else the wrapper will not catch new
>> +* IRQs. So loop around till dw_handle_msi_irq() returns
>> +* IRQ_NONE
>> +*/
>> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
>
> To avoid this kind of looping, shouldn't we be disabling all IRQ events while
> the interrupt handler is running and enable them just before we return from
> the hardirq
> handler?
IIUC, you are saying to disable all MSIs at PCIe designware core level,
then call dw_handle_msi_irq() and then enable MSIs after hardirq
returns. But, the problem is if PCIe EP raises another MSI after the
call to EP's handler but before re-enabling MSIs, then it will be
ignored as IRQs are not yet enabled.
Ideally, EP's support Per Vector Masking(PVM) which allow RC to prevent
EP from sending MSI messages for sometime. But, unfortunately, the cards
mentioned here don't support this feature.
>
>
>> break;
>> case INTA:
>> case INTB:
>> @@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
>> void *arg)
>> break;
>> }
>>
>> - dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>> -
>> return IRQ_HANDLED;
>> }
>>
>>
>>
>>
>
--
Regards
Vignesh
--
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: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
Hi Vignesh,
On 16/11/17 14:26, Vignesh R wrote:
> +linux-pci
>
> Hi Chris,
>
> On Thursday 16 November 2017 05:20 PM, Quadros, Roger wrote:
>> +Vignesh
>>
>> On 13/09/17 17:26, Chris Welch wrote:
>>> We are developing a product based on the TI AM5728 EVM. The product
>>> utilizes a TUSB7340 PCIe USB host for additional ports. The TUSB7340 is
>>> detected and setup properly and works OK with low data rate devices.
>>> However, hot plugging a Realtek USB network adapter and doing Ethernet
>>> transfer bandwidth testing using iperf3 causes the TUSB7340 host to be
>>> locked out. The TUSB7340 host appears to no longer communicate and the
>>> logging indicates xhci_hcd :01:00.0: HC died; cleaning up. Same issue
>>> occurs with another USB Ethernet adapter I tried (Asus).
>>>
>>> We looked at using another host and found a mini PCIe card that utilizes
>>> the µPD720201 and can be directly installed on the TI AM5728 EVM. The card
>>> is detected properly and we reran the transfer test. The uPD720201 gets
>>> locks out with the same problem.
>>>
>>> The AM5728 testing was performed using the TI SD card stock
>>> am57xx-evm-linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and
>>> it reports that it is using the TI AM572x EVM Rev A3 device tree.
>>>
>>> It shows the following logging when it fails (this is with the TI EVM and
>>> uPD720201).
>>>
>>> [ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop
>>> endpoint command.
>>> [ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host.
>>> [ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [ 630.425667] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [ 630.430483] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [ 630.440122] xhci_hcd :01:00.0: HC died; cleaning up
>>> [ 630.453961] usb 2-4: USB disconnect, device number 2
>>>
>>> The problem appears to be a general driver issue given we get the same
>>> problem with both the TUSB7340 and the µPD720201.
>
> Seems like PCIe driver is missing MSI IRQs leading to stall.
> Reading xHCI registers via PCIe mem space confirms this.
>
> I see two problems wrt MSI handling:
> Since commit 8c934095fa2f3 ("PCI: dwc: Clear MSI interrupt status after it is
> handled, not before"),
> dwc clears MSI status after calling EP's IRQ handler. But, it happens that
> another MSI interrupt is
> raised just at the end of EP's IRQ handler and before clearing MSI status.
> This will result in loss of new MSI IRQ as we clear the MSI IRQ status
> without handling.
>
> Another problem appears to be wrt dra7xx PCIe wrapper:
> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI does not seem to catch MSI IRQs unless,
> its ensured that PCIE_MSI_INTR0_STATUS register read returns 0.
>
> So, could you try reverting commit 8c934095fa2f3 and
> also apply below patch and let me know if that fixes the issue?
>
> ---
>
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index e77a4ceed74c..8280abc56f30 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
> void *arg)
> u32 reg;
>
> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
> + dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>
> switch (reg) {
> case MSI:
> - dw_handle_msi_irq(pp);
> + /*
> +* Need to make sure no MSI IRQs are pending before
> +* exiting handler, else the wrapper will not catch new
> +* IRQs. So loop around till dw_handle_msi_irq() returns
> +* IRQ_NONE
> +*/
> + while (dw_handle_msi_irq(pp) != IRQ_NONE);
To avoid this kind of looping, shouldn't we be disabling all IRQ events while
the interrupt handler is running and enable them just before we return from the
hardirq
handler?
> break;
> case INTA:
> case INTB:
> @@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
> void *arg)
> break;
> }
>
> - dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
> -
> return IRQ_HANDLED;
> }
>
>
>
>
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
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: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
+linux-pci
Hi Chris,
On Thursday 16 November 2017 05:20 PM, Quadros, Roger wrote:
> +Vignesh
>
> On 13/09/17 17:26, Chris Welch wrote:
>> We are developing a product based on the TI AM5728 EVM. The product
>> utilizes a TUSB7340 PCIe USB host for additional ports. The TUSB7340 is
>> detected and setup properly and works OK with low data rate devices.
>> However, hot plugging a Realtek USB network adapter and doing Ethernet
>> transfer bandwidth testing using iperf3 causes the TUSB7340 host to be
>> locked out. The TUSB7340 host appears to no longer communicate and the
>> logging indicates xhci_hcd :01:00.0: HC died; cleaning up. Same issue
>> occurs with another USB Ethernet adapter I tried (Asus).
>>
>> We looked at using another host and found a mini PCIe card that utilizes the
>> µPD720201 and can be directly installed on the TI AM5728 EVM. The card is
>> detected properly and we reran the transfer test. The uPD720201 gets locks
>> out with the same problem.
>>
>> The AM5728 testing was performed using the TI SD card stock
>> am57xx-evm-linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and
>> it reports that it is using the TI AM572x EVM Rev A3 device tree.
>>
>> It shows the following logging when it fails (this is with the TI EVM and
>> uPD720201).
>>
>> [ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop
>> endpoint command.
>> [ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host.
>> [ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108
>> [ 630.425667] r8152 2-4:1.0 enp1s0u4: Tx status -108
>> [ 630.430483] r8152 2-4:1.0 enp1s0u4: Tx status -108
>> [ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx status -108
>> [ 630.440122] xhci_hcd :01:00.0: HC died; cleaning up
>> [ 630.453961] usb 2-4: USB disconnect, device number 2
>>
>> The problem appears to be a general driver issue given we get the same
>> problem with both the TUSB7340 and the µPD720201.
Seems like PCIe driver is missing MSI IRQs leading to stall.
Reading xHCI registers via PCIe mem space confirms this.
I see two problems wrt MSI handling:
Since commit 8c934095fa2f3 ("PCI: dwc: Clear MSI interrupt status after it is
handled, not before"),
dwc clears MSI status after calling EP's IRQ handler. But, it happens that
another MSI interrupt is
raised just at the end of EP's IRQ handler and before clearing MSI status.
This will result in loss of new MSI IRQ as we clear the MSI IRQ status without
handling.
Another problem appears to be wrt dra7xx PCIe wrapper:
PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI does not seem to catch MSI IRQs unless,
its ensured that PCIE_MSI_INTR0_STATUS register read returns 0.
So, could you try reverting commit 8c934095fa2f3 and
also apply below patch and let me know if that fixes the issue?
---
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index e77a4ceed74c..8280abc56f30 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
void *arg)
u32 reg;
reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
+ dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
switch (reg) {
case MSI:
- dw_handle_msi_irq(pp);
+ /*
+* Need to make sure no MSI IRQs are pending before
+* exiting handler, else the wrapper will not catch new
+* IRQs. So loop around till dw_handle_msi_irq() returns
+* IRQ_NONE
+*/
+ while (dw_handle_msi_irq(pp) != IRQ_NONE);
break;
case INTA:
case INTB:
@@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq,
void *arg)
break;
}
- dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
-
return IRQ_HANDLED;
}
--
Regards
Vignesh
--
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: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
+Vigesh On 13/09/17 17:26, Chris Welch wrote: > We are developing a product based on the TI AM5728 EVM. The product utilizes > a TUSB7340 PCIe USB host for additional ports. The TUSB7340 is detected and > setup properly and works OK with low data rate devices. However, hot > plugging a Realtek USB network adapter and doing Ethernet transfer bandwidth > testing using iperf3 causes the TUSB7340 host to be locked out. The > TUSB7340 host appears to no longer communicate and the logging indicates > xhci_hcd :01:00.0: HC died; cleaning up. Same issue occurs with another > USB Ethernet adapter I tried (Asus). > > We looked at using another host and found a mini PCIe card that utilizes the > µPD720201 and can be directly installed on the TI AM5728 EVM. The card is > detected properly and we reran the transfer test. The uPD720201 gets locks > out with the same problem. > > The AM5728 testing was performed using the TI SD card stock > am57xx-evm-linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and > it reports that it is using the TI AM572x EVM Rev A3 device tree. > > It shows the following logging when it fails (this is with the TI EVM and > uPD720201). > > [ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop > endpoint command. > [ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host. > [ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108 > [ 630.425667] r8152 2-4:1.0 enp1s0u4: Tx status -108 > [ 630.430483] r8152 2-4:1.0 enp1s0u4: Tx status -108 > [ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx status -108 > [ 630.440122] xhci_hcd :01:00.0: HC died; cleaning up > [ 630.453961] usb 2-4: USB disconnect, device number 2 > > The problem appears to be a general driver issue given we get the same > problem with both the TUSB7340 and the µPD720201. > > I've tried the 4.4.49, 4.12.3 and 4.13.1 kernels and they also fail. > > I tried the TI E2E support community and they were unable to provide any > solutions. > > Here is a sample session with the TUSB7340: > > root@arm:~# !iperf3 > iperf3 -c 10.14.21.95 -t 6000 > Connecting to host 10.14.21.95, port 5201 > [ 4] local 10.14.21.89 port 60978 connected to 10.14.21.95 port 5201 > [ ID] Interval Transfer Bandwidth Retr Cwnd > [ 4] 0.00-1.00 sec 14.2 MBytes 119 Mbits/sec 1 1.41 KBytes > [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > ^C[ 4] 7.00-7.48 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-7.48 sec 14.2 MBytes 15.9 Mbits/sec 1 sender > [ 4] 0.00-7.48 sec 0.00 Bytes 0.00 bits/sec receiver > iperf3: interrupt - the client has terminated > root@arm:~# [ 118.187204] xhci_hcd 0001:07:00.0: xHCI host controller not > responding, assume dead > [ 118.196419] xhci_hcd 0001:07:00.0: HC died; cleaning up > > Any suggestions on how we can address this problem? > > -- > 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 > -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- 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: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
> -Original Message- > From: Roger Quadros [mailto:rog...@ti.com] > Sent: Thursday, September 14, 2017 10:14 AM > To: Chris Welch <chris.we...@viavisolutions.com>; linux-usb@vger.kernel.org > Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201 > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y- > tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 14/09/17 16:53, Chris Welch wrote: > >> -Original Message- > >> From: Roger Quadros [mailto:rog...@ti.com] > >> Sent: Thursday, September 14, 2017 6:38 AM > >> To: Chris Welch <chris.we...@viavisolutions.com>; > >> linux-usb@vger.kernel.org > >> Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and > >> µPD720201 > >> > >> Chris, > >> > >> > >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y- > >> tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > >> > >> On 13/09/17 17:26, Chris Welch wrote: > >>> We are developing a product based on the TI AM5728 EVM. The product > >> utilizes a TUSB7340 PCIe USB host for additional ports. The TUSB7340 > >> is detected and setup properly and works OK with low data rate devices. > >> However, hot plugging a Realtek USB network adapter and doing > >> Ethernet transfer bandwidth testing using iperf3 causes the TUSB7340 > >> host to be locked out. The TUSB7340 host appears to no longer > >> communicate and the logging indicates xhci_hcd :01:00.0: HC died; > >> cleaning up. Same issue occurs with another USB Ethernet adapter I tried > (Asus). > >>> > >>> We looked at using another host and found a mini PCIe card that > >>> utilizes the > >> µPD720201 and can be directly installed on the TI AM5728 EVM. The > >> card is detected properly and we reran the transfer test. The > >> uPD720201 gets locks out with the same problem. > >>> > >>> The AM5728 testing was performed using the TI SD card stock > >>> am57xx-evm- > >> linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and it > >> reports that it is using the TI AM572x EVM Rev A3 device tree. > >>> > >>> It shows the following logging when it fails (this is with the TI > >>> EVM and > >> uPD720201). > >>> > >>> [ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to > >>> stop > >> endpoint command. > >>> [ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting > >>> host. > >>> [ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108 [ 630.425667] > >>> r8152 2-4:1.0 enp1s0u4: Tx status -108 [ 630.430483] r8152 2-4:1.0 > >>> enp1s0u4: Tx status -108 [ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx > >>> status -108 [ 630.440122] xhci_hcd :01:00.0: HC died; cleaning > >>> up [ 630.453961] usb 2-4: USB disconnect, device number 2 > >>> > >>> The problem appears to be a general driver issue given we get the > >>> same > >> problem with both the TUSB7340 and the µPD720201. > >> > >> Can you try to reproduce the issue with the Realtek USB network > >> adapter on the Native USB host port of AM5727 EVM. That happens to > >> use xhci_hcd driver as well. > >> This will help us know if the issue is with the pcie based USB > >> controllers or elsewhere. > >> > >> Also do you have another make of USB network adapter to try on? > >> > > > > The issue appears to be with the PCie based USB host controllers. I have no > failures using the native USB ports or ports with subtended USB hubs. We use > TUSB8041s on the product as well to expand the native ports. > > > > I have also replicated the problem using an Asus Ethernet USB adapter. > > How about trying the PCIe USB cards on a Linux PC? > This would identify if PCIe bus on AM5727 EVM is the culprit or not. I got a hold of the TI EVM for the TUSB7340 and setup a test using Ubuntu 16.04.03, 4.10.0-28-generic. There were no problems with the data testing. I pushed it even harder than AM5728 testing and the host remained up. So it is looking like it is an issue with the AM5728 PCI/PCIe. I'll take the problem back to TI. Roger, I'll contact you directly. Thanks for your help! > > > > >>> > >>> I've tried the 4.4.49, 4.12.3 and 4.13.1 kernels and they also fail. > >>> > >>> I tried the TI E2E support community and they
Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 14/09/17 16:53, Chris Welch wrote: >> -Original Message- >> From: Roger Quadros [mailto:rog...@ti.com] >> Sent: Thursday, September 14, 2017 6:38 AM >> To: Chris Welch <chris.we...@viavisolutions.com>; linux-usb@vger.kernel.org >> Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201 >> >> Chris, >> >> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y- >> tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >> >> On 13/09/17 17:26, Chris Welch wrote: >>> We are developing a product based on the TI AM5728 EVM. The product >> utilizes a TUSB7340 PCIe USB host for additional ports. The TUSB7340 is >> detected and setup properly and works OK with low data rate devices. >> However, hot plugging a Realtek USB network adapter and doing Ethernet >> transfer bandwidth testing using iperf3 causes the TUSB7340 host to be >> locked >> out. The TUSB7340 host appears to no longer communicate and the logging >> indicates xhci_hcd :01:00.0: HC died; cleaning up. Same issue occurs >> with >> another USB Ethernet adapter I tried (Asus). >>> >>> We looked at using another host and found a mini PCIe card that utilizes the >> µPD720201 and can be directly installed on the TI AM5728 EVM. The card is >> detected properly and we reran the transfer test. The uPD720201 gets locks >> out with the same problem. >>> >>> The AM5728 testing was performed using the TI SD card stock am57xx-evm- >> linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and it reports >> that it is using the TI AM572x EVM Rev A3 device tree. >>> >>> It shows the following logging when it fails (this is with the TI EVM and >> uPD720201). >>> >>> [ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop >> endpoint command. >>> [ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host. >>> [ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108 [ 630.425667] >>> r8152 2-4:1.0 enp1s0u4: Tx status -108 [ 630.430483] r8152 2-4:1.0 >>> enp1s0u4: Tx status -108 [ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx >>> status -108 [ 630.440122] xhci_hcd :01:00.0: HC died; cleaning up >>> [ 630.453961] usb 2-4: USB disconnect, device number 2 >>> >>> The problem appears to be a general driver issue given we get the same >> problem with both the TUSB7340 and the µPD720201. >> >> Can you try to reproduce the issue with the Realtek USB network adapter on >> the Native USB host port of AM5727 EVM. That happens to use xhci_hcd driver >> as well. >> This will help us know if the issue is with the pcie based USB controllers or >> elsewhere. >> >> Also do you have another make of USB network adapter to try on? >> > > The issue appears to be with the PCie based USB host controllers. I have no > failures using the native USB ports or ports with subtended USB hubs. We use > TUSB8041s on the product as well to expand the native ports. > > I have also replicated the problem using an Asus Ethernet USB adapter. How about trying the PCIe USB cards on a Linux PC? This would identify if PCIe bus on AM5727 EVM is the culprit or not. > >>> >>> I've tried the 4.4.49, 4.12.3 and 4.13.1 kernels and they also fail. >>> >>> I tried the TI E2E support community and they were unable to provide any >> solutions. >>> >>> Here is a sample session with the TUSB7340: >>> >>> root@arm:~# !iperf3 >>> iperf3 -c 10.14.21.95 -t 6000 >>> Connecting to host 10.14.21.95, port 5201 [ 4] local 10.14.21.89 port >>> 60978 connected to 10.14.21.95 port 5201 [ ID] Interval Transfer >>> Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 14.2 MBytes 119 Mbits/sec 1 >>> 1.41 KBytes [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >>> [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] >>> 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 4.00-5.00 >>> sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 5.00-6.00 sec 0.00 >>> Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 >>> bits/sec 0 1.41 KBytes ^C[ 4] 7.00-7.48 sec 0.00 Bytes 0.00 bits/sec 0 >>> 1.41 KBytes >>> - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval >>> Transfer Bandwidth Retr [ 4] 0.00-7.48 sec 14.2 MBytes 15.9 Mbits/sec >>> 1 sender [ 4] 0.00-7.48 sec 0.0
RE: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
> -Original Message- > From: Roger Quadros [mailto:rog...@ti.com] > Sent: Thursday, September 14, 2017 6:38 AM > To: Chris Welch <chris.we...@viavisolutions.com>; linux-usb@vger.kernel.org > Subject: Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201 > > Chris, > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y- > tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 13/09/17 17:26, Chris Welch wrote: > > We are developing a product based on the TI AM5728 EVM. The product > utilizes a TUSB7340 PCIe USB host for additional ports. The TUSB7340 is > detected and setup properly and works OK with low data rate devices. > However, hot plugging a Realtek USB network adapter and doing Ethernet > transfer bandwidth testing using iperf3 causes the TUSB7340 host to be locked > out. The TUSB7340 host appears to no longer communicate and the logging > indicates xhci_hcd :01:00.0: HC died; cleaning up. Same issue occurs with > another USB Ethernet adapter I tried (Asus). > > > > We looked at using another host and found a mini PCIe card that utilizes the > µPD720201 and can be directly installed on the TI AM5728 EVM. The card is > detected properly and we reran the transfer test. The uPD720201 gets locks > out with the same problem. > > > > The AM5728 testing was performed using the TI SD card stock am57xx-evm- > linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and it reports > that it is using the TI AM572x EVM Rev A3 device tree. > > > > It shows the following logging when it fails (this is with the TI EVM and > uPD720201). > > > > [ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop > endpoint command. > > [ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host. > > [ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108 [ 630.425667] > > r8152 2-4:1.0 enp1s0u4: Tx status -108 [ 630.430483] r8152 2-4:1.0 > > enp1s0u4: Tx status -108 [ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx > > status -108 [ 630.440122] xhci_hcd :01:00.0: HC died; cleaning up > > [ 630.453961] usb 2-4: USB disconnect, device number 2 > > > > The problem appears to be a general driver issue given we get the same > problem with both the TUSB7340 and the µPD720201. > > Can you try to reproduce the issue with the Realtek USB network adapter on > the Native USB host port of AM5727 EVM. That happens to use xhci_hcd driver > as well. > This will help us know if the issue is with the pcie based USB controllers or > elsewhere. > > Also do you have another make of USB network adapter to try on? > The issue appears to be with the PCie based USB host controllers. I have no failures using the native USB ports or ports with subtended USB hubs. We use TUSB8041s on the product as well to expand the native ports. I have also replicated the problem using an Asus Ethernet USB adapter. > > > > I've tried the 4.4.49, 4.12.3 and 4.13.1 kernels and they also fail. > > > > I tried the TI E2E support community and they were unable to provide any > solutions. > > > > Here is a sample session with the TUSB7340: > > > > root@arm:~# !iperf3 > > iperf3 -c 10.14.21.95 -t 6000 > > Connecting to host 10.14.21.95, port 5201 [ 4] local 10.14.21.89 port > > 60978 connected to 10.14.21.95 port 5201 [ ID] Interval Transfer > > Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 14.2 MBytes 119 Mbits/sec 1 > > 1.41 KBytes [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] > > 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 4.00-5.00 > > sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 5.00-6.00 sec 0.00 > > Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 > > bits/sec 0 1.41 KBytes ^C[ 4] 7.00-7.48 sec 0.00 Bytes 0.00 bits/sec 0 > > 1.41 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval > > Transfer Bandwidth Retr [ 4] 0.00-7.48 sec 14.2 MBytes 15.9 Mbits/sec > > 1 sender [ 4] 0.00-7.48 sec 0.00 Bytes 0.00 bits/sec receiver > > iperf3: interrupt - the client has terminated root@arm:~# [ > > 118.187204] xhci_hcd 0001:07:00.0: xHCI host controller not > > responding, assume dead [ 118.196419] xhci_hcd 0001:07:00.0: HC died; > > cleaning up > > > > Any suggestions on how we can address this problem? > > > > -- > > 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 > > > > -- > cheers, > -roger
Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201
Chris, Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 13/09/17 17:26, Chris Welch wrote: > We are developing a product based on the TI AM5728 EVM. The product utilizes > a TUSB7340 PCIe USB host for additional ports. The TUSB7340 is detected and > setup properly and works OK with low data rate devices. However, hot > plugging a Realtek USB network adapter and doing Ethernet transfer bandwidth > testing using iperf3 causes the TUSB7340 host to be locked out. The > TUSB7340 host appears to no longer communicate and the logging indicates > xhci_hcd :01:00.0: HC died; cleaning up. Same issue occurs with another > USB Ethernet adapter I tried (Asus). > > We looked at using another host and found a mini PCIe card that utilizes the > µPD720201 and can be directly installed on the TI AM5728 EVM. The card is > detected properly and we reran the transfer test. The uPD720201 gets locks > out with the same problem. > > The AM5728 testing was performed using the TI SD card stock > am57xx-evm-linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and > it reports that it is using the TI AM572x EVM Rev A3 device tree. > > It shows the following logging when it fails (this is with the TI EVM and > uPD720201). > > [ 630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop > endpoint command. > [ 630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host. > [ 630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108 > [ 630.425667] r8152 2-4:1.0 enp1s0u4: Tx status -108 > [ 630.430483] r8152 2-4:1.0 enp1s0u4: Tx status -108 > [ 630.435297] r8152 2-4:1.0 enp1s0u4: Tx status -108 > [ 630.440122] xhci_hcd :01:00.0: HC died; cleaning up > [ 630.453961] usb 2-4: USB disconnect, device number 2 > > The problem appears to be a general driver issue given we get the same > problem with both the TUSB7340 and the µPD720201. Can you try to reproduce the issue with the Realtek USB network adapter on the Native USB host port of AM5727 EVM. That happens to use xhci_hcd driver as well. This will help us know if the issue is with the pcie based USB controllers or elsewhere. Also do you have another make of USB network adapter to try on? > > I've tried the 4.4.49, 4.12.3 and 4.13.1 kernels and they also fail. > > I tried the TI E2E support community and they were unable to provide any > solutions. > > Here is a sample session with the TUSB7340: > > root@arm:~# !iperf3 > iperf3 -c 10.14.21.95 -t 6000 > Connecting to host 10.14.21.95, port 5201 > [ 4] local 10.14.21.89 port 60978 connected to 10.14.21.95 port 5201 > [ ID] Interval Transfer Bandwidth Retr Cwnd > [ 4] 0.00-1.00 sec 14.2 MBytes 119 Mbits/sec 1 1.41 KBytes > [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > ^C[ 4] 7.00-7.48 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth Retr > [ 4] 0.00-7.48 sec 14.2 MBytes 15.9 Mbits/sec 1 sender > [ 4] 0.00-7.48 sec 0.00 Bytes 0.00 bits/sec receiver > iperf3: interrupt - the client has terminated > root@arm:~# [ 118.187204] xhci_hcd 0001:07:00.0: xHCI host controller not > responding, assume dead > [ 118.196419] xhci_hcd 0001:07:00.0: HC died; cleaning up > > Any suggestions on how we can address this problem? > > -- > 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 > -- cheers, -roger -- 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
