Firmware debugging patches?

Ben Greear greearb at
Sat Jun 7 08:27:14 PDT 2014

On 06/07/2014 06:03 AM, Kalle Valo wrote:
> Ben Greear <greearb at> writes:
>> On 06/05/2014 11:51 PM, Kalle Valo wrote:
>>> Ben Greear <greearb at> writes:
>>>>> Why do you want to put the crash dump in kernel log, can you describe
>>>>> your "use case" here? For me it would be enough to have a UUID for each
>>>>> crash dump and then have the driver print that to kernel log:
>>>>> ath10k: firmware crashed (uuid 1234567890-4321)
>>>>> And then you just need to find the correct dump from the file system and
>>>>> start debugging. Would that be enough for you?
>>>> Not all systems will have fancy user-space able to deal with this.
>>>> At the very least, please leave in the current firmware crash
>>>> dump text.
>>> I'm not removing anything. That was just an example how we can identify
>>> crashes.
>> Perhaps the time-stamp is good enough?  I don't see a need for
>> a uuid, but perhaps I am missing something?
> UUID is supposed to be unique. If we use walltime there's no guarantee
> that the clock is correct and if we use local_clock() (my preference) it
> will be reset after every boot.
> I just think using something like UUID is more robust. Especially if one
> implements an automatic crash dump collector from thousands of deployed
> APs, having an UUID makes it a lot easier to manage.

I can add since-boot timestamp as well.  Time-since-boot is less likely
to be unique than wall-time, and for systems that do have proper wall-time
clock configured, I think that provides some useful info.  (Would be interesting
if all APs in a stadium crashed near the same time, for instance.)

I was thinking we should not add a MAC to the dump, for privacy concerns,
but whatever user-space tools gather the dump could add MAC if user perfers.

With time-of-day, time-since-boot, and MAC, each dump should be unique.


Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list