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
On 15/4/2013 10:31 AM, Adrian Chadd
wrote:
well, those radm errors and local bus errors are actually pcie errors.
So look at PCIe errors with your bus analyser. :)
adrian
On 14 April 2013 19:07, Pannirselvam Kanagaratnam <[email protected]> wrote:
I have now tried 4 different chipsets on my board (AR9280, AR9287,
AR9380 and AR9382). Only AR9280 is failing. Debugfs interrupt stats is
as follows when using the AR9280:
SYNC_CAUSE stats:
Sync-All: 48
RTC-IRQ: 0
MAC-IRQ: 0
EEPROM-Illegal-Access: 0
APB-Timeout: 0
PCI-Mode-Conflict: 0
HOST1-Fatal: 0
HOST1-Perr: 0
TRCV-FIFO-Perr: 0
RADM-CPL-EP: 0
RADM-CPL-DLLP-Abort: 11
RADM-CPL-TLP-Abort: 0
RADM-CPL-ECRC-Err: 0
RADM-CPL-Timeout: 2
Local-Bus-Timeout: 35
PM-Access: 0
MAC-Awake: 0
MAC-Asleep: 0
MAC-Sleep-Access: 0
I have managed to get access to an Agilent Protocol Exerciser & Analyzer
(E2960A). Any tips on what I should be zooming into?
Regards,
Pannir
On 27/3/2013 11:27 AM, Pannirselvam Kanagaratnam wrote:
On 25/3/2013 12:39 AM, Felix Fietkau wrote:
On 2013-03-24 5:26 PM, Pannirselvam Kanagaratnam wrote:
Hello,
My WiFi connection drops while running the AR9280 on a Freescale
MPC8315E platform in AP mode with hostapd. I get the following error
within 15 seconds and the WiFi connection drops. However, I do not
observe any issues when using the AR9382. Can you let me know what
could
be causing this and if there is a workaround for this. I am using
Compat-Wireless-3.5.4.1.
I suggest updating to a more recent version of compat-wireless - 3.5.4.1
is quite old.
If a similar failure still occurs there, make sure you turn on
CONFIG_KALLSYMS so that the trace is not just a long list of meaningless
numbers.
- Felix
Here are my logs with Compat 3.9-rc2 and CONFIG_KALLSYMS enabled.
ath: phy0: Failed to stop TX DMA, queues=0x004!
ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x42000020 DMADBG_7=0x000062c0
ath: phy0: Could not stop RX, we could be confusing the DMA engine
when we start RX up
------------[ cut here ]------------
Badness at
/build/compat-wireless-3.9-rc2-2-su/drivers/net/wireless/ath/ath9k/recv.c:487
NIP: c9b72eec LR: c9b72ee0 CTR: c01bc900
REGS: c6c63e30 TRAP: 0700 Not tainted (2.6.35)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22002022 XER: 20000000
TASK = c7859360[930] 'phy0' THREAD: c6c62000
GPR00: 00000001 c6c63ee0 c7859360 0000004c 00005665 ffffffff c01b9e70
00004000
GPR08: 00000000 c9b90000 00005665 c046ad78 22002082 00000000 07ff9000
00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0000000a
GPR24: 00000000 c6c66b4c c6c68030 00000000 00000000 00000000 c6c68010
c6c65740
NIP [c9b72eec] ath_stoprecv+0x13c/0x154 [ath9k]
LR [c9b72ee0] ath_stoprecv+0x130/0x154 [ath9k]
Call Trace:
[c6c63ee0] [c9b72ee0] ath_stoprecv+0x130/0x154 [ath9k] (unreliable)
[c6c63f10] [c9b6ec20] ath_prepare_reset+0x54/0x90 [ath9k]
[c6c63f30] [c9b6ee90] ath_reset_internal+0x6c/0x220 [ath9k]
[c6c63f60] [c9b6f948] ath_reset+0x28/0x9c [ath9k]
[c6c63f80] [c0039398] worker_thread+0x108/0x1b0
[c6c63fc0] [c003d338] kthread+0x78/0x7c
[c6c63ff0] [c0010f08] kernel_thread+0x4c/0x68
Instruction dump:
2f800000 419eff74 809f0888 3c60c9b8 3ca0c9b8 38637194 38a572c8 38840020
4bec2125 3d20c9b9 88099475 68000001 <0f000000> 2f800000 419eff40 38000001
ath: phy0: Failed to stop TX DMA, queues=0x004!
ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x42000020 DMADBG_7=0x00006040
ath: phy0: Could not stop RX, we could be confusing the DMA engine
when we start RX up
Regards,
Pannir
_______________________________________________
ath9k-devel mailing list
[email protected]
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
|
_______________________________________________
ath9k-devel mailing list
[email protected]
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
