Re: Top kernel oopses/warnings this week

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Arjan van de Ven wrote:
> Stefan Richter wrote:
>> Report counts may be too high due to duplicate recognition of the very
>> same report.
> 
> this is true however it's .. a hard issue. It's really hard to
> distinguish a duplicate report from two reports of the same bug.

Would be nice though to try to find duplicates like the example I gave.
(The actual report and a reply was listed.  The reply just had a full
quote of the oops, with "> " prepended and perhaps lines wrapped.)
Because if an oops is independently reported twice or more, this too
says something about the issue.  E.g. flaky RAM and such is pretty much
eliminated as a possible cause.

Anyway, someone who is actually interested in a particular oops and
looks at the posts in your links quickly notices eventual duplicates.
But it would be helpful to people who only have a quick glance at the
bar graphs if you add a note of caution that the figures are not
accurate and not representative, e.g. because of occasional duplicates.

For the same reason, please don't write headings like "Oops statistics
for kernel 2.6.23-release".  Unless you mean "statistics" in a narrower
sense like they do statistics in medicine and economics. ;-)
Simply write "Oops reports for kernel...".

>> Reports against 2.6.X-rcY-mmZ are listed in the same category as reports
>> against 2.6.X-rcY.  To distinguish -mm reports from vanilla reports, one
>> has to look into the details of each bug entry.¹
> 
> finding what exact kernel version an oops is from is... surprisingly hard.
> And to be honest, bugs against -mm are still very interesting, since
> they'll be the next mainline after all

Yes, they definitely are interesting.  And it's the same like with the
above issue:  People who are genuinely interested in an oops find the
necessary information at the details page.  Separating them from
mainline oopses would be a service though for people who want to
  - have a quick look at what's urgent and what's not so urgent,
  - draw conclusions about the state of the release candidates.
So this is not that important.
-- 
Stefan Richter
-=====-=-=== ==-- -====
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/