Firmware debugging patches?

[Emmanuel Grumbach]

>
>>>>> a) Normal Fedora/Ubuntu/etc default-installed distribution user
>>>>> with ath10k NIC has wifi issues, firmware crashes, they don't
>>>>> really know what firmware means or that it crashed, but some automated crash-log
>>>>> tool notices and gathers debug info for automated bug reporting.
>>>>
>>>> I am working on that for our firmware. I recently added such capability relying on udev to notify the userspace that something bad happens. I gather all the data and prepare a binary file that is sent through debugfs (pulled by a script triggered by udev). I remember the first crash only.
>>>
>>> How is this binary blob encoded?
>>
>> 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?
>
> Do you have a link to your patch that defines the types you used?
>

Take a look at 1bd3cbc1a0e9ed977a6bd470c5bc7bd36fd87e26.
But I am adding more and more content to this file.

>>> At least for drivers that can recover from firmware crashes, I think
>>> we should continue to report crashes, not just the first.
>>>
>>
>> I remember the first until udev kicks the script that will empty the
>> buffer. Then I take the second crash's log.
>
> Sounds good enough to me.
>
>>> Maybe could store another one after initial crash has been read
>>> and 1 minute has elapsed, or if initial crash has not been read
>>> in 1 day, or something like that.
>>>
>>> Also, if we use debugfs then we require upstream kernels to have this
>>> compiled in and mounted if we want to handle this class of user.
>>
>> Agreed. I rely on debugfs. But this is "just" the way to reach the filesystem.
>> Give me another way and I am fine with it.
>> FWIW Ubuntu which is not exactly the distribution of the super
>> advanced users has it mounted by default.
>
> That sounds promising...Looks like Fedora 20 does as well, so maybe
> debugfs will be good enough for crash dumps.
>
>
> 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?

I seems you found a way already :)

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