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 <[email protected]> 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 <[email protected]> >>> 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 >>>> _______________________________________________ ath9k-devel mailing list [email protected] https://lists.ath9k.org/mailman/listinfo/ath9k-devel
