Repeated firmware crash when admin down.

Michal Kazior michal.kazior at tieto.com
Sun Mar 22 23:37:38 PDT 2015


On 20 March 2015 at 22:46, Ben Greear <greearb at candelatech.com> wrote:
> Someone reported this bug to me.  It is repeatable on various firmware,
> including my own and official QCA firmware.
>
> I am not certain of the hardware platform, but I think it might be a Ventana
> imx6 board.
>
> Kernel is based on 3.19-mumble.
>
> I cannot reproduce on x86 (but testing on 3.17 kernel and different flavour of
> Linux, so who knows.)
>
> They simply admin-down wlanX, and then the firmware crashes over and over.
> They cannot get any register dump.
> When they admin up the interface, the crashes stop and system resumes normally.
>
> I had them try it with my firmware and a driver patch
> which will attempt to do ping-pong register dump
> over pci register reads in case the firmware's normal PCI messaging transport
> is down, but the register value always reads as '0xdeadbeef'.
>
> Driver patch is linked below, 'val' is 0xdeadbeef after the million read attempts.

If you read MMIO registers while the device sleeps you get 0xdeadbeef.
I've recently posted a patch which should fix some of these[1].

I'm guessing the imx6 board could be using shared irq and the line is
shared with some other (active) device(s). This would lead to checking
registers in ath10k after ath10k_pci_sleep(). In that case my patch
should be sufficient.

[1]: https://github.com/kvalo/ath/commit/320e14b8db51a2d635897d521db4e5c79c3a8390


Michał



More information about the ath10k mailing list