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 <pan...@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 >> _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
