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

[Michal Kazior]

On 17 October 2013 23:29, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> 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.

Yes. It would still leave that case broken.


Michał