Firmware debugging patches?
kvalo at qca.qualcomm.com
Sun Jun 8 01:35:28 PDT 2014
Ben Greear <greearb at candelatech.com> writes:
>>> 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.
The MAC addresses can be extracted from the target memory anyway so I
don't see harm from including that in the dump. Is it even possible to
address all privacy issues when dealing with firmware dumps?
> With time-of-day, time-since-boot, and MAC, each dump should be unique.
But I would like to easily match from kernel log that the crash dump
matches with log. uuid would provide that in a simple way (check that
the uuid in the log matches with the uuid in the dump). What's so bad
from using uuid?
More information about the ath10k