Firmware debugging patches?
egrumbach at gmail.com
Wed Jun 4 12:23:47 PDT 2014
>>>>> 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 :)
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
More information about the ath10k