login
Search
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: ...
On Tue, 16 Sep 2008 09:22:06 -0700 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 --
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 --
On Wed, 24 Sep 2008 15:45:30 -0700 (PDT) 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 --
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 --
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? --
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 --
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 ...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 --