Warning/Oops report of the week of September 16th, 2008

Warning/Oops report of the week of September 16th, 2008

[Arjan van de Ven]

This is the first report where I've dropped oopses that happened to 2.6.25 or earlier kernels.
I've also changed the format of the report to split it in "fixed" and "not yet fixed" sections;
I hope that makes the report more useful for developers.



This week, a total of 1730 oopses and warnings have been reported,
compared to 626 reports in the previous week.


Per file statistics
266	net/sched/sch_generic.c
260	kernel/timer/tglx.c
167	drivers/ata/libata-sff.c
154	external/utrace
80	net/core/dev.c
62	drivers/parport/procfs.c
54	external/fireglx/binary (P)
45	fs/jbd/journal.c
38	kernel/timer.c
34	drivers/base/power/main.c
27	lib/scatterlist.c
25	kernel/sched.c
23	include/asm-x86/irqflags.h


Not yet fixed issues
====================

Rank 1: dev_watchdog (warning)
	Reported 263 times (495 total reports)
	Network card timeout; this error is currently not specific enough, a patch
	is pending to get this reported per driver, with some luck this gets merged soon.
	This warning was last seen in version 2.6.27-rc6, and first seen in 2.6.26-rc3.
	More info: http://www.kerneloops.org/searchweek.php?search=dev_watchdog

Rank 4: utrace_control (oops)
	Reported 149 times (152 total reports)
	[fedora] Fedora merged a broken utrace patch
	This oops was last seen in version 2.6.26.3, and first seen in 2.6.26.1.
	More info: http://www.kerneloops.org/searchweek.php?search=utrace_control

Rank 6: parport_device_proc_register (warning)
	Reported 62 times (3942 total reports)
	Duplicate /proc registration in the parport driver
	This warning was last seen in version 2.6.26.3, and first seen in 2.6.24-rc5.
	More info: http://www.kerneloops.org/searchweek.php?search=parport_device_proc_register

Rank 7: firegl_ioctl (warning)
	Reported 50 times (2479 total reports)
	[external] Bug in the proprietary fireglx driver
	warning only shows up in tainted kernels
	This warning was last seen in version 2.6.26.5, and first seen in 2.6.25.
	More info: http://www.kerneloops.org/searchweek.php?search=firegl_ioctl

Rank 8: journal_update_superblock (warning)
	Reported 44 times (3767 total reports)
	Likely caused by the user removing a USB stick while mounted
	This warning was last seen in version 2.6.27-rc6, and first seen in 2.6.24-rc6-git1.
	More info: http://www.kerneloops.org/searchweek.php?search=journal_update_superblock

Rank 9: run_timer_softirq (oops)
	Reported 36 times (76 total reports)
	softlockup; might be fixed by Thomas' HPET fixes
	This oops was last seen in version 2.6.27-rc1-git4, and first seen in 2.6.25.
	More info: http://www.kerneloops.org/searchweek.php?search=run_timer_softirq

Rank 10: device_pm_add (warning)
	Reported 29 times (122 total reports)
	This warning was last seen in version 2.6.27-rc4, and first seen in 2.6.26-rc5.
	More info: http://www.kerneloops.org/searchweek.php?search=device_pm_add

Rank 12: native_safe_halt (oops)
	Reported 23 times (122 total reports)
	This oops was last seen in version 2.6.27-rc5, and first seen in 2.6.24.
	More info: http://www.kerneloops.org/searchweek.php?search=native_safe_halt

Rank 13: account (warning)
	Reported 13 times (16 total reports)
	This warning was last seen in version 2.6.26.3, and first seen in 2.6.26.
	More info: http://www.kerneloops.org/searchweek.php?search=account

Rank 14: lock_page (warning)
	Reported 12 times (31 total reports)
	This warning was last seen in version 2.6.27-rc6, and first seen in 2.6.27-rc1-git2.
	More info: http://www.kerneloops.org/searchweek.php?search=lock_page

Fixed issues
============


