Re: Firmware debugging patches?

[Ben Greear <greearb@candelatech.com>]

On 06/05/2014 04:06 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
> 
>> On 06/02/2014 12:29 PM, Emmanuel Grumbach wrote:
>>
>>> Different TLV based binary blobs concatenated. The actual encoding of
>>> each of them is another story.
>>
>> Should we try to make the 'Type' in TLV be consistent as convenient
>> across different drivers?  That might someday help auto-reporting
>> tools?
> 
> I don't see the need for that as all firmwares are so different anyway.
> As long as there's some magic string to recognize/verify for which
> firmware it is we should be ok.
> 
>> It does not resolve my interest in firmware logs interleaved with
>> kernel logs and possibly supplicant, however.
>>
>> Looks like trace-cmds could do that, but it will not be
>> running for normal users when they experience crashes.
>>
>> Any suggestions other than printk for this feature?
> 
> 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.  That is enough to get a backtrace out of the firmware
most of the time, and almost every system that has any ability
to be debugged at all will be able to capture that text from
a kernel log file.

I like the printk for the same reason you like the trace:  It shows
things interleaved with other messages, and it is 'always on' unlike
trace, which has to be manually enabled and will not be running by default
on user's systems.

That said, I think there is no need to argue further on this.  Let's
get the debugfs dump stuff working, and maybe it will be good
enough.  It will certainly be better that what is currently
upstream.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com