Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1538597

Re: ATH9 driver issues on ARM64

From Bjorn Helgaas <helgaas@kernel.org>
Newsgroups linux.kernel
Subject Re: ATH9 driver issues on ARM64
Date 2016-12-08 16:00 +0100
Message-ID <sM8kW-7mt-23@gated-at.bofh.it> (permalink)
References <sM8kW-7mt-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[+cc Kalle, ath9k list]

On Thu, Dec 08, 2016 at 01:49:42PM +0000, 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 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.

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

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

> We are not seeing any issues on 32-bit ARM platform and X86
> platform. 

Can you collect a dmesg log (or, if the system hang means you can't
collect that, a console log with "ignore_loglevel"), and "lspci -vv"
output as root?  That should have clues about whether the INTx got
routed correctly.  /proc/interrupts should also show whether we're
receiving interrupts from the device.

Bjorn

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Re: ATH9 driver issues on ARM64 Bjorn Helgaas <helgaas@kernel.org> - 2016-12-08 16:00 +0100
  Re: ATH9 driver issues on ARM64 Kalle Valo <kvalo@codeaurora.org> - 2016-12-08 18:40 +0100
    Re: ATH9 driver issues on ARM64 Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> - 2016-12-09 15:30 +0100
  Re: ATH9 driver issues on ARM64 Marc Zyngier <marc.zyngier@arm.com> - 2016-12-08 19:10 +0100
    Re: ATH9 driver issues on ARM64 Marc Zyngier <marc.zyngier@arm.com> - 2016-12-08 20:10 +0100
      Re: ATH9 driver issues on ARM64 Marc Zyngier <marc.zyngier@arm.com> - 2016-12-09 12:00 +0100
        Re: ATH9 driver issues on ARM64 Marc Zyngier <marc.zyngier@arm.com> - 2016-12-09 12:30 +0100

csiph-web