Firmware debugging patches?
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
> 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.
More information about the ath10k