Issues with FW with Intel 720 wifi card
Hi, Im using linux 4.6 kernel, I get following error when I do interface up. Here is the boot log. [4.407681] iwlwifi :01:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm [4.407742] iwlwifi :01:00.0: Detected Intel(R) Wireless N 7260, REV=0x144 [4.407831] iwlwifi :01:00.0: L1 Disabled - LTR Disabled [4.408116] iwlwifi :01:00.0: L1 Disabled - LTR Disabled When I do interface up I get following : [9.41] iwlwifi :01:00.0: Failed to load firmware chunk! [9.425947] iwlwifi :01:00.0: Could not load the [0] uCode section [9.432472] iwlwifi :01:00.0: Failed to start INIT ucode: -110 [9.438899] iwlwifi :01:00.0: Failed to run INIT ucode: -110 [9.444858] iwlwifi :01:00.0: L1 Disabled - LTR Disabled I downloaded firmware from here https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi Is there anything im missing ? Regards, Bharat
RE: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
> Subject: Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware > interrupts > after enabling local irq flags > > On 01/20/2017 08:14 AM, Bharat Kumar Gogada wrote: > > > On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote: > >>> -Realtek 8192CE chipset maintains local irq flags after > >>> enabling/disabling hardware interrupts. > >>> -Hardware interrupts are enabled before enabling the local irq > >>> flags(these flags are being checked in interrupt handler), leading > >>> to race condition on some RP, where the irq line between bridge and > >>> GIC goes high at ASSERT_INTx and goes low only at DEASSERT_INTx. In > >>> this kind of RP by the time ASSERT_INTx is seen irq_enable flag is > >>> still set to false, resulting in continuous interrupts seen by CPU > >>> as DEASSERT_INTx cannot be sent since flag is still false and making > >>> CPU stall. > >>> -Changing the sequence of setting these irq flags. > >>> > >>> Signed-off-by: Bharat Kumar Gogada <bhara...@xilinx.com> > >>> --- > >> > >> This patch should be enhanced with the smb_xx() calls as suggested by by > Lino. > >> > >> The subject should be changed. I would suggest something like "rtlwifi: > >> rtl8192ce: Prevent race condition when enabling interrupts", as it > >> explains the condition you are preventing. > >> > >> The other PCI drivers also have the same problem. Do you want to > >> prepare the patches, or should I do it? > >> > > Thanks Larry. Please send out the patches adding the above enhancements > suggested by Lino. > > I have prepared a patch fixing all the drivers. By the way, what CPU hardware > showed this problem? > Thanks Larry, it was showed in ZynqUltrascalePlus Root Port hardware.
RE: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
> On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote: > > -Realtek 8192CE chipset maintains local irq flags after enabling/disabling > > hardware interrupts. > > -Hardware interrupts are enabled before enabling the local irq > > flags(these flags are being checked in interrupt handler), > > leading to race condition on some RP, where the irq line between > > bridge and GIC goes high at ASSERT_INTx and goes low only > > at DEASSERT_INTx. In this kind of RP by the time ASSERT_INTx is seen > > irq_enable flag is still set to false, resulting in continuous > > interrupts seen by CPU as DEASSERT_INTx cannot be sent since > > flag is still false and making CPU stall. > > -Changing the sequence of setting these irq flags. > > > > Signed-off-by: Bharat Kumar Gogada <bhara...@xilinx.com> > > --- > > This patch should be enhanced with the smb_xx() calls as suggested by by Lino. > > The subject should be changed. I would suggest something like "rtlwifi: > rtl8192ce: Prevent race condition when enabling interrupts", as it explains > the > condition you are preventing. > > The other PCI drivers also have the same problem. Do you want to prepare the > patches, or should I do it? > Thanks Larry. Please send out the patches adding the above enhancements suggested by Lino. Bharat
[PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
-Realtek 8192CE chipset maintains local irq flags after enabling/disabling hardware interrupts. -Hardware interrupts are enabled before enabling the local irq flags(these flags are being checked in interrupt handler), leading to race condition on some RP, where the irq line between bridge and GIC goes high at ASSERT_INTx and goes low only at DEASSERT_INTx. In this kind of RP by the time ASSERT_INTx is seen irq_enable flag is still set to false, resulting in continuous interrupts seen by CPU as DEASSERT_INTx cannot be sent since flag is still false and making CPU stall. -Changing the sequence of setting these irq flags. Signed-off-by: Bharat Kumar Gogada <bhara...@xilinx.com> --- drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c index a47be73..143766c4 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c @@ -1306,9 +1306,9 @@ void rtl92ce_enable_interrupt(struct ieee80211_hw *hw) struct rtl_priv *rtlpriv = rtl_priv(hw); struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw)); + rtlpci->irq_enabled = true; rtl_write_dword(rtlpriv, REG_HIMR, rtlpci->irq_mask[0] & 0x); rtl_write_dword(rtlpriv, REG_HIMRE, rtlpci->irq_mask[1] & 0x); - rtlpci->irq_enabled = true; } void rtl92ce_disable_interrupt(struct ieee80211_hw *hw) @@ -1316,9 +1316,9 @@ void rtl92ce_disable_interrupt(struct ieee80211_hw *hw) struct rtl_priv *rtlpriv = rtl_priv(hw); struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw)); + rtlpci->irq_enabled = false; rtl_write_dword(rtlpriv, REG_HIMR, IMR8190_DISABLED); rtl_write_dword(rtlpriv, REG_HIMRE, IMR8190_DISABLED); - rtlpci->irq_enabled = false; } static void _rtl92ce_poweroff_adapter(struct ieee80211_hw *hw) -- 2.1.1
RE: ATH9 driver issues on ARM64
Hi All,
After further debugging we know the place it hangs.
In function:
static int ath_reset_internal (struct ath_softc *sc, struct ath9k_channel
*hchan)
{
disable_irq(sc->irq);
tasklet_disable(>intr_tq);
tasklet_disable(>bcon_tasklet);
spin_lock_bh(>sc_pcu_lock);
if (!ath_complete_reset(sc, true)) -> This function enables
hardware interrupts
r = -EIO;
out:
enable_irq(sc->irq);-> Here IRQ line state is
changed to enable state
spin_unlock_bh(>sc_pcu_lock);
tasklet_enable(>bcon_tasklet);
tasklet_enable(>intr_tq);
}
static bool ath_complete_reset(struct ath_softc *sc, bool start)
{
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
unsigned long flags;
ath9k_calculate_summary_state(sc, sc->cur_chan);
ath_startrecv(sc);
sc->gtt_cnt = 0;
ath9k_hw_set_interrupts(ah);-> Here hardware interrupts are
being enabled
ath9k_hw_enable_interrupts(ah); -> We see hang after this line
ieee80211_wake_queues(sc->hw);
ath9k_p2p_ps_timer(sc);
return true;
}
Before changing IRQ line to to enabled state, hardware interrupts are being
enabled.
Wont this cause a race condition where within this period of hardware raises an
interrupt, but IRQ line state is disabled state, this will
reach the following condition making EP handler not being invoked.
void handle_simple_irq(struct irq_desc *desc)
{
raw_spin_lock(>lock);
...
if (unlikely(!desc->action || irqd_irq_disabled(>irq_data))) {
// This condition is reaching and becoming true.
desc->istate |= IRQS_PENDING;
goto out_unlock;
}
kstat_incr_irqs_this_cpu(desc);
handle_irq_event(desc);
out_unlock:
raw_spin_unlock(>lock);
}
We see hang at that statement, without reaching back enable_irq, looks like by
this time CPU is in stall.
Can any tell why hardware interrupts are being enabled before kernel changing
IRQ line state?
Regards,
Bharat
>
> > On Sat, Dec 10, 2016 at 02:40:48PM +, Bharat Kumar Gogada wrote:
> > > Hi,
> > >
> > > After taking some more lecroy traces, we see that after 2nd ASSERT
> > > from EP
> > on ARM64 we see continuous data movement of 32 dwords or 12 dwords and
> > never sign of DEASSERT.
> > > Comparatively on working traces (x86) after 2nd assert there are
> > > only BAR
> > register reads and writes and then DEASSERT, for almost most of the
> > interrupts and we haven't seen 12 or 32 dwords data movement on this trace.
> > >
> > > I did not work on EP wifi/network drivers, any help why EP needs
> > > those many
> > number of data at scan time ?
> >
> > The device doesn't know whether it's in an x86 or an arm64 system. If
> > it works differently, it must be because the PCI core or the driver is
> > programming the device differently.
> >
> > You should be able to match up Memory transactions from the host in
> > the trace with things the driver does. For example, if you see an
> > Assert_INTx message from the device, you should eventually see a
> > Memory Read from the host to get the ISR, i.e., some read done in the bowels
> of ath9k_hw_getisr().
> >
> > I don't know how the ath9k device works, but there must be some Memory
> > Read or Write done by the driver that tells the device "we've handled this
> interrupt".
> > The device should then send a Deassert_INTx; of course, if the device
> > still requires service, e.g., because it has received more packets, it
> > might leave the INTx asserted.
> >
> > I doubt you'd see exactly the same traces on x86 and arm64 because
> > they aren't seeing the same network packets and the driver is executing at
> different rates.
> > But you should at least be able to identify interrupt assertion and
> > the actions of the driver's interrupt service routine.
>
>
> Thanks Bjorn.
>
> As you mentioned we did try to debug in that path. After we start scan after
> 2nd
> ASSERT we see lots of 32 and 12 dword data, and in function void
> ath9k_hw_enable_interrupts(struct ath_hw *ah) {
> ...
> ..
> REG_WRITE(ah, AR_IER, AR_IER_ENABLE);
> // EP driver hangs at this
> position after 2nd ASSERT
> // The following writes are not
> happening
> if (!AR_SREV_9100(ah)) {
> REG_WRITE(ah
RE: ATH9 driver issues on ARM64
> On Sat, Dec 10, 2016 at 02:40:48PM +0000, Bharat Kumar Gogada wrote:
> > Hi,
> >
> > After taking some more lecroy traces, we see that after 2nd ASSERT from EP
> on ARM64 we see continuous data movement of 32 dwords or 12 dwords and
> never sign of DEASSERT.
> > Comparatively on working traces (x86) after 2nd assert there are only BAR
> register reads and writes and then DEASSERT, for almost most of the interrupts
> and we haven't seen 12 or 32 dwords data movement on this trace.
> >
> > I did not work on EP wifi/network drivers, any help why EP needs those many
> number of data at scan time ?
>
> The device doesn't know whether it's in an x86 or an arm64 system. If it
> works
> differently, it must be because the PCI core or the driver is programming the
> device differently.
>
> You should be able to match up Memory transactions from the host in the trace
> with things the driver does. For example, if you see an Assert_INTx message
> from the device, you should eventually see a Memory Read from the host to get
> the ISR, i.e., some read done in the bowels of ath9k_hw_getisr().
>
> I don't know how the ath9k device works, but there must be some Memory Read
> or Write done by the driver that tells the device "we've handled this
> interrupt".
> The device should then send a Deassert_INTx; of course, if the device still
> requires service, e.g., because it has received more packets, it might leave
> the
> INTx asserted.
>
> I doubt you'd see exactly the same traces on x86 and arm64 because they aren't
> seeing the same network packets and the driver is executing at different
> rates.
> But you should at least be able to identify interrupt assertion and the
> actions of
> the driver's interrupt service routine.
Thanks Bjorn.
As you mentioned we did try to debug in that path. After we start scan after
2nd ASSERT we see lots of 32 and 12 dword
data, and in function
void ath9k_hw_enable_interrupts(struct ath_hw *ah)
{
...
..
REG_WRITE(ah, AR_IER, AR_IER_ENABLE);
// EP driver hangs at this
position after 2nd ASSERT
// The following writes are not
happening
if (!AR_SREV_9100(ah)) {
REG_WRITE(ah, AR_INTR_ASYNC_ENABLE, async_mask);
REG_WRITE(ah, AR_INTR_ASYNC_MASK, async_mask);
REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
REG_WRITE(ah, AR_INTR_SYNC_MASK, sync_default);
}
ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER));
}
The above funtion is invoked from tasklet.
I tried several boots every it stops here. The condition (!AR_SREV_9100(ah)) is
true as per before 1st ASSERT handling.
Regards,
Bharat
>
> > > Hello there,
> > >
> > > as this is a thread about ath9k and ARM64, i'm not sure if i should
> > > answer here or not, but i have similar "stalls" with ath9k on x86_64
> > > (starting with 4.9rc), stack trace is posted down below where the original
> ARM64 stall traces are.
> > >
> > > Greetings,
> > >
> > > Tobias
> > >
> > >
> > > On 08.12.2016 18:36, Kalle Valo wrote:
> > > > Bharat Kumar Gogada <bharat.kumar.gog...@xilinx.com> writes:
> > > >
> > > >> > [+cc Kalle, ath9k list]
> > > > Thanks, but please also CC linux-wireless. Full thread below for
> > > > the folks there.
> > > >
> > > >>> On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada
> wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> Did anyone test Atheros ATH9
> > > >>>> driver(drivers/net/wireless/ath/ath9k/)
> > > >>>> on ARM64. The end point is TP link wifi card with which
> > > >>>> supports only legacy interrupts.
> > > >>> If it works on other arches and the arm64 PCI enumeration works,
> > > >>> my first guess would be an INTx issue, e.g., maybe the driver is
> > > >>> waiting for an interrupt that never arrives.
> > > >> We are not sure for now.
> > > >>>> We are trying to test it on ARM64 with
> > > >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> > > >>>>
> > > >>>> EP is getting enumerated and able to link up.
> > > >>>>
> > > >>>> But when we start scan system gets hanged.
> > > >>> When yo
RE: ATH9 driver issues on ARM64
Hi, After taking some more lecroy traces, we see that after 2nd ASSERT from EP on ARM64 we see continuous data movement of 32 dwords or 12 dwords and never sign of DEASSERT. Comparatively on working traces (x86) after 2nd assert there are only BAR register reads and writes and then DEASSERT, for almost most of the interrupts and we haven't seen 12 or 32 dwords data movement on this trace. I did not work on EP wifi/network drivers, any help why EP needs those many number of data at scan time ? Regards, Bharat > Hello there, > > as this is a thread about ath9k and ARM64, i'm not sure if i should answer > here > or not, but i have similar "stalls" with ath9k on x86_64 (starting with > 4.9rc), stack > trace is posted down below where the original ARM64 stall traces are. > > Greetings, > > Tobias > > > On 08.12.2016 18:36, Kalle Valo wrote: > > Bharat Kumar Gogada <bharat.kumar.gog...@xilinx.com> writes: > > > >> > [+cc Kalle, ath9k list] > > Thanks, but please also CC linux-wireless. Full thread below for the > > folks there. > > > >>> On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada wrote: > >>>> Hi, > >>>> > >>>> Did anyone test Atheros ATH9 > >>>> driver(drivers/net/wireless/ath/ath9k/) > >>>> on ARM64. The end point is TP link wifi card with which supports > >>>> only legacy interrupts. > >>> If it works on other arches and the arm64 PCI enumeration works, my > >>> first guess would be an INTx issue, e.g., maybe the driver is > >>> waiting for an interrupt that never arrives. > >> We are not sure for now. > >>>> We are trying to test it on ARM64 with > >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port. > >>>> > >>>> EP is getting enumerated and able to link up. > >>>> > >>>> But when we start scan system gets hanged. > >>> When you say the system hangs when you start a scan, I assume you > >>> mean a wifi scan, not the PCI enumeration. A problem with a wifi > >>> scan might cause a *process* to hang, but it shouldn't hang the > >>> entire system. > >>> > >> Yes wifi scan. > >>>> When we took trace we see that after we start scan assert message > >>>> is sent but there is no de assert from end point. > >>> Are you talking about a trace from a PCIe analyzer? Do you see an > >>> Assert_INTx PCIe message on the link? > >>> > >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening > when we do interface link up. > >> When we have less debug prints in Atheros driver, and do wifi scan we > >> see Assert_INTx but never Deassert_INTx, > >>>> What might cause end point not sending de assert ? > >>> If the endpoint doesn't send a Deassert_INTx message, I expect that > >>> would mean the driver didn't service the interrupt and remove the > >>> condition that caused the device to assert the interrupt in the > >>> first place. > >>> > >>> If the driver didn't receive the interrupt, it couldn't service it, > >>> of course. You could add a printk in the ath9k interrupt service > >>> routine to see if you ever get there. > >>> > >> The interrupt behavior is changing w.r.t amount of debug prints we > >> add. (I kept many prints to aid debug) root@Xilinx-ZCU102-2016_3:~# iw dev > wlan0 scan > >> [ 83.064675] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.069486] ath9k: ath9k_ioread32 ff800a400024 > >> [ 83.074257] ath9k_hw_kill_interrupts 793 > >> [ 83.078260] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.083107] ath9k: ath9k_ioread32 ff800a400024 > >> [ 83.087882] ath9k_hw_kill_interrupts 793 > >> [ 83.095450] ath9k_hw_enable_interrupts 821 > >> [ 83.099557] ath9k_hw_enable_interrupts 825 > >> [ 83.103721] ath9k_hw_enable_interrupts 832 > >> [ 83.107887] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.112748] AR_SREV_9100 0 > >> [ 83.115438] ath9k_hw_enable_interrupts 848 > >> [ 83.119607] ath9k: ath9k_ioread32 ff800a400024 > >> [ 83.124389] ath9k_hw_intrpend762 > >> [ 83.127761] (AR_SREV_9340(ah) val 0 > >> [ 83.131234] ath9k_hw_intrpend767 > >> [ 83.134628] ath_isr 603 > >> [ 83.137134] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.141995] ath9k: ath9k_ioread32 ff80
RE: ATH9 driver issues on ARM64
Correcting Manohar Mail ID. > Hello there, > > as this is a thread about ath9k and ARM64, i'm not sure if i should > answer here or not, but i have similar "stalls" with ath9k on x86_64 > (starting with 4.9rc), stack trace is posted down below where the > original ARM64 stall traces are. > > Greetings, > > Tobias > > > On 08.12.2016 18:36, Kalle Valo wrote: > > Bharat Kumar Gogada <bharat.kumar.gog...@xilinx.com> writes: > > > >> > [+cc Kalle, ath9k list] > > Thanks, but please also CC linux-wireless. Full thread below for the > > folks there. > > > >>> On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada wrote: > >>>> Hi, > >>>> > >>>> Did anyone test Atheros ATH9 driver(drivers/net/wireless/ath/ath9k/) > >>>> on ARM64. The end point is TP link wifi card with which supports > >>>> only legacy interrupts. > >>> If it works on other arches and the arm64 PCI enumeration works, my > >>> first guess would be an INTx issue, e.g., maybe the driver is waiting > >>> for an interrupt that never arrives. > >> We are not sure for now. > >>>> We are trying to test it on ARM64 with > >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port. > >>>> > >>>> EP is getting enumerated and able to link up. > >>>> > >>>> But when we start scan system gets hanged. > >>> When you say the system hangs when you start a scan, I assume you mean > >>> a wifi scan, not the PCI enumeration. A problem with a wifi scan > >>> might cause a *process* to hang, but it shouldn't hang the entire > >>> system. > >>> > >> Yes wifi scan. > >>>> When we took trace we see that after we start scan assert message is > >>>> sent but there is no de assert from end point. > >>> Are you talking about a trace from a PCIe analyzer? Do you see an > >>> Assert_INTx PCIe message on the link? > >>> > >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening > when we do interface link up. > >> When we have less debug prints in Atheros driver, and do wifi scan we see > Assert_INTx but never Deassert_INTx, > >>>> What might cause end point not sending de assert ? > >>> If the endpoint doesn't send a Deassert_INTx message, I expect that > >>> would mean the driver didn't service the interrupt and remove the > >>> condition that caused the device to assert the interrupt in the first > >>> place. > >>> > >>> If the driver didn't receive the interrupt, it couldn't service it, of > >>> course. You could add a printk in the ath9k interrupt service > >>> routine to see if you ever get there. > >>> > >> The interrupt behavior is changing w.r.t amount of debug prints we add. (I > kept many prints to aid debug) > >> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan > >> [ 83.064675] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.069486] ath9k: ath9k_ioread32 ff800a400024 > >> [ 83.074257] ath9k_hw_kill_interrupts 793 > >> [ 83.078260] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.083107] ath9k: ath9k_ioread32 ff800a400024 > >> [ 83.087882] ath9k_hw_kill_interrupts 793 > >> [ 83.095450] ath9k_hw_enable_interrupts 821 > >> [ 83.099557] ath9k_hw_enable_interrupts 825 > >> [ 83.103721] ath9k_hw_enable_interrupts 832 > >> [ 83.107887] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.112748] AR_SREV_9100 0 > >> [ 83.115438] ath9k_hw_enable_interrupts 848 > >> [ 83.119607] ath9k: ath9k_ioread32 ff800a400024 > >> [ 83.124389] ath9k_hw_intrpend762 > >> [ 83.127761] (AR_SREV_9340(ah) val 0 > >> [ 83.131234] ath9k_hw_intrpend767 > >> [ 83.134628] ath_isr 603 > >> [ 83.137134] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.141995] ath9k: ath9k_ioread32 ff800a400024 > >> [ 83.146771] ath9k_hw_kill_interrupts 793 > >> [ 83.150864] ath9k_hw_enable_interrupts 821 > >> [ 83.154971] ath9k_hw_enable_interrupts 825 > >> [ 83.159135] ath9k_hw_enable_interrupts 832 > >> [ 83.163300] ath9k: ath9k_iowrite32 ff800a400024 > >> [ 83.168161] AR_SREV_9100 0 > >> [ 83.170852] ath9k_hw_enable_interrupts 848 > >> [ 83.170855] ath9k_hw_intrpend762 > >> [ 83.178398]
RE: ATH9 driver issues on ARM64
Sorry, Forgot to add kernel version, we are using 4.6 kernel. > Hi, > Can any one tell, when exactly the chip sends ASSERT & DEASSERT in driver. > It might help us to debug issue further. > > Thanks & Regards, > Bharat > > > > > [+cc Kalle, ath9k list] > > > > Thanks, but please also CC linux-wireless. Full thread below for the folks > > there. > > > > >> On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada wrote: > > >> > Hi, > > >> > > > >> > Did anyone test Atheros ATH9 > > >> > driver(drivers/net/wireless/ath/ath9k/) > > >> > on ARM64. The end point is TP link wifi card with which supports > > >> > only legacy interrupts. > > >> > > >> If it works on other arches and the arm64 PCI enumeration works, my > > >> first guess would be an INTx issue, e.g., maybe the driver is > > >> waiting for an interrupt that never arrives. > > > We are not sure for now. > > >> > > >> > We are trying to test it on ARM64 with > > >> > (drivers/pci/host/pcie-xilinx-nwl.c) as root port. > > >> > > > >> > EP is getting enumerated and able to link up. > > >> > > > >> > But when we start scan system gets hanged. > > >> > > >> When you say the system hangs when you start a scan, I assume you > > >> mean a wifi scan, not the PCI enumeration. A problem with a wifi > > >> scan might cause a *process* to hang, but it shouldn't hang the > > >> entire system. > > >> > > > Yes wifi scan. > > >> > When we took trace we see that after we start scan assert message > > >> > is sent but there is no de assert from end point. > > >> > > >> Are you talking about a trace from a PCIe analyzer? Do you see an > > >> Assert_INTx PCIe message on the link? > > >> > > > Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx > > > happening > > when we do interface link up. > > > When we have less debug prints in Atheros driver, and do wifi scan > > > we see Assert_INTx but never Deassert_INTx, > > >> > What might cause end point not sending de assert ? > > >> > > >> If the endpoint doesn't send a Deassert_INTx message, I expect that > > >> would mean the driver didn't service the interrupt and remove the > > >> condition that caused the device to assert the interrupt in the > > >> first place. > > >> > > >> If the driver didn't receive the interrupt, it couldn't service it, > > >> of course. You could add a printk in the ath9k interrupt service > > >> routine to see if you ever get there. > > >> > > > The interrupt behavior is changing w.r.t amount of debug prints we > > > add. (I kept many prints to aid debug) root@Xilinx-ZCU102-2016_3:~# > > > iw dev > > wlan0 scan > > > [ 83.064675] ath9k: ath9k_iowrite32 ff800a400024 > > > [ 83.069486] ath9k: ath9k_ioread32 ff800a400024 > > > [ 83.074257] ath9k_hw_kill_interrupts793 > > > [ 83.078260] ath9k: ath9k_iowrite32 ff800a400024 > > > [ 83.083107] ath9k: ath9k_ioread32 ff800a400024 > > > [ 83.087882] ath9k_hw_kill_interrupts793 > > > [ 83.095450] ath9k_hw_enable_interrupts 821 > > > [ 83.099557] ath9k_hw_enable_interrupts 825 > > > [ 83.103721] ath9k_hw_enable_interrupts 832 > > > [ 83.107887] ath9k: ath9k_iowrite32 ff800a400024 > > > [ 83.112748] AR_SREV_9100 0 > > > [ 83.115438] ath9k_hw_enable_interrupts 848 > > > [ 83.119607] ath9k: ath9k_ioread32 ff800a400024 > > > [ 83.124389] ath9k_hw_intrpend 762 > > > [ 83.127761] (AR_SREV_9340(ah) val 0 > > > [ 83.131234] ath9k_hw_intrpend 767 > > > [ 83.134628] ath_isr 603 > > > [ 83.137134] ath9k: ath9k_iowrite32 ff800a400024 > > > [ 83.141995] ath9k: ath9k_ioread32 ff800a400024 > > > [ 83.146771] ath9k_hw_kill_interrupts793 > > > [ 83.150864] ath9k_hw_enable_interrupts 821 > > > [ 83.154971] ath9k_hw_enable_interrupts 825 > > > [ 83.159135] ath9k_hw_enable_interrupts 832 > > > [ 83.163300] ath9k: ath9k_iowrite32 ff800a400024 > > > [ 83.168161] AR_SREV_9100 0 > > > [ 83.170852] ath9k_hw_enable_interrupts 848 > > > [ 83.170855] ath9k_hw_intrpend 762 > > > [ 83.178398] (AR_SREV_9340(
RE: ATH9 driver issues on ARM64
Hi, Can any one tell, when exactly the chip sends ASSERT & DEASSERT in driver. It might help us to debug issue further. Thanks & Regards, Bharat > > > [+cc Kalle, ath9k list] > > Thanks, but please also CC linux-wireless. Full thread below for the folks > there. > > >> On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada wrote: > >> > Hi, > >> > > >> > Did anyone test Atheros ATH9 > >> > driver(drivers/net/wireless/ath/ath9k/) > >> > on ARM64. The end point is TP link wifi card with which supports > >> > only legacy interrupts. > >> > >> If it works on other arches and the arm64 PCI enumeration works, my > >> first guess would be an INTx issue, e.g., maybe the driver is waiting > >> for an interrupt that never arrives. > > We are not sure for now. > >> > >> > We are trying to test it on ARM64 with > >> > (drivers/pci/host/pcie-xilinx-nwl.c) as root port. > >> > > >> > EP is getting enumerated and able to link up. > >> > > >> > But when we start scan system gets hanged. > >> > >> When you say the system hangs when you start a scan, I assume you > >> mean a wifi scan, not the PCI enumeration. A problem with a wifi > >> scan might cause a *process* to hang, but it shouldn't hang the > >> entire system. > >> > > Yes wifi scan. > >> > When we took trace we see that after we start scan assert message > >> > is sent but there is no de assert from end point. > >> > >> Are you talking about a trace from a PCIe analyzer? Do you see an > >> Assert_INTx PCIe message on the link? > >> > > Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening > when we do interface link up. > > When we have less debug prints in Atheros driver, and do wifi scan we > > see Assert_INTx but never Deassert_INTx, > >> > What might cause end point not sending de assert ? > >> > >> If the endpoint doesn't send a Deassert_INTx message, I expect that > >> would mean the driver didn't service the interrupt and remove the > >> condition that caused the device to assert the interrupt in the first > >> place. > >> > >> If the driver didn't receive the interrupt, it couldn't service it, > >> of course. You could add a printk in the ath9k interrupt service > >> routine to see if you ever get there. > >> > > The interrupt behavior is changing w.r.t amount of debug prints we > > add. (I kept many prints to aid debug) root@Xilinx-ZCU102-2016_3:~# iw dev > wlan0 scan > > [ 83.064675] ath9k: ath9k_iowrite32 ff800a400024 > > [ 83.069486] ath9k: ath9k_ioread32 ff800a400024 > > [ 83.074257] ath9k_hw_kill_interrupts 793 > > [ 83.078260] ath9k: ath9k_iowrite32 ff800a400024 > > [ 83.083107] ath9k: ath9k_ioread32 ff800a400024 > > [ 83.087882] ath9k_hw_kill_interrupts 793 > > [ 83.095450] ath9k_hw_enable_interrupts821 > > [ 83.099557] ath9k_hw_enable_interrupts825 > > [ 83.103721] ath9k_hw_enable_interrupts832 > > [ 83.107887] ath9k: ath9k_iowrite32 ff800a400024 > > [ 83.112748] AR_SREV_9100 0 > > [ 83.115438] ath9k_hw_enable_interrupts848 > > [ 83.119607] ath9k: ath9k_ioread32 ff800a400024 > > [ 83.124389] ath9k_hw_intrpend 762 > > [ 83.127761] (AR_SREV_9340(ah) val 0 > > [ 83.131234] ath9k_hw_intrpend 767 > > [ 83.134628] ath_isr 603 > > [ 83.137134] ath9k: ath9k_iowrite32 ff800a400024 > > [ 83.141995] ath9k: ath9k_ioread32 ff800a400024 > > [ 83.146771] ath9k_hw_kill_interrupts 793 > > [ 83.150864] ath9k_hw_enable_interrupts821 > > [ 83.154971] ath9k_hw_enable_interrupts825 > > [ 83.159135] ath9k_hw_enable_interrupts832 > > [ 83.163300] ath9k: ath9k_iowrite32 ff800a400024 > > [ 83.168161] AR_SREV_9100 0 > > [ 83.170852] ath9k_hw_enable_interrupts848 > > [ 83.170855] ath9k_hw_intrpend 762 > > [ 83.178398] (AR_SREV_9340(ah) val 0 > > [ 83.181873] ath9k_hw_intrpend 767 > > [ 83.185265] ath_isr 603 > > [ 83.187773] ath9k: ath9k_iowrite32 ff800a400024 > > [ 83.192635] ath9k: ath9k_ioread32 ff800a400024 > > [ 83.197411] ath9k_hw_kill_interrupts 793 > > [ 83.201414] ath9k: ath9k_ioread32 ff800a400024 > > [ 83.206258] ath9k_hw_enable_interrupts821 > > [ 83.210368] ath9k_hw_enable_interrupts825 > > [ 83.214531] ath9k_hw_enable_
