* [ath9k-devel] WiFi Failure with AR9280 @ 2013-03-24 16:26 Pannirselvam Kanagaratnam 2013-03-24 16:39 ` Felix Fietkau 0 siblings, 1 reply; 10+ messages in thread From: Pannirselvam Kanagaratnam @ 2013-03-24 16:26 UTC (permalink / raw) To: ath9k-devel 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. 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 /compat-wireless-3.5.4-1/drivers/net/wireless/ath/ath9k/recv.c:531 NIP: c9adabe0 LR: c9adabd4 CTR: c01b8068 REGS: c7b47e30 TRAP: 0700 Not tainted (2.6.35) MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22002022 XER: 20000000 TASK = c783db20[916] 'phy0' THREAD: c7b46000 GPR00: 00000001 c7b47ee0 c783db20 0000004c 00005554 ffffffff c01b55d8 00004000 GPR08: 00000000 c9af0000 00005554 c03f4d58 22002082 100b1254 07ff9000 00000000 GPR16: 100a9c50 00000000 00000000 00000000 00000000 00000000 00000000 100a9048 GPR24: 00000000 c7b4a6cc 00000000 00000001 00000001 00000000 c7b49720 c7b4c000 Call Trace: [c7b47ee0] [c9adabd4] 0xc9adabd4 (unreliable) [c7b47f10] [c9ad547c] 0xc9ad547c [c7b47f30] [c9ad5eec] 0xc9ad5eec [c7b47f60] [c9ad64e0] 0xc9ad64e0 [c7b47f80] [c003939c] 0xc003939c [c7b47fc0] [c003d328] 0xc003d328 [c7b47ff0] [c0010f08] 0xc0010f08 Instruction dump: 4082ffac 3c60c9af 3ca0c9af 3863b45c 38a5b590 419eff98 809e0888 3884001c 4beeb431 3d20c9af 8809d59c 68000001 <0f000000> 2f800000 419eff74 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 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-03-24 16:26 [ath9k-devel] WiFi Failure with AR9280 Pannirselvam Kanagaratnam @ 2013-03-24 16:39 ` Felix Fietkau 2013-03-27 3:27 ` Pannirselvam Kanagaratnam 0 siblings, 1 reply; 10+ messages in thread From: Felix Fietkau @ 2013-03-24 16:39 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-03-24 16:39 ` Felix Fietkau @ 2013-03-27 3:27 ` Pannirselvam Kanagaratnam 2013-04-15 2:07 ` Pannirselvam Kanagaratnam 0 siblings, 1 reply; 10+ messages in thread From: Pannirselvam Kanagaratnam @ 2013-03-27 3:27 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-03-27 3:27 ` Pannirselvam Kanagaratnam @ 2013-04-15 2:07 ` Pannirselvam Kanagaratnam 2013-04-15 2:31 ` Adrian Chadd 0 siblings, 1 reply; 10+ messages in thread From: Pannirselvam Kanagaratnam @ 2013-04-15 2:07 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-04-15 2:07 ` Pannirselvam Kanagaratnam @ 2013-04-15 2:31 ` Adrian Chadd 2013-04-18 10:16 ` Pannirselvam Kanagaratnam 0 siblings, 1 reply; 10+ messages in thread From: Adrian Chadd @ 2013-04-15 2:31 UTC (permalink / raw) To: ath9k-devel 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 <pannir@xsmail.com> 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 > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-04-15 2:31 ` Adrian Chadd @ 2013-04-18 10:16 ` Pannirselvam Kanagaratnam 2013-04-19 6:36 ` Adrian Chadd 0 siblings, 1 reply; 10+ messages in thread From: Pannirselvam Kanagaratnam @ 2013-04-18 10:16 UTC (permalink / raw) To: ath9k-devel An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130418/90640813/attachment.htm ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-04-18 10:16 ` Pannirselvam Kanagaratnam @ 2013-04-19 6:36 ` Adrian Chadd 2013-04-22 7:41 ` Pannirselvam Kanagaratnam 0 siblings, 1 reply; 10+ messages in thread From: Adrian Chadd @ 2013-04-19 6:36 UTC (permalink / raw) To: ath9k-devel 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 > > > 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 <pannir@xsmail.com> 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 > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-04-19 6:36 ` Adrian Chadd @ 2013-04-22 7:41 ` Pannirselvam Kanagaratnam 2013-04-22 8:38 ` Adrian Chadd 0 siblings, 1 reply; 10+ messages in thread From: Pannirselvam Kanagaratnam @ 2013-04-22 7:41 UTC (permalink / raw) To: ath9k-devel 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 >> ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-04-22 7:41 ` Pannirselvam Kanagaratnam @ 2013-04-22 8:38 ` Adrian Chadd 2013-04-22 14:58 ` Pannirselvam Kanagaratnam 0 siblings, 1 reply; 10+ messages in thread From: Adrian Chadd @ 2013-04-22 8:38 UTC (permalink / raw) To: ath9k-devel 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 >>> > ^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] WiFi Failure with AR9280 2013-04-22 8:38 ` Adrian Chadd @ 2013-04-22 14:58 ` Pannirselvam Kanagaratnam 0 siblings, 0 replies; 10+ messages in thread From: Pannirselvam Kanagaratnam @ 2013-04-22 14:58 UTC (permalink / raw) To: ath9k-devel 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 >>>> ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-04-22 14:58 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-24 16:26 [ath9k-devel] WiFi Failure with AR9280 Pannirselvam Kanagaratnam 2013-03-24 16:39 ` Felix Fietkau 2013-03-27 3:27 ` Pannirselvam Kanagaratnam 2013-04-15 2:07 ` Pannirselvam Kanagaratnam 2013-04-15 2:31 ` Adrian Chadd 2013-04-18 10:16 ` Pannirselvam Kanagaratnam 2013-04-19 6:36 ` Adrian Chadd 2013-04-22 7:41 ` Pannirselvam Kanagaratnam 2013-04-22 8:38 ` Adrian Chadd 2013-04-22 14:58 ` Pannirselvam Kanagaratnam
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.