> >>>>> 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@xxxxxxxxxxxxxxx> > Candela Technologies Inc http://www.candelatech.com > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