Rank 2: tick_dev_program_event (warning)
	Reported 260 times (282 total reports)
	[debug] temporary WARN_ON() inserted in -rc5 for diagnostics purposes, removed for -rc6
	This warning was last seen in version 2.6.27-rc5-git10, and first seen in 2.6.27-rc5.
	More info: http://www.kerneloops.org/searchweek.php?search=tick_dev_program_event

Rank 3: ata_sff_hsm_move (warning)
	Reported 167 times (300 total reports)
	[fixed] redundant WARN_ON; fixed in 9c2676b61a5a4b6d99e65fb2f438fb3914302eda
	This warning was last seen in version 2.6.27-rc2-git1, and first seen in 2.6.25.4.
	More info: http://www.kerneloops.org/searchweek.php?search=ata_sff_hsm_move

Rank 5: __netif_schedule (warning)
	Reported 74 times (559 total reports)
	[fixed] issue as a result of the multiqueue feature, fixed for 2.6.27-rc1
	This warning was last seen in version 2.6.27-rc0-git11, and first seen in 2.6.26-rc8-git.
	More info: http://www.kerneloops.org/searchweek.php?search=__netif_schedule

Rank 11: sg_copy_buffer (warning)
	Reported 27 times (29 total reports)
	[fixed] by making the locks _irqsave (and backported to -stable)
	This warning was last seen in version 2.6.26.5, and first seen in 2.6.26-rc6.
	More info: http://www.kerneloops.org/searchweek.php?search=sg_copy_buffer



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Warning/Oops report of the week of September 16th, 2008

[Jay Cliburn]

On Tue, 16 Sep 2008 09:22:06 -0700
Arjan van de Ven <arjan@infradead.org> wrote:


> Not yet fixed issues
> ====================
> 
> Rank 1: dev_watchdog (warning)
> 	Reported 263 times (495 total reports)
> 	Network card timeout; this error is currently not specific
> enough, a patch is pending to get this reported per driver, with some
> luck this gets merged soon. This warning was last seen in version
> 2.6.27-rc6, and first seen in 2.6.26-rc3. More info:
> http://www.kerneloops.org/searchweek.php?search=dev_watchdog

Some of these are undoubtedly from the atl1 driver, and many of those
from that driver are probably from me personally as I've poked around
trying to isolate the cause.  I sent a patch yesterday to Alexey
Dobriyan (who's also been experiencing it) that seems to quash the
warnings, so hopefully we're near resolution.  On my own development
system I recently turned off kerneloops, so at least *my* contribution
to the list will diminish.  :)

Jay

Re: Warning/Oops report of the week of September 16th, 2008

[Frans Pop]

(Dropped a few irrelevant lists.)

> Rank 6: parport_device_proc_register (warning)
>         Reported 62 times (3942 total reports)
>         Duplicate /proc registration in the parport driver
>         This warning was last seen in version 2.6.26.3, and first seen
>         in 2.6.24-rc5.

Note that I'm still seeing this in 2.6.27-rc7. This is now one of the 
oldest entries in the list and as it happens for *every* print job, it's 
quite an annoying one.

Unfortunately I still cannot get kerneloops to work for me.

Re: Warning/Oops report of the week of September 16th, 2008

[Linus Torvalds]

On Thu, 25 Sep 2008, Frans Pop wrote:
> 
> > Rank 6: parport_device_proc_register (warning)
> >         Reported 62 times (3942 total reports)
> >         Duplicate /proc registration in the parport driver
> >         This warning was last seen in version 2.6.26.3, and first seen
> >         in 2.6.24-rc5.
> 
> Note that I'm still seeing this in 2.6.27-rc7. This is now one of the 
> oldest entries in the list and as it happens for *every* print job, it's 
> quite an annoying one.
> 
> Unfortunately I still cannot get kerneloops to work for me.

Al and Arjan looked at this one at the KS, and quite frankly, the warning 
is just bogus.

Or rather, it's a warnign about the parport /proc interface. The fact is, 
the parport code can generate multiple "instances" of things that 
time-slice on the port, but they have all ended up always just registering 
under the same name. IOW, it's a bug in the _user_ interface, not the 
kernel.

I'd like to remove the file entirely (probably nobody uses it), but Al 
said he could perhaps send patches to extend it (yet leave the old name to 
point to the first instance, the way it always has). 

