From: Peter Zijlstra <peterz@infradead.org>
To: Borislav Petkov <bp@alien8.de>
Cc: arapov@gmail.com, poros@redhat.com,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, matt@console-pimps.org
Subject: Re: FW/BIOS Bug category for oops.kernel.org
Date: Mon, 3 Nov 2014 22:51:06 +0100 [thread overview]
Message-ID: <20141103215106.GC10501@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20141103213442.GB27387@pd.tnic>
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 ;-)
prev parent reply other threads:[~2014-11-03 21:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 21:26 FW/BIOS Bug category for oops.kernel.org Peter Zijlstra
2014-11-03 21:34 ` Borislav Petkov
2014-11-03 21:51 ` Peter Zijlstra [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141103215106.GC10501@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=arapov@gmail.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=poros@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.