Top bugreports for the week prior to January 21st 2008

Top bugreports for the week prior to January 21st 2008

[Arjan van de Ven]

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 9 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted in collecting the top 9)

This week, a total of 123 oopses and warnings have been reported.


Rank 1: implement
	WARN_ON in drivers/hid/hid-core.c:785
	Reported 30 times (92 total reports)
	Same issue as last week; the WARN_ON is in response to an invalid command
	sent from a (common) userspace application. This is clearly an obnoxious
	thing to do; an -EINVAL return from the ioctl() would have been nicer
	More info: http://www.kerneloops.org/search.php?search=implement

Rank 2: __ieee80211_rx_handle_packet
	WARN_ON in net/mac80211/rx.c:1702
	Reported 14 times (20 total reports)
	This is a bug in the iwl3945 driver and is already being worked on
	More info: http://www.kerneloops.org/search.php?search=__ieee80211_rx_handle_packet

Rank 3: set_dentry_child_flags
	WARN_ON in fs/inotify.c:172
	Only reported for pre-2.6.24 kernels
	Reported 9 times (15 total reports)
	Is inotify related
	More info: http://www.kerneloops.org/search.php?search=set_dentry_child_flags

Rank 4: uart_flush_buffer
	WARN_ON in drivers/serial/serial_core.c:544
	Reported 6 times (30 total reports)
	This is an old known issue; Andrew has a patch for it in -mm
	More info: http://www.kerneloops.org/search.php?search=uart_flush_buffer

Rank 5: __make_request
	This is a spinlock lockup when using the Oracle database application
	Reported 4 times (17 total reports)
	Sounds like something for Jens Axboe to chase down
	More info: http://www.kerneloops.org/search.php?search=__make_request

Rank 6: cache_grow
	WARN_ON in mm/slab.c:2779
	Reported 3 times, but only for PPC64 2.6.24-rc8
	More info: http://www.kerneloops.org/search.php?search=cache_grow

Rank 7: default_idle
	Reported 3 times (7 total reports)
	As always, crashes in the idle loop tend to be a symptom for hardware issues
	(Not only is the most wallclock time spent here, it's also a scenario for big
	swings in power consumption)
	More info: http://www.kerneloops.org/search.php?search=default_idle

Rank 8: down_read
	Only happened with a tripple-tainted kernel; probably not worth spending time on
	Reported 2 times (5 total reports)
	More info: http://www.kerneloops.org/search.php?search=down_read

Rank 9: acpi_idle_enter_bm
	As always, crashes in the idle loop tend to be a symptom for hardware issues
	(Not only is the most wallclock time spent here, it's also a scenario for big
	Reported 2 times (5 total reports)
	More info: http://www.kerneloops.org/search.php?search=acpi_idle_enter_bm