Fwd: ath10k related kernel crash in wireless-testing (3.12.0-rc3-wl+)

[Kalle Valo]

Michal Kazior <michal.kazior at tieto.com> writes:

> On 17 October 2013 01:43, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>>
>>> Ben Greear <greearb at candelatech.com> writes:
>>>
>>>> I sent this to the wrong list the first time.
>>>>
>>>> Do you know if this is already addressed?  If not, I'll see if I can
>>>> find a fix.
>>>
>>> [...]
>>>
>>>> ath10k: MSI-X interrupt handling (8 intrs)
>>>> ath10k: Unable to wakeup target
>>>> ath10k: target took longer 5000 us to wake up (awake count 1)
>>>> ath10k: Failed to get pcie state addr: -16
>>>> ath10k: early firmware event indicated
>>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
>>>> IP: [<ffffffffa06ae46c>] ath10k_ce_completed_send_next+0x47/0x122
>>>> [ath10k_pci]
>
> Hmm.. if BMI handlers are set then must've been CE is allocated
> earlier. I'm suspecting this is because ath10k_pci_ce_deinit() gets
> called on ath10k_pci_power_up() failpath before interrupts are
> disabled/hanlders unregistered.
>
> In that case the solution is to fix the failpath in
> ath10k_pci_power_up(). Disabling interrupts or moving
> ath10k_pci_ce_deinit() before the very return statement in
> ath10k_pci_hif_power_up()'s failpath should suffice. It should be safe
> to call ath10k_pci_ce_deinit() without calling to
> ath10k_pci_ce_init().

But doesn't that will still leave the race of having interrupts enabled
but tasklet handler not properly initialised? I think the right fix is
to first initialise everything and only then enable interrupts.

-- 
Kalle Valo