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
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 IS
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 *
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
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 i
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.
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 2012-11-20 11:05 AM, Felix Liao wrote:
> 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,
>
On 2012-11-20 11:05 AM, Felix Liao wrote:
>> 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 IR
