Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003
unlucky! it is still reproduced now when I using one hostapd to driver two APs. > -Original Message- > From: Felix Liao > Sent: Friday, February 22, 2013 3:31 PM > To: 'Adrian Chadd' > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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. > > > -Original Message- > > From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > Behalf > > Of Adrian Chadd > > Sent: Friday, February 22, 2013 3:19 PM > > To: Felix Liao > > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 > wrote: > > > I just test this case about 4 hours, using one hostapd to driver > > > these two APs, that is, > > > > > > - 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. > > > > > >> -Original Message- > > >> From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > > >> Behalf Of Adrian Chadd > > >> Sent: Friday, February 22, 2013 1:16 PM > > >> To: Felix Liao > > >> Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 > > wrote: > > >> > 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. > > >> > > > >> >> -Original Message- > > >> >> From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] > > On > > >> >> Behalf Of Adrian Chadd > > >> >> Sent: Friday, February 22, 2013 4:39 AM > > >> >> To: Felix Liao > > >> >> Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003
The CPU is only one core in my board. > -Original Message- > From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > Behalf Of Adrian Chadd > Sent: Friday, February 22, 2013 3:19 PM > To: Felix Liao > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 wrote: > > I just test this case about 4 hours, using one hostapd to driver these > > two APs, that is, > > > > - 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. > > > >> -Original Message----- > >> From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > >> Behalf Of Adrian Chadd > >> Sent: Friday, February 22, 2013 1:16 PM > >> To: Felix Liao > >> Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 > wrote: > >> > 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. > >> > > >> >> -Original Message- > >> >> From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] > On > >> >> Behalf Of Adrian Chadd > >> >> Sent: Friday, February 22, 2013 4:39 AM > >> >> To: Felix Liao > >> >> Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003
I just test this case about 4 hours, using one hostapd to driver these two APs, that is, - 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. > -Original Message- > From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > Behalf Of Adrian Chadd > Sent: Friday, February 22, 2013 1:16 PM > To: Felix Liao > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 wrote: > > 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. > > > >> -Original Message- > >> From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > >> Behalf Of Adrian Chadd > >> Sent: Friday, February 22, 2013 4:39 AM > >> To: Felix Liao > >> Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003
I also test the following patches, but they can't resolve my problem. [46/93] ath9k_hw: fix chain swap setting when setting rx chainmask to 5 http://patchwork.ozlabs.org/patch/218409/ [45/93] ath9k_hw: fix calibration issues on chainmask that don't include chain 0 http://patchwork.ozlabs.org/patch/218408/ [39/93] ath9k: disable the tasklet before taking the PCU lock http://patchwork.ozlabs.org/patch/218403/ [38/93] ath9k: remove sc->rx.rxbuflock to fix a deadlock http://patchwork.ozlabs.org/patch/218402/ [36/93] ath9k: fix rx flush handling http://patchwork.ozlabs.org/patch/218400/ [35/93] ath9k: add a better fix for the rx tasklet vs rx flush race http://patchwork.ozlabs.org/patch/218399/ [34/93] ath9k: do not link receive buffers during flush http://patchwork.ozlabs.org/patch/218398/ [049/270] ath9k: use ieee80211_free_txskb http://patchwork.ozlabs.org/patch/201782/ > -Original Message----- > From: Felix Liao > Sent: Friday, February 22, 2013 9:33 AM > To: 'Adrian Chadd' > Cc: 'ath9k-devel@lists.ath9k.org'; 'lindner_ma...@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. > > diff --git a/reproduce.sh b/reproduce.sh > index 7f7ce2a..05a6410 > --- a/reproduce.sh > +++ b/reproduce.sh > @@ -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 > > > -Original Message- > > From: Felix Liao > > Sent: Friday, February 22, 2013 9:20 AM > > To: 'Adrian Chadd' > > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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. > > > > > -Original Message- > > > From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > > Behalf > > > Of Adrian Chadd > > > Sent: Friday, February 22, 2013 4:39 AM > > > To: Felix Liao > > > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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. diff --git a/reproduce.sh b/reproduce.sh index 7f7ce2a..05a6410 --- a/reproduce.sh +++ b/reproduce.sh @@ -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 > -Original Message- > From: Felix Liao > Sent: Friday, February 22, 2013 9:20 AM > To: 'Adrian Chadd' > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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. > > > -Original Message- > > From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > Behalf > > Of Adrian Chadd > > Sent: Friday, February 22, 2013 4:39 AM > > To: Felix Liao > > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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. > -Original Message- > From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On > Behalf Of Adrian Chadd > Sent: Friday, February 22, 2013 4:39 AM > To: Felix Liao > Cc: ath9k-devel@lists.ath9k.org; lindner_ma...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ
Hi Felix F, I'm Felix Liao from WatchGuard, I think we should spin_lock_irqsave and spin_unlock_irqrestore on sc_pcu_lock in the ath9k_tasklet() instead of spin_lock/spin_unlock, just to avoid the tasklet being interrupted by the hardware IRQ, do you think so? Thanks, - Felix Liao -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: Sunday, November 18, 2012 10:11 PM To: Felix Liao; Felix Fietkau Cc: ath9k-devel@lists.ath9k.org Subject: Re: [ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ On 12 November 2012 01:54, Felix Liao wrote: > Thanks for you information. > It is running in AP mode, and uses compat-wireless-3.5-3, but the "irq 16: > nobody cared" issue still happens when I update to compat-wireless-3.6.6-1. > I found a mail list talk about this, > https://patchwork.kernel.org/patch/1536701/, I see this patch not in 3.6.6-1, > and just set the mask to ATH9K_INT_FATAL, then the ath_isr() will just reset > the hardware, it is just same with what I think in my mind, and I will take a > try for it. > > Another question I said, do you think we should spin_lock_irqsave and > spin_unlock_irqrestore in the ath9k_tasklet instead of spin_lock/spin_unlock? That's a question for someone with a more intimate knowledge of the current workings of ath9k. Felix (F) - would you mind taking a look at this thread? He's having issues with fatal sync interrupts not causing the NIC to be reset? Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ
Thanks for you information.
It is running in AP mode, and uses compat-wireless-3.5-3, but the "irq 16:
nobody cared" issue still happens when I update to compat-wireless-3.6.6-1.
I found a mail list talk about this,
https://patchwork.kernel.org/patch/1536701/, I see this patch not in 3.6.6-1,
and just set the mask to ATH9K_INT_FATAL,
then the ath_isr() will just reset the hardware, it is just same with what I
think in my mind, and I will take a try for it.
Another question I said, do you think we should spin_lock_irqsave and
spin_unlock_irqrestore in the ath9k_tasklet instead of spin_lock/spin_unlock?
Thanks,
- Felix
-Original Message-
From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of
Adrian Chadd
Sent: Monday, November 12, 2012 5:44 PM
To: Felix Liao
Cc: ath9k-devel@lists.ath9k.org
Subject: Re: [ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ
Well, any sync error like that where the PCIe glue throws an error like that is
a bad thing.
It could be from a variety of places. It could be a busted PCIe interconnect
somehow. I've seen this happen before. The only real way to diagnose that is to
grab a PCIe bus analyser.
It however could also be from the NIC going in and out of network sleep. Is
this in STA or AP mode?
Adrian
On 12 November 2012 01:06, Felix Liao wrote:
> Hi ath9k team,
> I trace the ath9k_hw_getisr() today to find out why I get the zero ISR
> mask, and I found that when I get the zero ISR mask, this function
> return the boolean true, then I trace into the function
> ar9003_hw_get_isr(),
>
> static bool ar9003_hw_get_isr(struct ath_hw *ah, enum ath9k_int
> *masked) {
>
> async_cause = REG_READ(ah, AR_INTR_ASYNC_CAUSE);
>
> if (async_cause & (AR_INTR_MAC_IRQ | AR_INTR_ASYNC_MASK_MCI)) {
> if ((REG_READ(ah, AR_RTC_STATUS) & AR_RTC_STATUS_M)
> == AR_RTC_STATUS_ON)
> isr = REG_READ(ah, AR_ISR);
> }
>
>
> sync_cause = REG_READ(ah, AR_INTR_SYNC_CAUSE) &
> AR_INTR_SYNC_DEFAULT;
>
> *masked = 0;
>
> if (!isr && !sync_cause && !async_cause)
> return false;
>
> if (isr == 0) {
> //debug value here is isr=0, async_cause=0, sync_cause=0x20
> --> AR_INTR_SYNC_HOST1_FATAL
> }
> ...
> }
>
> I have no idea why I always get the isr=0 and sync_cause=0x20 which means
> AR_INTR_SYNC_HOST1_FATAL, but we can't deal with this value in the source
> code, do you know any about this?
>
> Thanks,
> - Felix
>
> -Original Message-
> From: Felix Liao
> Sent: Monday, November 12, 2012 10:10 AM
> To: 'ath9k-devel@lists.ath9k.org'
> Subject: RE: ath9k_tasklet() can be interrupted by a hardware IRQ
>
> Hi ath9k team:
> Another interest question is since the ath9k interrupt was disabled, how can
> we get a new IRQ to interrupt the tasklet?
> So I investigated and found that the cause of the issue "irq 16: nobody
> cared" in my box is the ath9k's irq handler return too many IRQ_NONE since I
> read the ISR register always return 0 as below.
>
> /*
> * Figure out the reason(s) for the interrupt. Note
> * that the hal returns a pseudo-ISR that may include
> * bits we haven't explicitly enabled so we mask the
> * value to insure we only process bits we requested.
> */
> ath9k_hw_getisr(ah, &status); /* NB: clears ISR too */
> status &= ah->imask;/* discard unasked-for bits */
>
> /*
> * If there are no status bits set, then this interrupt was not
> * for me (should have been caught above).
> */
> if (!status)
> return IRQ_NONE;
>
> if I go to reset chip instead of return IRQ_NONE in this position, the things
> become a little healthier than before, I will never see the message "irq 16:
> nobody cared".
>
> I check each IRQ using "if(AR_SREV_9300(ah))" and they are all passed, that
> is, no other hardware share the irq with ath9k.
> I need to know why we read the ISR register and get value 0, and return
> IRQ_NONE, the chip I used is AR9300.
> Can we using this change below in the ath_isr() function:
> if (!status)
> goto reset_chip;
>
> Thanks,
> - Felix
> -
> From: Felix Liao
> Sent: Friday, November 09, 2012 9:33 AM
> To: 'ath9k-devel@lists.ath9k.org'
> Subject: ath9k_tasklet() can be interrupted by a hardware IRQ
>
> Hi all,
> I met a kernel call trace below using the ath9k driver, we can see that the
Re: [ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ
Hi ath9k team,
I trace the ath9k_hw_getisr() today to find out why I get the zero ISR mask,
and I found that when I get the zero ISR mask, this function return the boolean
true, then I trace into the function ar9003_hw_get_isr(),
static bool ar9003_hw_get_isr(struct ath_hw *ah, enum ath9k_int *masked)
{
async_cause = REG_READ(ah, AR_INTR_ASYNC_CAUSE);
if (async_cause & (AR_INTR_MAC_IRQ | AR_INTR_ASYNC_MASK_MCI)) {
if ((REG_READ(ah, AR_RTC_STATUS) & AR_RTC_STATUS_M)
== AR_RTC_STATUS_ON)
isr = REG_READ(ah, AR_ISR);
}
sync_cause = REG_READ(ah, AR_INTR_SYNC_CAUSE) & AR_INTR_SYNC_DEFAULT;
*masked = 0;
if (!isr && !sync_cause && !async_cause)
return false;
if (isr == 0) {
//debug value here is isr=0, async_cause=0, sync_cause=0x20 -->
AR_INTR_SYNC_HOST1_FATAL
}
...
}
I have no idea why I always get the isr=0 and sync_cause=0x20 which means
AR_INTR_SYNC_HOST1_FATAL, but we can't deal with this value in the source code,
do you know any about this?
Thanks,
- Felix
-----Original Message-
From: Felix Liao
Sent: Monday, November 12, 2012 10:10 AM
To: 'ath9k-devel@lists.ath9k.org'
Subject: RE: ath9k_tasklet() can be interrupted by a hardware IRQ
Hi ath9k team:
Another interest question is since the ath9k interrupt was disabled, how can we
get a new IRQ to interrupt the tasklet?
So I investigated and found that the cause of the issue "irq 16: nobody cared"
in my box is the ath9k's irq handler return too many IRQ_NONE since I read the
ISR register always return 0 as below.
/*
* Figure out the reason(s) for the interrupt. Note
* that the hal returns a pseudo-ISR that may include
* bits we haven't explicitly enabled so we mask the
* value to insure we only process bits we requested.
*/
ath9k_hw_getisr(ah, &status); /* NB: clears ISR too */
status &= ah->imask;/* discard unasked-for bits */
/*
* If there are no status bits set, then this interrupt was not
* for me (should have been caught above).
*/
if (!status)
return IRQ_NONE;
if I go to reset chip instead of return IRQ_NONE in this position, the things
become a little healthier than before, I will never see the message "irq 16:
nobody cared".
I check each IRQ using "if(AR_SREV_9300(ah))" and they are all passed, that is,
no other hardware share the irq with ath9k.
I need to know why we read the ISR register and get value 0, and return
IRQ_NONE, the chip I used is AR9300.
Can we using this change below in the ath_isr() function:
if (!status)
goto reset_chip;
Thanks,
- Felix
-
From: Felix Liao
Sent: Friday, November 09, 2012 9:33 AM
To: 'ath9k-devel@lists.ath9k.org'
Subject: ath9k_tasklet() can be interrupted by a hardware IRQ
Hi all,
I met a kernel call trace below using the ath9k driver, we can see that the
ath9k_tasklet() was interrupted by a hardware IRQ, and at this time the ath9k
IRQ was disabled, so the kernel will complain that there is none irq handler
for this interrupt.
[ 60.977474] irq 16: nobody cared (try booting with the "irqpoll" option) [
60.984194] Call Trace:
[ 60.986660] [dfff1f50] [c000843c] show_stack+0x70/0x1c8 (unreliable) [
60.993041] [dfff1f90] [c00777a0] __report_bad_irq+0x44/0xe8 [ 60.998718]
[dfff1fb0] [c0077a44] note_interrupt+0x200/0x260 [ 61.004396] [dfff1fe0]
[c0078704] handle_fasteoi_irq+0xc4/0x10c [ 61.010340] [dfff1ff0] [c0010fdc]
call_handle_irq+0x18/0x28 [ 61.015929] [dfff3e50] [c00051c8]
do_IRQ+0xcc/0x1b4 [ 61.020825] [dfff3e80] [c0011fc4] ret_from_except+0x0/0x18
[ 61.026349] --- Exception: 501 at ioread32+0x8/0x14 [ 61.026355] LR =
ath_descdma_setup+0x294/0x664 [ath9k] [ 61.036733] [dfff3f40] [c04f5bdc]
softirq_to_name+0x0/0x28 (unreliable) [ 61.043390] [dfff3f50] [e5ad66fc]
ath9k_hw_enable_interrupts+0x160/0x1b0 [ath9k_hw] [ 61.051074] [dfff3f70]
[e5b41368] ath9k_tasklet+0xc0/0x208 [ath9k] [ 61.057274] [dfff3f90]
[c0043298] tasklet_action+0xcc/0xf8 [ 61.062777] [dfff3fb0] [c0043d48]
__do_softirq+0xdc/0x18c [ 61.068194] [dfff3ff0] [c0010fb4]
call_do_softirq+0x14/0x24 [ 61.073784] [d8613e60] [c0004fec]
do_softirq+0x8c/0x98 [ 61.078939] [d8613e80] [c0043bd0]
local_bh_enable+0x9c/0xa0 [ 61.084536] [d8613e90] [c036d910]
unix_create1+0x184/0x1ac [ 61.090039] [d8613eb0] [c036d9a0]
unix_create+0x68/0xbc [ 61.095286] [d8613ec0] [c02c6c34]
__sock_create+0x114/0x248 [ 61.100877] [d8613ef0] [c02c7008]
sys_socket+0x54/0x84 [ 61.106031] [d8613f10] [c02c70e8]
sys_socketcall+0xb0/0x258 [ 61.111622] [d8613f40] [c0011970]
ret_from_syscall+0x0/0x3c [ 61.117338] --- E
Re: [ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ
Hi ath9k team:
Another interest question is since the ath9k interrupt was disabled, how can we
get a new IRQ to interrupt the tasklet?
So I investigated and found that the cause of the issue "irq 16: nobody cared"
in my box is the ath9k's irq handler return
too many IRQ_NONE since I read the ISR register always return 0 as below.
/*
* Figure out the reason(s) for the interrupt. Note
* that the hal returns a pseudo-ISR that may include
* bits we haven't explicitly enabled so we mask the
* value to insure we only process bits we requested.
*/
ath9k_hw_getisr(ah, &status); /* NB: clears ISR too */
status &= ah->imask;/* discard unasked-for bits */
/*
* If there are no status bits set, then this interrupt was not
* for me (should have been caught above).
*/
if (!status)
return IRQ_NONE;
if I go to reset chip instead of return IRQ_NONE in this position, the things
become a little healthier than before,
I will never see the message "irq 16: nobody cared".
I check each IRQ using "if(AR_SREV_9300(ah))" and they are all passed, that is,
no other hardware share the irq with ath9k.
I need to know why we read the ISR register and get value 0, and return
IRQ_NONE, the chip I used is AR9300.
Can we using this change below in the ath_isr() function:
if (!status)
goto reset_chip;
Thanks,
- Felix
-
From: Felix Liao
Sent: Friday, November 09, 2012 9:33 AM
To: 'ath9k-devel@lists.ath9k.org'
Subject: ath9k_tasklet() can be interrupted by a hardware IRQ
Hi all,
I met a kernel call trace below using the ath9k driver, we can see that the
ath9k_tasklet() was interrupted by a hardware IRQ,
and at this time the ath9k IRQ was disabled, so the kernel will complain that
there is none irq handler for this interrupt.
[ 60.977474] irq 16: nobody cared (try booting with the "irqpoll" option)
[ 60.984194] Call Trace:
[ 60.986660] [dfff1f50] [c000843c] show_stack+0x70/0x1c8 (unreliable)
[ 60.993041] [dfff1f90] [c00777a0] __report_bad_irq+0x44/0xe8
[ 60.998718] [dfff1fb0] [c0077a44] note_interrupt+0x200/0x260
[ 61.004396] [dfff1fe0] [c0078704] handle_fasteoi_irq+0xc4/0x10c
[ 61.010340] [dfff1ff0] [c0010fdc] call_handle_irq+0x18/0x28
[ 61.015929] [dfff3e50] [c00051c8] do_IRQ+0xcc/0x1b4
[ 61.020825] [dfff3e80] [c0011fc4] ret_from_except+0x0/0x18
[ 61.026349] --- Exception: 501 at ioread32+0x8/0x14
[ 61.026355] LR = ath_descdma_setup+0x294/0x664 [ath9k]
[ 61.036733] [dfff3f40] [c04f5bdc] softirq_to_name+0x0/0x28 (unreliable)
[ 61.043390] [dfff3f50] [e5ad66fc] ath9k_hw_enable_interrupts+0x160/0x1b0
[ath9k_hw]
[ 61.051074] [dfff3f70] [e5b41368] ath9k_tasklet+0xc0/0x208 [ath9k]
[ 61.057274] [dfff3f90] [c0043298] tasklet_action+0xcc/0xf8
[ 61.062777] [dfff3fb0] [c0043d48] __do_softirq+0xdc/0x18c
[ 61.068194] [dfff3ff0] [c0010fb4] call_do_softirq+0x14/0x24
[ 61.073784] [d8613e60] [c0004fec] do_softirq+0x8c/0x98
[ 61.078939] [d8613e80] [c0043bd0] local_bh_enable+0x9c/0xa0
[ 61.084536] [d8613e90] [c036d910] unix_create1+0x184/0x1ac
[ 61.090039] [d8613eb0] [c036d9a0] unix_create+0x68/0xbc
[ 61.095286] [d8613ec0] [c02c6c34] __sock_create+0x114/0x248
[ 61.100877] [d8613ef0] [c02c7008] sys_socket+0x54/0x84
[ 61.106031] [d8613f10] [c02c70e8] sys_socketcall+0xb0/0x258
[ 61.111622] [d8613f40] [c0011970] ret_from_syscall+0x0/0x3c
[ 61.117338] --- Exception: c01 at 0xeff41fc
[ 61.117343] LR = 0xeff4350
[ 61.124578] handlers:
[ 61.126851] [] (ath_isr+0x0/0x21c [ath9k])
[ 61.131840] Disabling IRQ #16
[ 61.143234] ath: phy0: Failed to stop TX DMA, queues=0x001!
I made a patch below for this issue and use it to reduce the probability of
this issue, you can see that,
I can't disable the IRQ from start to end of this function, I need to restore
the IRQ flags before we call ath_rx_tasklet and ath_tx_tasklet,
since these functions will disable and enable the local softirq using
spin_lock_bh and spin_unlock_bh, since with this gap of time,
the tasklet still can be interrupted by the hardware IRQ.
diff -pNaur compat-wireless-3.6.6-1-orig/drivers/net/wireless/ath/ath9k/main.c
compat-wireless-3.6.6-1-fixed/drivers/net/wireless/ath/ath9k/main.c
--- compat-wireless-3.6.6-1-orig/drivers/net/wireless/ath/ath9k/main.c
2012-11-08 00:17:08.0 +0800
+++
compat-wireless-3.6.6-1-fixed/drivers/net/wireless/ath/ath9k/main.c
2012-11-09 07:27:28.459837051 +0800
@@ -368,6 +368,7 @@ void ath9k_tasklet(unsigned long data)
u32 status = sc->intrstatus;
u32 rxmask;
+ local_irq_save(flags);
ath9k_ps_wakeup(sc);
spin_lock(&sc->sc_pcu_lock);
@@ -383,7 +384,7 @@ void ath9k_tasklet(unsigned long data)
goto out;
}
[ath9k-devel] we need use CONFIG_CPU_FREQ for cpufreq_quick_get_max to make the compiler happy
Hi all, SFAIK, there is nobody call this function, but I don't enable CONFIG_CPU_FREQ in my kernel config file, so we need to add this #ifdef to make the compiler happy. diff -pNur compat-wireless-3.6.6-1-orig/compat/compat-3.1.c compat-wireless-3.6.6-1-new/compat/compat-3.1.c --- compat-wireless-3.6.6-1-orig/compat/compat-3.1.c2012-11-08 00:17:09.0 +0800 +++ compat-wireless-3.6.6-1-new/compat/compat-3.1.c 2012-11-09 08:36:35.450566578 +0800 @@ -11,6 +11,7 @@ #include #include +#ifdef CONFIG_CPU_FREQ /* This backports: * commit 3d73710880afa3d61cf57b5d4eb192e812eb7e4f * Author: Jesse Barnes @@ -33,6 +34,7 @@ unsigned int compat_cpufreq_quick_get_ma } EXPORT_SYMBOL(compat_cpufreq_quick_get_max); +#endif static DEFINE_SPINLOCK(compat_simple_ida_lock); diff -pNur compat-wireless-3.6.6-1-orig/include/linux/compat-3.1.h compat-wireless-3.6.6-1-new/include/linux/compat-3.1.h --- compat-wireless-3.6.6-1-orig/include/linux/compat-3.1.h 2012-10-24 21:22:50.0 +0800 +++ compat-wireless-3.6.6-1-new/include/linux/compat-3.1.h 2012-11-09 08:24:00.352596503 +0800 @@ -111,10 +111,12 @@ int ida_simple_get(struct ida *ida, unsi void ida_simple_remove(struct ida *ida, unsigned int id); +#ifdef CONFIG_CPU_FREQ /* mask cpufreq_quick_get_max as RHEL6 backports this */ #define cpufreq_quick_get_max(a) compat_cpufreq_quick_get_max(a) unsigned int cpufreq_quick_get_max(unsigned int cpu); +#endif #endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(3,1,0)) */ #endif /* LINUX_3_1_COMPAT_H */ Thanks, - Felix add_CONFIG_CPU_FREQ.patch Description: add_CONFIG_CPU_FREQ.patch ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k_tasklet() can be interrupted by a hardware IRQ
Hi all,
I met a kernel call trace below using the ath9k driver, we can see that the
ath9k_tasklet() was interrupted by a hardware IRQ, and at this time the ath9k
IRQ was disabled, so the kernel will complain that there is none irq handler
for this interrupt.
[ 60.977474] irq 16: nobody cared (try booting with the "irqpoll" option)
[ 60.984194] Call Trace:
[ 60.986660] [dfff1f50] [c000843c] show_stack+0x70/0x1c8 (unreliable)
[ 60.993041] [dfff1f90] [c00777a0] __report_bad_irq+0x44/0xe8
[ 60.998718] [dfff1fb0] [c0077a44] note_interrupt+0x200/0x260
[ 61.004396] [dfff1fe0] [c0078704] handle_fasteoi_irq+0xc4/0x10c
[ 61.010340] [dfff1ff0] [c0010fdc] call_handle_irq+0x18/0x28
[ 61.015929] [dfff3e50] [c00051c8] do_IRQ+0xcc/0x1b4
[ 61.020825] [dfff3e80] [c0011fc4] ret_from_except+0x0/0x18
[ 61.026349] --- Exception: 501 at ioread32+0x8/0x14
[ 61.026355] LR = ath_descdma_setup+0x294/0x664 [ath9k]
[ 61.036733] [dfff3f40] [c04f5bdc] softirq_to_name+0x0/0x28 (unreliable)
[ 61.043390] [dfff3f50] [e5ad66fc] ath9k_hw_enable_interrupts+0x160/0x1b0
[ath9k_hw]
[ 61.051074] [dfff3f70] [e5b41368] ath9k_tasklet+0xc0/0x208 [ath9k]
[ 61.057274] [dfff3f90] [c0043298] tasklet_action+0xcc/0xf8
[ 61.062777] [dfff3fb0] [c0043d48] __do_softirq+0xdc/0x18c
[ 61.068194] [dfff3ff0] [c0010fb4] call_do_softirq+0x14/0x24
[ 61.073784] [d8613e60] [c0004fec] do_softirq+0x8c/0x98
[ 61.078939] [d8613e80] [c0043bd0] local_bh_enable+0x9c/0xa0
[ 61.084536] [d8613e90] [c036d910] unix_create1+0x184/0x1ac
[ 61.090039] [d8613eb0] [c036d9a0] unix_create+0x68/0xbc
[ 61.095286] [d8613ec0] [c02c6c34] __sock_create+0x114/0x248
[ 61.100877] [d8613ef0] [c02c7008] sys_socket+0x54/0x84
[ 61.106031] [d8613f10] [c02c70e8] sys_socketcall+0xb0/0x258
[ 61.111622] [d8613f40] [c0011970] ret_from_syscall+0x0/0x3c
[ 61.117338] --- Exception: c01 at 0xeff41fc
[ 61.117343] LR = 0xeff4350
[ 61.124578] handlers:
[ 61.126851] [] (ath_isr+0x0/0x21c [ath9k])
[ 61.131840] Disabling IRQ #16
[ 61.143234] ath: phy0: Failed to stop TX DMA, queues=0x001!
I made a patch below for this issue and use it to reduce the probability of
this issue, you can see that, I can't disable the IRQ from start to end of this
function, I need to restore the IRQ flags before we call ath_rx_tasklet and
ath_tx_tasklet, since these functions will disable and enable the local softirq
using spin_lock_bh and spin_unlock_bh, since with this gap of time, the
tasklet still can be interrupted by the hardware IRQ.
diff -pNaur compat-wireless-3.6.6-1-orig/drivers/net/wireless/ath/ath9k/main.c
compat-wireless-3.6.6-1-fixed/drivers/net/wireless/ath/ath9k/main.c
--- compat-wireless-3.6.6-1-orig/drivers/net/wireless/ath/ath9k/main.c
2012-11-08 00:17:08.0 +0800
+++ compat-wireless-3.6.6-1-fixed/drivers/net/wireless/ath/ath9k/main.c
2012-11-09 07:27:28.459837051 +0800
@@ -368,6 +368,7 @@ void ath9k_tasklet(unsigned long data)
u32 status = sc->intrstatus;
u32 rxmask;
+ local_irq_save(flags);
ath9k_ps_wakeup(sc);
spin_lock(&sc->sc_pcu_lock);
@@ -383,7 +384,7 @@ void ath9k_tasklet(unsigned long data)
goto out;
}
- spin_lock_irqsave(&sc->sc_pm_lock, flags);
+ spin_lock(&sc->sc_pm_lock);
if ((status & ATH9K_INT_TSFOOR) && sc->ps_enabled) {
/*
* TSF sync does not look correct; remain awake to
sync with
@@ -392,7 +393,7 @@ void ath9k_tasklet(unsigned long data)
ath_dbg(common, PS, "TSFOOR - Sync with next
Beacon\n");
sc->ps_flags |= PS_WAIT_FOR_BEACON |
PS_BEACON_SYNC;
}
- spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
+ spin_unlock(&sc->sc_pm_lock);
if (ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
rxmask = (ATH9K_INT_RXHP | ATH9K_INT_RXLP |
ATH9K_INT_RXEOL |
@@ -400,6 +401,7 @@ void ath9k_tasklet(unsigned long data)
else
rxmask = (ATH9K_INT_RX | ATH9K_INT_RXEOL |
ATH9K_INT_RXORN);
+ local_irq_restore(flags);
if (status & rxmask) {
/* Check for high priority Rx first */
if ((ah->caps.hw_caps & ATH9K_HW_CAP_EDMA) &&
@@ -416,6 +418,7 @@ void ath9k_tasklet(unsigned long data)
ath_tx_tasklet(sc);
}
+ local_irq_save(flags);
ath9k_btcoex_handle_interrupt(sc, status);
out:
@@ -424,6 +427,7 @@ out:
spin_unlock(&sc->sc_pcu_lock);
ath9k_ps_restore(sc);
+ local_irq_restore(flags);
}
irqreturn_t ath_isr(int irq, void *dev)
but what I need to say is we should disable the IRQ entire of this function, so
we need to use the spin_lock/spin_unl
