[ath9k-devel] WiFi Failure with AR9280

[ath9k-devel] WiFi Failure with AR9280

[Pannirselvam Kanagaratnam]

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

[ath9k-devel] WiFi Failure with AR9280

[Felix Fietkau]

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

[ath9k-devel] WiFi Failure with AR9280

[Pannirselvam Kanagaratnam]

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] WiFi Failure with AR9280

[Pannirselvam Kanagaratnam]

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] WiFi Failure with AR9280

[Adrian Chadd]

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

[ath9k-devel] WiFi Failure with AR9280

[Pannirselvam Kanagaratnam]

An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130418/90640813/attachment.htm 

[ath9k-devel] WiFi Failure with AR9280

[Adrian Chadd]

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
>
>

[ath9k-devel] WiFi Failure with AR9280

[Pannirselvam Kanagaratnam]

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
>>

[ath9k-devel] WiFi Failure with AR9280

[Adrian Chadd]

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
>>>
>

[ath9k-devel] WiFi Failure with AR9280

[Pannirselvam Kanagaratnam]

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
>>>>