[PATCH 1/2] ath10k: save firmware stacks upon firmware crash

Kalle Valo kvalo at qca.qualcomm.com
Tue Sep 23 06:23:57 PDT 2014


greearb at candelatech.com writes:

> From: Ben Greear <greearb at candelatech.com>
>
> Should help debug firmware crashes, and give users a way
> to provide some useful debug reports to firmware developers.
>
> Signed-off-by: Ben Greear <greearb at candelatech.com>
> Signed-off-by: Kalle Valo <kvalo at qca.qualcomm.com>

Like we talked on IRC, I think it's better to take a dump of the whole
DRAM and find all the info during postprocessing in user space. I just
consider it too much work to investigate firmware internals from ath10k
as the internals can change between firmware versions. In user space
that's a lot easier to manage.

Of course downside is the increased memory usage, but if that becomes a
problem there are ways to solve that. For example, adding a module
parameter with bitmask for individually enabling enum
ath10k_fw_crash_dump_type is first which comes to my mind.

I have patches ready for the DRAM thing, but I have some issues which I
found during testing. I'll post the patches soon as I have solved the
issues, but don't know how long that will take.

-- 
Kalle Valo



More information about the ath10k mailing list