Top 9 kernel oopses/warnings for the week of December 29th, 2007

The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas as well as with a client users can install to auto-submit oopses. 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)

It has been a quiet week due to the holidays, only 55 oops traces have been collected.

Rank 1: sysctl_head_finish
sysctl table check failed
Reported 7 times
Only reported for the proprietary madwifi driver
More info: http://www.kerneloops.org/search.php?search=sysctl_head_finish

Rank 2: __ieee80211_rx

	Warning at net/mac80211/rx.c:1672
	Reported 5 times
	Only seen in 2.6.24-rc6 so far
	Johannes has diagnosed this as a driver bug in the iwlwifi drivers
	More info: http://www.kerneloops.org/search.php?search=__ieee80211_rx

Rank 3: rb_erase
Null pointer dereference
Reported 4 times
Only seen in 2.6.24-rc6 so far
(Note: the reported removed the oops end marker manually; may be duplicate reports)
More info: http://www.kerneloops.org/guilty.php?version=2.6.24-rc6&guilty=rb_erase&start=1574400&end=1574400

Rank 4: remove_proc_entry
Warning at fs/proc/generic.c:736
Reported 4 times for 2.6.24-rc4 and rc5 (Mandrake)
Seems to be a module unload issue
More info: http://www.kerneloops.org/search.php?search=remove_proc_entry

Rank 5: aes_encrypt
Invalid kernel pointer oops
Reported 2 times for 2.6.23.11
More info: http://www.kerneloops.org/search.php?search=aes_encrypt

Rank 6: cascade
BUG statement at kernel/timer.c:606
Reported 2 times for 2.6.23 (Gentoo)
More info: http://www.kerneloops.org/search.php?search=cascade

Rank 7: kref_put
Kernel paging request
Reported 2 times, only for 2.6.24-rc6-mm1
Diagnosed as a bug in the md-subsystem, patch available More info: http://www.kerneloops.org/search.php?search=kref_put
More info: http://article.gmane.org/gmane.linux.kernel/618056

Rank 8: device_release
Warning at drivers/base/core.c:107
Reported 2 times last week, 6 incidents total
Seems to be a bug in the MTD physmap driver and the hgafb driver More info: http://article.gmane.org/gmane.linux.kernel/618076
More info: http://article.gmane.org/gmane.linux.kernel/618076

Rank 9: mutex_lock
Null pointer dereference
Reported 2 times, of which one was a duplicate report
Seems to be related to running PPP over a bluetooth link
More info: http://www.kerneloops.org/guilty.php?version=2.6.24-rc6&guilty=mutex_lock&start=1574400&end=1574400

kerneloops.org news:
* As of 2.6.24-rc6, oopses have a unique identifier which makes it possible to filter out duplicate reports of (and replies to) the same oops. Unfortunately some reporters remove this line from their reports to lkml.

i'd not mind printing out the bootup-ID as a regular part of the oops, as long as it's put into an unintrusive place, preferably without adding a new line. (just use an empty spot somewhere)

for example:

Call Trace: (ID afbf0104e2079481)
 [<ffffffff805079f6>] sysdev_driver_unregister+0x5b/0x91
 [<ffffffff806f2ef4>] cpufreq_register_driver+0x15a/0x19b
 [<ffffffff80cb0586>] powernowk8_init+0x86/0x94

Ingo

This would be more useful if it was more readable. As it is, you seem to have some formatting errors in your automation, where the things are incorrectly grouped:

ie notice how that "Rank 2" got reported as if it was part of the "Rank 1" issue.

Linus

this is manual made; I'll blame thunderbird for now

let me see if I can send it again without corruption

hmmm.. the copy in my Sent folder looks fine, as does the one in the lkml archive:
http://lkml.org/lkml/2007/12/29/41

This is distinctly weird.

Ahh, it seems to be a alpine bug. Probably brought on by alpine trying to highlight the web addresses.

It doesn't always happen - between Rank 3 and Rank 4, you have an empty line, and alpine reacted correctly to that one, but the "empty" line between Rank 1 and Rank 2 actually contained a single TAB, and that apparently made alpine really confused.

So never mind. I'll make a bug-report on alpine, it wasn't a bug in your email.

Linus

FYI, exactly the same thing happens with pine.

/Martin

The bug is also present in the original branch, called pine 4.64 ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Shows up correctly here. Random guess is that your MUA treats tabs like spaces when it sees format=flowed. The lines between the different ranks weren't empty but had a single tab. And for whatever reason (I don't see any trailing spaces), Arjan's mail had a format=flowed header.

AFAIK, only SPACE CRLF is valid for line-continuation with format=flowed, not TAB CRLF. So the above formatting would be the result of a pointless format=flowed header meeting a MUA that was too eager searching for line continuations.

Björn