From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750906AbWGGJZJ (ORCPT ); Fri, 7 Jul 2006 05:25:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750960AbWGGJZJ (ORCPT ); Fri, 7 Jul 2006 05:25:09 -0400 Received: from smtp.osdl.org ([65.172.181.4]:51328 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1750906AbWGGJZH (ORCPT ); Fri, 7 Jul 2006 05:25:07 -0400 Date: Fri, 7 Jul 2006 02:24:20 -0700 From: Andrew Morton To: Paul Drynoff Cc: linux-kernel@vger.kernel.org Subject: Re: linux-2.6.17-mm6: strange kobject message Message-Id: <20060707022420.6f58b58c.akpm@osdl.org> In-Reply-To: <20060707125942.fe3d467b.pauldrynoff@gmail.com> References: <20060707125942.fe3d467b.pauldrynoff@gmail.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 7 Jul 2006 12:59:42 +0400 Paul Drynoff wrote: > Here is dmesg which I got during boot, > the first part not interesting I already reported about it, > and I don't remember one of two things: Arjan van de Ven's patch was > lost or not good enough. The second part is related to kobject, > I'm not sure is it normal when kobject tell about -EEXIST and print stack? > Note that this is happened only once per 100 normal booting, I mean the second part. > > ================================= > [ INFO: inconsistent lock state ] > --------------------------------- > inconsistent {hardirq-on-W} -> {in-hardirq-W} usage. > dhclient/1952 [HC1[1]:SC0[1]:HE0:SE0] takes: > (&ei_local->page_lock){+...}, at: [] ei_interrupt+0x39/0x32c > {hardirq-on-W} state was registered at: > [] lock_acquire+0x57/0x74 > [] _spin_lock+0x1a/0x28 > [] ei_start_xmit+0x74/0x270 > [] dev_hard_start_xmit+0x1a9/0x1f8 > [] __qdisc_run+0xb6/0x1a8 > [] dev_queue_xmit+0x115/0x23c > [] packet_sendmsg_spkt+0x195/0x1d0 > [] sock_sendmsg+0xcf/0xf0 > [] sys_sendto+0xb6/0xf0 > [] sys_socketcall+0x11f/0x194 > [] syscall_call+0x7/0xb > irq event stamp: 8667 > hardirqs last enabled at (8666): [] _spin_unlock_irqrestore+0x3d/0x48 > hardirqs last disabled at (8667): [] common_interrupt+0x1b/0x2c > softirqs last enabled at (8632): [] __do_softirq+0x97/0xa8 > softirqs last disabled at (8660): [] dev_queue_xmit+0x3b/0x23c > > other info that might help us debug this: > 1 lock held by dhclient/1952: > #0: (&dev->_xmit_lock){-+..}, at: [] __qdisc_run+0x37/0x1a8 > > stack backtrace: > [] show_trace+0x16/0x1c > [] dump_stack+0x1a/0x20 > [] print_usage_bug+0x1d7/0x1e4 > [] mark_lock+0x432/0x548 > [] __lock_acquire+0x53e/0xc68 > [] lock_acquire+0x57/0x74 > [] _spin_lock+0x1a/0x28 > [] ei_interrupt+0x39/0x32c > [] handle_IRQ_event+0x24/0x58 > [] handle_level_irq+0x6c/0xd0 > [] do_IRQ+0x55/0xa8 > [] common_interrupt+0x25/0x2c > [] enable_irq+0x4b/0x9c > [] ei_start_xmit+0x10f/0x270 > [] dev_hard_start_xmit+0x1a9/0x1f8 > [] __qdisc_run+0xb6/0x1a8 > [] dev_queue_xmit+0x115/0x23c > [] packet_sendmsg_spkt+0x195/0x1d0 > [] sock_sendmsg+0xcf/0xf0 > [] sys_sendto+0xb6/0xf0 > [] sys_socketcall+0x11f/0x194 > [] syscall_call+0x7/0xb hm. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/broken-out/lockdep-annotate-8390c-disable_irq.patch didn't work. > kobject_add failed for vcs1 with -EEXIST, don't try to register things with the same name in the same directory. > [] show_trace+0x16/0x1c > [] dump_stack+0x1a/0x20 > [] kobject_add+0x114/0x1b4 > [] class_device_add+0xb3/0x484 > [] class_device_register+0x13/0x18 > [] class_device_create+0x8a/0xbc > [] vcs_make_devfs+0x26/0x54 > [] con_open+0x61/0x88 > [] tty_open+0x16f/0x348 > [] chrdev_open+0x63/0x168 > [] __dentry_open+0x8c/0x164 > [] nameidata_to_filp+0x30/0x3c > [] do_filp_open+0x3b/0x44 > [] do_sys_open+0x3b/0xc4 > [] sys_open+0x13/0x18 > [] syscall_call+0x7/0xb > kobject_add failed for vcsa1 with -EEXIST, don't try to register things with the same name in the same directory. We've seen this reported a couple of times before. It could be a race in the tty layer where a newly-added vc has the same index as a going-away one which still has its sysfs file. Or it could be something else :( Once someone comes up with a way to reproduce it, we'll fix it though.