[ath9k-devel] WiFi Failure with AR9280

[Pannirselvam Kanagaratnam <pannir@xsmail.com>]

Hello,

I have created a bug report at:
https://bugzilla.kernel.org/show_bug.cgi?id=56991

Thanks for your support.

Regards,

Pannir

On 22/4/2013 4:38 PM, Adrian Chadd wrote:
> Hi,
>
> Please wrap all of this up in a bug report at bugzilla.kernel.org .
>
> I'll then punt it around internally to see if someone can dig up
> what's going on.
>
> Thanks,
>
>
>
> Adrian
>
> On 22 April 2013 00:41, Pannirselvam Kanagaratnam <pannir@xsmail.com> wrote:
>> Hello,
>>
>> I am using the latest revision and the chip vendor has confirmed that the
>> errata is applicable to the latest revision.
>>
>> I analyzed the behaviour of the AR9287 and AR9380 and found the following
>> when encountering the "Completion with Data" packet with LCRC errors:
>>
>> 1) AR9280: Completion Timeout bit: 1. Bad TLP bit: 1.
>> 2) AR9287: Completion Timeout bit: 0. Bad TLP bit: 1.
>> 3) AR9380: Completion Timeout bit: 0. Bad TLP bit: 0.
>>
>> I can get > 90 Mbps on both the AR9287 and AR9380. Is there a way to disable
>> the completion timeout on the AR9280? Can you point me to the code which
>> handles the transaction timeout and transaction retries? Is this the PCIe
>> host interface code you were referring to?
>>
>> Thank you.
>>
>> Pannir
>>
>>
>> On 19/4/2013 2:36 PM, Adrian Chadd wrote:
>>> Hi,
>>>
>>> Thanks for digging into this!
>>>
>>> Unfortunately going digging through the PCIe host interface code will
>>> take too much time and I just don't have the time to spare at the
>>> moment.
>>>
>>> There _may_ be a workaround? But it's also equally likely that it was
>>> just fixed in later revisions of the chip so to be more tolerant with
>>> known buggy PCIe implementations.
>>>
>>> I think the host interface glue has a transaction timeout and
>>> transaction retry counter. I'm not sure what the details are though
>>> and whether or not it'll help here.
>>>
>>>
>>>
>>> Adrian
>>>
>>> On 18 April 2013 03:16, Pannirselvam Kanagaratnam <pannir@xsmail.com>
>>> wrote:
>>>> Hello,
>>>>
>>>> Upon analyzing the Protocol Analyzer I shared my finding with the CPU
>>>> chipset support. They said it is an errata on their CPU. It reads as
>>>> follows:
>>>>
>>>> **********************************
>>>>
>>>> PCI Express Packets may be transmitted with excess data on x1 link
>>>> Description: An internal error in the PCI Express controller may cause 8
>>>> bytes of packet header or data
>>>> payload to be duplicated on transmit. Depending on the location of the
>>>> duplicate bytes, this
>>>> may cause a malformed packet error or CRC error detected in the link
>>>> partner.
>>>>
>>>> Impact: A PCI Express link partner may see excess correctable errors or
>>>> malformed packets in x1
>>>> links.
>>>>
>>>> Note that any PCI Express specification-compliant recipient at the
>>>> ultimate
>>>> end of the
>>>> transaction may only recognize the erroneous packet as a Bad TLP and flag
>>>> the error as
>>>> correctable due to the LCRC error. It should respond with a NAK and then
>>>> wait for the device
>>>> to re-try the packet. The ultimate recipient should not recognize the
>>>> erroneous packet as a
>>>> Malformed TLP, since before reaching the transaction layer the Bad TLP
>>>> should have been
>>>> discarded by the ultimate recipient?s link layer.
>>>>
>>>> **********************************
>>>>
>>>> I have noticed that although the error occurs, the AR9287, AR9380 and
>>>> AR9382
>>>> are able to handle this. However, the AR9280 link fails. Is there
>>>> something
>>>> that can be done on the driver level to manage this?
>>>>
>>>> You may take a look at the analyzer logs at:
>>>> http://www.yousendit.com/download/UVJqaUNITWNtUUZBSXNUQw
>>>>
>>>> You will need the Analyzer software to read it:
>>>>
>>>> ftp://ftp.agilent.com/cos/outbound/PCIe_Gen2/Analyzer/6.13%20for%20Gen1%20anlyzer/
>>>>
>>>> The record in question is # 3957101. It is Completion with Data for the
>>>> Memory Read request by the EP at record #3957098. This packet was NAK by
>>>> the
>>>> EP and so there was a replay of this packet. The reason for NAK was that
>>>> some extra bytes were inserted and transmitted by RC.
>>>>
>>>> Regards,
>>>>
>>>> Pannir
>>>>