Firmware debugging patches?

Kalle Valo kvalo at qca.qualcomm.com
Sat Jun 7 06:03:31 PDT 2014


Ben Greear <greearb at candelatech.com> writes:

> On 06/05/2014 11:51 PM, Kalle Valo wrote:
>> Ben Greear <greearb at candelatech.com> 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.

-- 
Kalle Valo



More information about the ath10k mailing list