ath9k_hw: Handle AR_INTR_SYNC_HOST1_(FATAL|PERR) on AR9003

Interrupts with the sync_cause AR_INTR_SYNC_HOST1_FATAL has to be handled using a chip reset. Otherwise a interrupt storm with unhandled interrupts will cause a hang or crash of the machine.

Signed-off-by Sven Eckelmann <[email protected]>

---
I was informed that AR_INTR_SYNC_HOST1_PERR should not be handled this way because it can create system freezes after an adhoc interface was created.

I really need some Atheros developer who can check the documentation to verify the interpretation of these flags. Otherwise this is just guessing and may lead to even bigger problems.

 drivers/net/wireless/ath/ath9k/ar9003_mac.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/net/wireless/ath/ath9k/ar9003_mac.c +5 -1

index d5b2e0e..6031bdf 100644
@@ -311,6 +311,11 @@ static bool ar9003_hw_get_isr(struct ath_hw *ah, enum ath9k_int *masked)
        if (sync_cause) {
                ath9k_debug_sync_cause(common, sync_cause);
 
+               if (sync_cause & AR_INTR_SYNC_HOST1_FATAL) {
+                       ath_dbg(common, ANY, "received PCI FATAL interrupt\n");
+                       *masked |= ATH9K_INT_FATAL;
+               }
+
                if (sync_cause & AR_INTR_SYNC_RADM_CPL_TIMEOUT) {
                        REG_WRITE(ah, AR_RC, AR_RC_HOSTIF);
                        REG_WRITE(ah, AR_RC, 0);
--

1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

.. well, the rule here is "You shouldn't get PERR/FATAL interrupts."

Haven't I posted a summary of what those errors are?

Ok. So they're signals from the PCIe core (named host1_fatal and host1_perr. Helpfully.) Those errors occured during a DMA transfer.

So the question is why you're seeing PERR interrupts when creating an adhoc interface. That hints to me that something odd is going on..

I've seen these issues creep up when the NIC is in some way behaving very, very badly (lots of timeouts and sync errors with little to no traffic at all), which resulted in all kinds of odd and weird, unstable behaviour. After replacing the NIC with another NIC (in my case, an AR9280 -> AR9280 NIC :-) the errors went away and things continued swimmingly.

I'd have to go digging through the PCIe core source to figure out exactly what host1_peer and host1_fatal mean. I can if you'd like, it'll just take some time as I'm not familiar at all with the PCIe host interface.

.. well, the rule here is "You shouldn't get PERR/FATAL interrupts."

Haven't I posted a summary of what those errors are?

Ok. So they're signals from the PCIe core (named host1_fatal and host1_perr. Helpfully.) Those errors occured during a DMA transfer.

So the question is why you're seeing PERR interrupts when creating an adhoc interface. That hints to me that something odd is going on..

I've seen these issues creep up when the NIC is in some way behaving very, very badly (lots of timeouts and sync errors with little to no traffic at all), which resulted in all kinds of odd and weird, unstable behaviour. After replacing the NIC with another NIC (in my case, an AR9280 -> AR9280 NIC :-) the errors went away and things continued swimmingly.

I'd have to go digging through the PCIe core source to figure out exactly what host1_peer and host1_fatal mean. I can if you'd like, it'll just take some time as I'm not familiar at all with the PCIe host interface.

Thanks,

Adrian

Quoted 35 lines · Sven Eckelmann

Interrupts with the sync_cause AR_INTR_SYNC_HOST1_FATAL has to be handled using a chip reset. Otherwise a interrupt storm with unhandled interrupts will cause a hang or crash of the machine.

Signed-off-by Sven Eckelmann <[email protected]>

---
I was informed that AR_INTR_SYNC_HOST1_PERR should not be handled this way because it can create system freezes after an adhoc interface was created.

I really need some Atheros developer who can check the documentation to verify the interpretation of these flags. Otherwise this is just guessing and may lead to even bigger problems.

 drivers/net/wireless/ath/ath9k/ar9003_mac.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/net/wireless/ath/ath9k/ar9003_mac.c +5 -1

index d5b2e0e..6031bdf 100644
@@ -311,6 +311,11 @@ static bool ar9003_hw_get_isr(struct ath_hw *ah, enum ath9k_int *masked)
        if (sync_cause) {
                ath9k_debug_sync_cause(common, sync_cause);
 
+               if (sync_cause & AR_INTR_SYNC_HOST1_FATAL) {
+                       ath_dbg(common, ANY, "received PCI FATAL interrupt\n");
+                       *masked |= ATH9K_INT_FATAL;
+               }
+
                if (sync_cause & AR_INTR_SYNC_RADM_CPL_TIMEOUT) {
                        REG_WRITE(ah, AR_RC, AR_RC_HOSTIF);
                        REG_WRITE(ah, AR_RC, 0);
--

1.7.10.4

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hm, there are still issues on Hornet?

Quoted 1 line · On Tuesday 02 October 2012 07:06:03 Adrian Chadd wrote:

Hm, there are still issues on Hornet?

Yes, we still have problems with hornet. The issue I am trying to "fix" with this patch is an interrupt storm on AR9330 devices with sta interface(s). Random devices crash after getting a stacktrace reporting __report_bad_irq. The crash either results in a reboot or hang of the device

[  952.950000] irq 2: nobody cared (try booting with the "irqpoll" option)
[  952.950000] Call Trace:
[  952.950000] [<8026ade8>] dump_stack+0x8/0x34
[  952.950000] [<800a75d0>] __report_bad_irq+0x44/0xf4
[  952.950000] [<800a78ec>] note_interrupt+0x200/0x2a4
[  952.950000] [<800a58c8>] handle_irq_event_percpu+0x19c/0x1e0
[  952.950000] [<800a86cc>] handle_percpu_irq+0x54/0x88
[  952.950000] [<800a501c>] generic_handle_irq+0x3c/0x4c
[  952.950000] [<80064748>] do_IRQ+0x1c/0x34
[  952.950000] [<80062d6c>] ret_from_irq+0x0/0x4
[  952.950000] [<8007673c>] tasklet_action+0xb8/0xd4
[  952.950000] [<80076c24>] __do_softirq+0xa0/0x154
[  952.950000] [<80076e30>] do_softirq+0x48/0x68
[  952.950000] [<80076f94>] local_bh_enable+0x94/0xb0
[  952.950000] [<83406d60>] cfg80211_scan_done+0x670/0x6d0 [cfg80211]
[  952.950000] 
[  952.950000] handlers:
[  952.950000] [<83564d48>] ath_isr
[  952.950000] Disabling IRQ #2

The test setup is using 30 AR9330 devices running OpenWRT 32727/33559. 32727 is using compat-wireless-2012-04-17 (+ many OpenWRT patches) and 33559 is running compat-wireless-2012-09-07 (+many more patches from Felix). 1 device is running an open AP device (standard OpenWRT settings) and 29 devices are trying to connect. Random devices will now fail. To debug this problem, I used one devices with 8 vif devices and restarted the network script again and again to force the recreation of the vif and reconnect.

The stack trace doesn't seem to be very helpful. Therefore, I checked ath_isr and noticed that the interrupts right before the device crash get the status 0 from ar9003_hw_get_isr. Digging a little but further also revealed that the interrupts in the interrupt storm also have async_cause 0 and sync_cause 0x20.

This sync cause 0x20 isn't handled anywhere and may be the cause of the hang/crash. At least this is the symptom which can be fixed without crashing the system.

Quoted 3 lines

This sync cause 0x20 isn't handled anywhere and may be the cause of the hang/crash. At least this is the symptom which can be fixed without crashing the system.

I checked the AR933x datasheet, and it says that cause 0x20 is tx descriptor corruption.

Quoted 6 lines · Felix Fietkau

Quoted 3 lines

This sync cause 0x20 isn't handled anywhere and may be the cause of the hang/crash. At least this is the symptom which can be fixed without crashing the system.

I checked the AR933x datasheet, and it says that cause 0x20 is tx descriptor corruption.

Ah hey, for Hornet they redefined those bits:

5: MAC_TXC_CORRUPTION_FLAG_SYNC (TX descriptor integrity flag) 6: INVALID_ADDRESS_ACCESS (invalid register access)

Good catch. That's definitely something in the right direction.

Quoted 8 lines · On Wednesday 03 October 2012 07:51:28 Adrian Chadd wrote:

Quoted 6 lines · Felix Fietkau

Quoted 3 lines

This sync cause 0x20 isn't handled anywhere and may be the cause of the hang/crash. At least this is the symptom which can be fixed without crashing the system.

I checked the AR933x datasheet, and it says that cause 0x20 is tx descriptor corruption.

Quoted 6 lines

Ah hey, for Hornet they redefined those bits:

5: MAC_TXC_CORRUPTION_FLAG_SYNC (TX descriptor integrity flag) 6: INVALID_ADDRESS_ACCESS (invalid register access)

Good catch. That's definitely something in the right direction.

Ok, I've just created a dirty hack to trace some of the register reads/writes.

I used following test setup: Two Hornets, one is the "internet gateway" (just attached using ethernet to a test server) and is running one AP vif with standard OpenWRT settings. The other Hornet is placed next to it (only some centimeter far away) and is connected to the AP using WiFi.

The client device is just trying to download a large file using HTTP. The serial consoles on both devices will now print the "same" log. I already searched for the interesting section. It is started in ath_ani_calibrate and contains ~42 register access operations.

My best guess is the REG_RMW_FIELD for ATH9K_ANI_MRC_CCK in ar9003_hw_ani_control (just checked sync_cause before and after the access).

So, now I need some input again from the guis with the spec. :)

On 2012-10-05 1:08 PM, Sven Eckelmann wrote:

Please try this patch to see if it gets rid of these interrupts:
---

Quoted 1 line · On Friday 05 October 2012 14:34:28 Felix Fietkau wrote:

On 2012-10-05 1:08 PM, Sven Eckelmann wrote:

[...]

Quoted 5 lines

Please try this patch to see if it gets rid of these interrupts:
---

drivers/net/wireless/ath/ath9k/ani.c void ath9k_ani_reset(struct ath_hw *ah, · line 314

Quoted 9 lines

drivers/net/wireless/ath/ath9k/ani.c +2 -1

@@ -307,7 +307,8 @@ void ath9k_ani_reset(struct ath_hw *ah,
 		if (IS_CHAN_2GHZ(chan)) {
 			ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
 					    ATH9K_ANI_FIRSTEP_LEVEL);
-			if (AR_SREV_9300_20_OR_LATER(ah))
+			if (AR_SREV_9300_20_OR_LATER(ah) &&
+			    ah->caps.rx_chainmask != 1)
 				ah->ani_function |= ATH9K_ANI_MRC_CCK;
 		} else
 			ah->ani_function = 0;

Looks partially good. At least this patch fixed parts my friday :D

I have more similar bugs, but at least this one is related to a bandwidth problem which I also wanted to check today. But it didn't fix _this_ invalid register access on the client device (but I don't see it anymore on the AP device).

Quoted 28 lines · Sven Eckelmann

Quoted 1 line · On Friday 05 October 2012 14:34:28 Felix Fietkau wrote:

On 2012-10-05 1:08 PM, Sven Eckelmann wrote:

[...]

Quoted 11 lines

Please try this patch to see if it gets rid of these interrupts:
---

drivers/net/wireless/ath/ath9k/ani.c +0 -0

@@ -307,7 +307,8 @@ void ath9k_ani_reset(struct ath_hw *ah,
 
 		if (IS_CHAN_2GHZ(chan)) {
 
 			ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
 
 					    ATH9K_ANI_FIRSTEP_LEVEL);

drivers/net/wireless/ath/ath9k/ani.c void ath9k_ani_reset(struct ath_hw *ah, · line 314

Quoted 10 lines

drivers/net/wireless/ath/ath9k/ani.c +2 -1

 
-			if (AR_SREV_9300_20_OR_LATER(ah))
+			if (AR_SREV_9300_20_OR_LATER(ah) &&
+			    ah->caps.rx_chainmask != 1)
 
 				ah->ani_function |= ATH9K_ANI_MRC_CCK;
 
 		} else
 
 			ah->ani_function = 0;

Looks partially good. At least this patch fixed parts my friday :D

Quoted 4 lines

I have more similar bugs, but at least this one is related to a bandwidth problem which I also wanted to check today. But it didn't fix _this_ invalid register access on the client device (but I don't see it anymore on the AP device).

Are you sure that it's still the same register access on the client side? I don't see how it could still access MRC related registers with this part masked out.

Maybe it would make sense to come up with a debugging patch that checks the IRQ status register on every register access to see if an error was reported by the last one, and if there is an error, throw a stack trace.

Quoted 29 lines · On Friday 05 October 2012 15:24:25 Felix Fietkau wrote:

Quoted 28 lines · Sven Eckelmann

Quoted 1 line · On Friday 05 October 2012 14:34:28 Felix Fietkau wrote:

On 2012-10-05 1:08 PM, Sven Eckelmann wrote:

[...]

Quoted 11 lines

Please try this patch to see if it gets rid of these interrupts:
---

drivers/net/wireless/ath/ath9k/ani.c +0 -0

@@ -307,7 +307,8 @@ void ath9k_ani_reset(struct ath_hw *ah,
 
 		if (IS_CHAN_2GHZ(chan)) {
 
 			ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
 
 					    ATH9K_ANI_FIRSTEP_LEVEL);

drivers/net/wireless/ath/ath9k/ani.c void ath9k_ani_reset(struct ath_hw *ah,

Quoted 10 lines

drivers/net/wireless/ath/ath9k/ani.c +2 -1

 
-			if (AR_SREV_9300_20_OR_LATER(ah))
+			if (AR_SREV_9300_20_OR_LATER(ah) &&
+			    ah->caps.rx_chainmask != 1)
 
 				ah->ani_function |= ATH9K_ANI_MRC_CCK;
 
 		} else
 
 			ah->ani_function = 0;

Looks partially good. At least this patch fixed parts my friday :D

Quoted 8 lines

Quoted 4 lines

I have more similar bugs, but at least this one is related to a bandwidth problem which I also wanted to check today. But it didn't fix _this_ invalid register access on the client device (but I don't see it anymore on the AP device).

Are you sure that it's still the same register access on the client side? I don't see how it could still access MRC related registers with this part masked out.

Yes, I am sure. Let's read some code:

	if (ah->opmode == NL80211_IFTYPE_AP) {
		if (IS_CHAN_2GHZ(chan)) {
			ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
					    ATH9K_ANI_FIRSTEP_LEVEL);
			if (AR_SREV_9300_20_OR_LATER(ah) &&
			    ah->caps.rx_chainmask != 1)
				ah->ani_function |= ATH9K_ANI_MRC_CCK;
		} else
			ah->ani_function = 0;
	}

Now raise your hands when you see the "ah->opmode == NL80211_IFTYPE_AP". I've just added following after this block

	if (!AR_SREV_9300_20_OR_LATER(ah) || ah->caps.rx_chainmask == 1)
		ah->ani_function &= ~ATH9K_ANI_MRC_CCK;

But maybe it is better to fix the test in __ath9k_hw_init

	if (!AR_SREV_9300_20_OR_LATER(ah) || ah->caps.rx_chainmask == 1)
		ah->ani_function &= ~ATH9K_ANI_MRC_CCK;

The problem in __ath9k_hw_init is the value of ah->caps.rx_chainmask ... which is not yet initialized correctly (and therefore ends up as 0).

I've attached my "please don't enable MRC CCK" version of the patch. Feel free to submit it because you've submitted the initial version... or other things with it ;)

Thanks for testing, but for submitting I'd prefer something simple, how about this:
---

drivers/net/wireless/ath/ath9k/ani.c void ath9k_ani_reset(struct ath_hw *ah, · line 314

Quoted 13 lines · Felix Fietkau

---

drivers/net/wireless/ath/ath9k/ani.c +2 -1

@@ -307,7 +307,8 @@ void ath9k_ani_reset(struct ath_hw *ah,
                if (IS_CHAN_2GHZ(chan)) {
                        ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
                                            ATH9K_ANI_FIRSTEP_LEVEL);
-                       if (AR_SREV_9300_20_OR_LATER(ah))
+                       if (AR_SREV_9300_20_OR_LATER(ah) &&
+                           ah->caps.rx_chainmask != 1)
                                ah->ani_function |= ATH9K_ANI_MRC_CCK;
                } else
                        ah->ani_function = 0;

Well, is it a RX chainmask thing, or is it a chip thing?

It's totally possible to have an RX chainmask of say 0x2 or 0x4..

Also to figure out which registers triggered the interrupt is likely going to be a bit .. special. Maybe keep a circular buffer of the last N register accesses and dump them in time order whenever you get an interrupt.

Quoted 3 lines

Well, is it a RX chainmask thing, or is it a chip thing?

It's totally possible to have an RX chainmask of say 0x2 or 0x4..

What are you trying to tell us?

Maybe you missed that part of the conversation, but this was exactly what I did. You can even find one of my debug patches which implements it (but many fancy hacks are missing).

Quoted 5 lines · Sven Eckelmann

Quoted 3 lines

Well, is it a RX chainmask thing, or is it a chip thing?

It's totally possible to have an RX chainmask of say 0x2 or 0x4..

What are you trying to tell us?

That the check for "rx chainmask == 1? Definitely can't do MRC CCK" implying "rx chainmask != 1? Definitely can do MRC CCK." I think that's the wrong logic. It may be a general chipset problem across some/all AR9300 and later chips that doing MRC CCK with only one RX chain enabled is a problem, or it may be a single-chain NIC problem.

I'm pretty sure we can configure any of the RX antennas; it doesn't have to be "one chain == chain 0."

Anywy. I'll double check that.

Quoted 5 lines · Sven Eckelmann

Quoted 3 lines

Well, is it a RX chainmask thing, or is it a chip thing?

It's totally possible to have an RX chainmask of say 0x2 or 0x4..

What are you trying to tell us?

That the check for "rx chainmask == 1? Definitely can't do MRC CCK" implying "rx chainmask != 1? Definitely can do MRC CCK." I think that's the wrong logic. It may be a general chipset problem across some/all AR9300 and later chips that doing MRC CCK with only one RX chain enabled is a problem, or it may be a single-chain NIC problem.

I'm pretty sure we can configure any of the RX antennas; it doesn't have to be "one chain == chain 0."

Anywy. I'll double check that.

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 4:39 AM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Hm, that's quite a CC, for people who are mostly on the list :-)

How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC?

Adrian

the vap setup as following, I should add these into reproduce.sh.

phy phy0 interface add ath1 type __ap
iwconfig ath1 power off

phy phy0 interface add ath2 type __ap
iwconfig ath2 power off

yes, I was running two hostapds, one on each vap of a single phy.

Quoted 20 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 4:39 AM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Hm, that's quite a CC, for people who are mostly on the list :-)

How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC?

Adrian

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 1:16 PM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

And it doesn't happen with the same vap setup if you have one hostapd controlling both?

Adrian

Quoted 30 lines · Felix Liao

the vap setup as following, I should add these into reproduce.sh.

phy phy0 interface add ath1 type __ap
iwconfig ath1 power off

phy phy0 interface add ath2 type __ap
iwconfig ath2 power off

yes, I was running two hostapds, one on each vap of a single phy.

Quoted 20 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 4:39 AM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Hm, that's quite a CC, for people who are mostly on the list :-)

How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC?

Adrian

I just test this case about 4 hours, using one hostapd to driver these two APs, that is,

(quoted diff) +1 -2

-       hostapd hostapd1.conf -t -d -K 1> hostapd1.log &
-       hostapd hostapd2.conf -t -d -K 1> hostapd2.log &
+       hostapd hostapd1.conf hostapd2.conf -t -d -K 1> hostapd.log &

seems works well so far.

Quoted 49 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 1:16 PM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

And it doesn't happen with the same vap setup if you have one hostapd controlling both?

Adrian

Quoted 30 lines · Felix Liao

the vap setup as following, I should add these into reproduce.sh.

phy phy0 interface add ath1 type __ap
iwconfig ath1 power off

phy phy0 interface add ath2 type __ap
iwconfig ath2 power off

yes, I was running two hostapds, one on each vap of a single phy.

Quoted 20 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 4:39 AM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Hm, that's quite a CC, for people who are mostly on the list :-)

How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC?

Adrian

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 3:19 PM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Ok, that's a good debugging point. It means there's only one concurrent sending path.

Are you using a multi-core board? Can you try booting it single core and see if it still behaves this way?

Adrian

Quoted 28 lines · Felix Liao

I just test this case about 4 hours, using one hostapd to driver these two APs, that is,

(quoted diff) +1 -2

-       hostapd hostapd1.conf -t -d -K 1> hostapd1.log &
-       hostapd hostapd2.conf -t -d -K 1> hostapd2.log &
+       hostapd hostapd1.conf hostapd2.conf -t -d -K 1> hostapd.log &

seems works well so far.

Quoted 19 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 1:16 PM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

And it doesn't happen with the same vap setup if you have one hostapd controlling both?

Adrian

On 21 February 2013 17:19, Felix Liao <[email protected]>

Quoted 10 lines · wrote:

Quoted 10 lines

Quoted 10 lines

the vap setup as following, I should add these into reproduce.sh.

phy phy0 interface add ath1 type __ap iwconfig ath1 power off

phy phy0 interface add ath2 type __ap iwconfig ath2 power off

yes, I was running two hostapds, one on each vap of a single phy.

Quoted 2 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com]

On

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 4:39 AM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Hm, that's quite a CC, for people who are mostly on the list :-)

How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC?

Adrian

-----Original Message-----
From: Felix Liao
Sent: Friday, February 22, 2013 3:31 PM
To: 'Adrian Chadd'
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: RE: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

The CPU is only one core in my board.

Quoted 2 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On

Behalf

Quoted 20 lines

Of Adrian Chadd
Sent: Friday, February 22, 2013 3:19 PM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Ok, that's a good debugging point. It means there's only one concurrent sending path.

Are you using a multi-core board? Can you try booting it single core and see if it still behaves this way?

Adrian

On 21 February 2013 22:43, Felix Liao <[email protected]>

Quoted 59 lines · wrote:

Quoted 29 lines

I just test this case about 4 hours, using one hostapd to driver these two APs, that is,

(quoted diff) +2 -2

-       hostapd hostapd1.conf -t -d -K 1> hostapd1.log &
-       hostapd hostapd2.conf -t -d -K 1> hostapd2.log &
+       hostapd hostapd1.conf hostapd2.conf -t -d -K 1> hostapd.log
+ &

seems works well so far.

Quoted 19 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 1:16 PM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

And it doesn't happen with the same vap setup if you have one hostapd controlling both?

Adrian

On 21 February 2013 17:19, Felix Liao <[email protected]>

Quoted 10 lines · wrote:

Quoted 10 lines

Quoted 10 lines

the vap setup as following, I should add these into reproduce.sh.

phy phy0 interface add ath1 type __ap iwconfig ath1 power off

phy phy0 interface add ath2 type __ap iwconfig ath2 power off

yes, I was running two hostapds, one on each vap of a single phy.

Quoted 2 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com]

On

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Quoted 18 lines

Behalf Of Adrian Chadd
Sent: Friday, February 22, 2013 4:39 AM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Hm, that's quite a CC, for people who are mostly on the list :-)

How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC?

Adrian

-----Original Message-----
From: Felix Liao
Sent: Friday, February 22, 2013 9:20 AM
To: 'Adrian Chadd'
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: RE: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

the vap setup as following, I should add these into reproduce.sh.

phy phy0 interface add ath1 type __ap
iwconfig ath1 power off

phy phy0 interface add ath2 type __ap
iwconfig ath2 power off

yes, I was running two hostapds, one on each vap of a single phy.

Quoted 2 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On

Behalf

Quoted 18 lines

Of Adrian Chadd
Sent: Friday, February 22, 2013 4:39 AM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Hm, that's quite a CC, for people who are mostly on the list :-)

How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC?

Adrian

-----Original Message-----
From: Felix Liao
Sent: Friday, February 22, 2013 9:33 AM
To: 'Adrian Chadd'
Cc: 'ath9k-devel at lists.ath9k.org'; 'lindner_marek at yahoo.de'; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: RE: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

indeed, in order to set vap power off, I just create a station vap and set power off then change its type to AP.

reproduce.sh +11 -0

index 7f7ce2a..05a6410
@@ -14,6 +14,17 @@ brctl addif eth1-bridge eth1
 brctl addif eth2-bridge eth2
 brctl addif eth3-bridge eth3
 
+iw dev ath1 del
+iw dev ath2 del
+
+iw phy phy0 interface add ath1 type station
+iwconfig ath1 power off
+iw dev ath1 set type __ap
+
+iw phy phy0 interface add ath2 type station
+iwconfig ath2 power off
+iw dev ath1 set type __ap
+
 dmesg -c > dmesg_boot.log
 while [ 1 ]
 do

Quoted 15 lines

-----Original Message-----
From: Felix Liao
Sent: Friday, February 22, 2013 9:20 AM
To: 'Adrian Chadd'
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao; Hao Wang; Bryan Phillippe
Subject: RE: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

the vap setup as following, I should add these into reproduce.sh.

phy phy0 interface add ath1 type __ap
iwconfig ath1 power off

Quoted 12 lines

phy phy0 interface add ath2 type __ap
iwconfig ath2 power off

yes, I was running two hostapds, one on each vap of a single phy.

Quoted 2 lines

-----Original Message-----
From: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] On

Behalf

Quoted 4 lines

Of Adrian Chadd
Sent: Friday, February 22, 2013 4:39 AM
To: Felix Liao
Cc: ath9k-devel at lists.ath9k.org; lindner_marek at yahoo.de; Joe Qiao;

Hao

Quoted 14 lines

Quoted 14 lines

Wang; Bryan Phillippe
Subject: Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

Hm, that's quite a CC, for people who are mostly on the list :-)

How's the vap setup look? Are you running two hostapds, one on each vap of a single card? Or is it two hostaps, each one to a separate vap on a separate NIC?

Adrian