Repeated firmware crash when admin down.
Ben Greear
greearb at candelatech.com
Mon Mar 23 17:30:35 PDT 2015
The user reports this does indeed fix the problem.
Thanks,
Ben
On 03/22/2015 11:37 PM, Michal Kazior wrote:
> 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ł
>
--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k
mailing list