Repeated firmware crash when admin down.

Ben Greear greearb at
Mon Mar 23 17:30:35 PDT 2015

The user reports this does indeed fix the problem.


On 03/22/2015 11:37 PM, Michal Kazior wrote:
> On 20 March 2015 at 22:46, Ben Greear <greearb at> 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]:
> Michał

Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list