In the meantime, that warning is just best ignored entirely. It's not a 
kernel bug per se, or even anything that is fixable without changing 
exported user interfaces that in my opinion aren't necessarily even 
_worth_ changing (the only reasonable change is extending on the insane 
interface that nobody cares about).

I think Arjan agreed to just remove it from his statistics, but maybe he's 
just ignoring _new_ entries ;)

			Linus

Re: Warning/Oops report of the week of September 16th, 2008

[Arjan van de Ven]

On Wed, 24 Sep 2008 15:45:30 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> I think Arjan agreed to just remove it from his statistics, but maybe
> he's just ignoring _new_ entries ;)

yeah I blacklisted it on submission; I haven't removed it from the
database


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Warning/Oops report of the week of September 16th, 2008

[Linus Torvalds]

On Wed, 24 Sep 2008, Linus Torvalds wrote:
> 
> Or rather, it's a warnign about the parport /proc interface. The fact is, 
> the parport code can generate multiple "instances" of things that 
> time-slice on the port, but they have all ended up always just registering 
> under the same name. IOW, it's a bug in the _user_ interface, not the 
> kernel.

Side note: the reason nobody cares is that the files exported there are 
likely never used anyway. But we don't _know_ that. Maybe somebody depends 
on the totally broken things that get registered in /proc. I doubt it, 
but..

		Linus

Re: Warning/Oops report of the week of September 16th, 2008

[Frans Pop]

On Thursday 25 September 2008, Linus Torvalds wrote:
> In the meantime, that warning is just best ignored entirely. It's not a
> kernel bug per se, or even anything that is fixable without changing
> exported user interfaces that in my opinion aren't necessarily even
> _worth_ changing (the only reasonable change is extending on the insane
> interface that nobody cares about).

Yep, I agree it's basically harmless and I have been ignoring it. But that 
does not make it less annoying as, because of the call trace, it will 
continue to show up in logcheck mails every time.

If no other solution is found soon, would a patch to just skip the sysctl 
table check for this particular case be acceptable?

Re: Warning/Oops report of the week of September 16th, 2008

[Linus Torvalds]

On Thu, 25 Sep 2008, Frans Pop wrote:
> 
> If no other solution is found soon, would a patch to just skip the sysctl 
> table check for this particular case be acceptable?

Well, it would be even _more_ acceptable to have a new Kconfig option that 
just disables the insane parport registrations.

Them you could turn off the /proc files, and if it turns out you don't 
have anything that uses it, you can avoid the warning by actually having a 
smaller kernel with less crap, rather than adding more crap to hide the 
crap. Wouldn't that be nicer?

It would have to be a Kconfig option since we don't _know_ that it's not 
used by anything..

		Linus

Re: Warning/Oops report of the week of September 16th, 2008

[Alan Cox]

> In the meantime, that warning is just best ignored entirely. It's not a 
> kernel bug per se, or even anything that is fixable without changing 
> exported user interfaces that in my opinion aren't necessarily even 
> _worth_ changing (the only reasonable change is extending on the insane 
> interface that nobody cares about).

How about a quickfix for the moment. This ought to do the job. BTW I
disagree that the link should be to first, it would be best a link to the
active driver IMHO.

Has been Torvalds-tested only (ie it compiled)

--

parport: quickfix the proc registration bug

From: Alan Cox <alan@redhat.com>

Ideally we should have a directory of drivers and a link to the 'active'
driver. For now just show the first device which is effectively the existing
semantics without a warning.

Signed-off-by: Alan Cox <alan@redhat.com>
---

 drivers/parport/share.c   |   13 ++++++++++---
 drivers/serial/8250_pci.c |    4 ++--
 include/linux/parport.h   |    4 ++++
 3 files changed, 16 insertions(+), 5 deletions(-)


