From: Arjan van de Ven <arjan@...>
Subject: Top kernel oopses/warnings this week
Date: Dec 14, 2:46 pm 2007

The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas; below is a top 10

list of the oopses collected in the last 7 days. (Reports prior to 2.6.23 have been omitted in collecting the top 10)
This is the first such report that I'm posting; Please let me know if this is useful or not.
hid_output_report warning

	Warning at drivers/hid/hid-core.c:784 implement()

	16 times last week
	More Info: http://www.kerneloops.org/search.php?search=implement
softlockup in tick_broadcast_oneshot_control

	3 times last week

	Only seen in 2.6.24-rc4 so far

	More Info: http://www.kerneloops.org/oops.php?number=2409
hiddev_ioctl crash

	3 times last week

	Only seen in 2.6.24-rc3 so far

	More Info: http://www.kerneloops.org/oops.php?number=2428
shrink_dcache_for_umount_subtree crash

	BUG at fs/dcache.c:595

	2 times last week

	Has been seen as far back as 2.6.18

	More Info: http://www.kerneloops.org/oops.php?number=2365

	More Info: http://www.kerneloops.org/search.php?search=shrink_dcache_for_umount_sub...
cpufreq_remove_dev crash

	BUG at drivers/cpufreq/cpufreq.c:1060

	2 times last week

	Has been reported only for 2.6.24-rc4

	More Info: http://www.kerneloops.org/search.php?search=cpufreq_remove_dev

	More Info: http://www.kerneloops.org/oops.php?number=2458
journal_dirty_data crash (tainted)

	BUG at fs/jbd/transaction.c:983

	2 times last week

	Has been reported only in 2.6.23.9

	http://www.kerneloops.org/search.php?search=journal_dirty_data
tcp_fastretrans_alert

	WARNING at net/ipv4/tcp_input.c:2533 tcp_fastretrans_alert()

	2 times last week

	Has been reported in 2.6.24-rc4 and -rc5

	More Info: http://www.kerneloops.org/search.php?search=tcp_fastretrans_alert	
tcp_sacktag_one

	WARNING at net/ipv4/tcp_input.c:1280 tcp_sacktag_one()

	Reported once

	Has only been seen in -rc5 so far

	More Info: http://www.kerneloops.org/search.php?search=tcp_sacktag_one
simple_map_write (MTD)

	kernel crash

	Reported once this week on 2.6.24-rc5

	Has been seen as far back as 2.6.17

	More Info: http://www.kerneloops.org/search.php?search=simple_map_write
tcp_sacktag_walk

	WARNING at net/ipv4/tcp_input.c:1280

	Reported once on 2.6.24-rc5

	Has been seen only on 2.6.24-rc5

	More Info: http://www.kerneloops.org/search.php?search=tcp_sacktag_walk

--



From: Andrew Morton <akpm@...>
Subject: Re: Top kernel oopses/warnings this week
Date: Dec 14, 5:57 pm 2007

On Fri, 14 Dec 2007 10:46:36 -0800 Arjan van de Ven  wrote:
> The http://www.kerneloops.org website collects kernel oops and warning

> reports from various mailing lists and bugzillas
Well that would have been fun to write.  Does it watch

https://lists.linux-foundation.org/mailman/listinfo/bugme-new ?

--



From: Stefan Richter <stefanr@...>
Subject: Re: Top kernel oopses/warnings this week
Date: Dec 15, 11:49 am 2007

Arjan van de Ven wrote:

> The http://www.kerneloops.org website collects kernel oops and warning

> reports from various mailing lists and bugzillas;
A few comments:
Report counts may be too high due to duplicate recognition of the very

same report.¹
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.¹
A general weakness is that it is ultimately impossible to know whether a

report was against an unpatched kernel, unless one drills down to the

individual mailinglist threads.
Reports about tainted kernels have arguably less value.  It would be

good to hide such reports until a report of the same oops in an

untainted kernel was found.
¹) example: http://www.kerneloops.org/oops.php?number=2335

--

Stefan Richter

-=====-=-=== ==-- -====

http://arcgraph.de/sr/

--



From: Arjan van de Ven <arjan@...>
Subject: Re: Top kernel oopses/warnings this week
Date: Dec 15, 2:21 pm 2007

Stefan Richter wrote:

> Arjan van de Ven wrote:

>> The http://www.kerneloops.org website collects kernel oops and warning

>> reports from various mailing lists and bugzillas;

>

> A few comments:

>

> 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.
>

> 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
>

> A general weakness is that it is ultimately impossible to know whether a

> report was against an unpatched kernel, unless one drills down to the

> individual mailinglist threads.
for the same reason patched kernels are relevant. And if someone has a super weirdo kernel,

well, as long as we get enough bug data it'll be way down in the noise.
> Reports about tainted kernels have arguably less value.  It would be

> good to hide such reports until a report of the same oops in an

> untainted kernel was found.

That's half of what is done right now; they're not hidden though, just very clearly marked.

--



From: Stefan Richter <stefanr@...>
Subject: Re: Top kernel oopses/warnings this week
Date: Dec 15, 3:44 pm 2007

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/

--