FW/BIOS Bug category for oops.kernel.org

FW/BIOS Bug category for oops.kernel.org

[Peter Zijlstra]

Hi oops.kernel.org folks,

I'm wanting to collect information on FW/BIOS bugs, and I figured that
we could use the oops.kernel.org infrastructure to do this.

Now, I'd prefer to not use the regular BUG/WARN because it might confuse
users and the stacktrace is entirely pointless -- we know were/why we
generate the msgs.

Is everything between:

        pr_warn("------------[ cut here ]------------\n");
and:
        pr_warn("---[ end trace %016llx ]---\n", (unsigned long long)oops_id);

sucked in automagically, or do we need more magic?

I was thinking of adding a body like:

	FW/BIOS fail: $msg
	Hardware name: $dump_stack_arc_desc_str
	CPU model name: $cpuinfo_x86->x86_model_id

Which would allow us to index on both CPU and Hardware.


Can we make this happen?

Re: FW/BIOS Bug category for oops.kernel.org

[Borislav Petkov]

On Mon, Nov 03, 2014 at 10:26:10PM +0100, Peter Zijlstra wrote:
> Hi oops.kernel.org folks,
> 
> I'm wanting to collect information on FW/BIOS bugs, and I figured that
> we could use the oops.kernel.org infrastructure to do this.
> 
> Now, I'd prefer to not use the regular BUG/WARN because it might confuse
> users and the stacktrace is entirely pointless -- we know were/why we
> generate the msgs.
> 
> Is everything between:
> 
>         pr_warn("------------[ cut here ]------------\n");
> and:
>         pr_warn("---[ end trace %016llx ]---\n", (unsigned long long)oops_id);
> 
> sucked in automagically, or do we need more magic?

Btw, we have FW_{BUG,WARN,INFO} macros for exactly firmware issues.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: FW/BIOS Bug category for oops.kernel.org

[Peter Zijlstra]

On Mon, Nov 03, 2014 at 10:34:43PM +0100, Borislav Petkov wrote:
> On Mon, Nov 03, 2014 at 10:26:10PM +0100, Peter Zijlstra wrote:
> > Hi oops.kernel.org folks,
> > 
> > I'm wanting to collect information on FW/BIOS bugs, and I figured that
> > we could use the oops.kernel.org infrastructure to do this.
> > 
> > Now, I'd prefer to not use the regular BUG/WARN because it might confuse
> > users and the stacktrace is entirely pointless -- we know were/why we
> > generate the msgs.
> > 
> > Is everything between:
> > 
> >         pr_warn("------------[ cut here ]------------\n");
> > and:
> >         pr_warn("---[ end trace %016llx ]---\n", (unsigned long long)oops_id);
> > 
> > sucked in automagically, or do we need more magic?
> 
> Btw, we have FW_{BUG,WARN,INFO} macros for exactly firmware issues.

They're more like printk prefixes, while we can continue to use them
inside the body, prefixing the actual msg, I think we need more.

Just using those will not get the data out of the machine, not have it
associated with hardware strings.

I want to know how often various FW fails still happen out there and I
want to have a list of hardware to avoid buying ;-)