diff --git a/drivers/parport/share.c b/drivers/parport/share.c
index a8a62bb..0750dcb 100644
--- a/drivers/parport/share.c
+++ b/drivers/parport/share.c
@@ -614,7 +614,10 @@ parport_register_device(struct parport *port, const char *name,
 	 * pardevice fields. -arca
 	 */
 	port->ops->init_state(tmp, tmp->state);
-	parport_device_proc_register(tmp);
+	if (test_and_set_bit(PARPORT_DEVPROC_REGISTERED, &port->devflags)) {
+		port->proc_device = tmp;
+		parport_device_proc_register(tmp);
+	}
 	return tmp;
 
  out_free_all:
@@ -646,10 +649,14 @@ void parport_unregister_device(struct pardevice *dev)
 	}
 #endif
 
-	parport_device_proc_unregister(dev);
-
 	port = dev->port->physport;
 
+	if (port->proc_device == dev) {
+		port->proc_device = NULL;
+		clear_bit(PARPORT_DEVPROC_REGISTERED, &port->devflags);
+		parport_device_proc_unregister(dev);
+	}
+
 	if (port->cad == dev) {
 		printk(KERN_DEBUG "%s: %s forgot to release port\n",
 		       port->name, dev->name);
diff --git a/include/linux/parport.h b/include/linux/parport.h
index 6a0d7cd..986252e 100644
--- a/include/linux/parport.h
+++ b/include/linux/parport.h
@@ -326,6 +326,10 @@ struct parport {
 	int spintime;
 	atomic_t ref_count;
 
+	unsigned long devflags;
+#define PARPORT_DEVPROC_REGISTERED	0
+	struct pardevice *proc_device;	/* Currently register proc device */
+
 	struct list_head full_list;
 	struct parport *slaves[3];
 };

Re: Warning/Oops report of the week of September 16th, 2008

[Frans Pop]

On Friday 26 September 2008, Alan Cox wrote:
> parport: quickfix the proc registration bug
>
> From: Alan Cox <alan@redhat.com>
>
> Ideally we should have a directory of drivers and a link to the
> 'active' driver. For now just show the first device which is
> effectively the existing semantics without a warning.
>
> Signed-off-by: Alan Cox <alan@redhat.com>

Thanks Greg, but I'm afraid that still gives me the error:

ppdev0: registered pardevice
sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice  
Sysctl already exists
Pid: 7104, comm: hpijs Not tainted 2.6.27-rc7 #21

Call Trace:
 [<ffffffff8024d2ac>] set_fail+0x48/0x53
 [<ffffffff8024d7a1>] sysctl_check_table+0x4ea/0x531
 [<ffffffff8024d7ba>] sysctl_check_table+0x503/0x531
 [<ffffffff8024d7ba>] sysctl_check_table+0x503/0x531
 [<ffffffff8024d7ba>] sysctl_check_table+0x503/0x531
 [<ffffffff8024d7ba>] sysctl_check_table+0x503/0x531
 [<ffffffff8024d7ba>] sysctl_check_table+0x503/0x531
 [<ffffffff8023b378>] ? sysctl_set_parent+0x24/0x39
 [<ffffffff8023c66e>] __register_sysctl_paths+0xee/0x29e
 [<ffffffff80314f05>] ? sprintf+0x68/0x6a
 [<ffffffff8023c847>] register_sysctl_paths+0x29/0x2b
 [<ffffffff8023c85c>] register_sysctl_table+0x13/0x15
 [<ffffffffa00f79d4>] parport_device_proc_register+0xcc/0xf0 [parport]
 [<ffffffffa00f5a07>] parport_register_device+0x25c/0x296 [parport]
 [<ffffffffa03c9a3b>] ? pp_irq+0x0/0x4b [ppdev]
 [<ffffffffa03c93e2>] pp_ioctl+0x16f/0x7c8 [ppdev]
 [<ffffffff80282894>] ? free_pages_and_swap_cache+0x57/0x72
 [<ffffffff8029abbe>] vfs_ioctl+0x2a/0x78
 [<ffffffff8029ae63>] do_vfs_ioctl+0x257/0x274
 [<ffffffff8029aed5>] sys_ioctl+0x55/0x78
 [<ffffffff8020c1eb>] system_call_fastpath+0x16/0x1b

ppdev0: registered pardevice
ppdev0: unregistered pardevice
ppdev0: unregistered pardevice

Cheers,
FJP