* next-20081103: error: asm/ftrace.h: No such file or directory
2008-11-03 7:32 linux-next: Tree for November 3 Stephen Rothwell
@ 2008-11-03 13:58 ` Alexey Dobriyan
2008-11-03 14:04 ` Ingo Molnar
2008-11-03 14:28 ` next-20081103: arch/arm/kernel/elf.c:30: error: 'e_flags' undeclared Alexey Dobriyan
` (5 subsequent siblings)
6 siblings, 1 reply; 18+ messages in thread
From: Alexey Dobriyan @ 2008-11-03 13:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, mingo, srostedt
Alpha is busted:
CC init/main.o
In file included from include/linux/interrupt.h:12,
from include/linux/rtc.h:102,
from include/linux/efi.h:19,
from init/main.c:45:
include/linux/hardirq.h:8:24: error: asm/ftrace.h: No such file or directory
^ permalink raw reply [flat|nested] 18+ messages in thread* next-20081103: arch/arm/kernel/elf.c:30: error: 'e_flags' undeclared
2008-11-03 7:32 linux-next: Tree for November 3 Stephen Rothwell
2008-11-03 13:58 ` next-20081103: error: asm/ftrace.h: No such file or directory Alexey Dobriyan
@ 2008-11-03 14:28 ` Alexey Dobriyan
2008-11-03 15:08 ` Mikael Pettersson
2008-11-03 14:54 ` next-20081103: voyager Alexey Dobriyan
` (4 subsequent siblings)
6 siblings, 1 reply; 18+ messages in thread
From: Alexey Dobriyan @ 2008-11-03 14:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, rmk+kernel
s/e_flags/eflags/ but I'm not sure.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: next-20081103: arch/arm/kernel/elf.c:30: error: 'e_flags' undeclared
2008-11-03 14:28 ` next-20081103: arch/arm/kernel/elf.c:30: error: 'e_flags' undeclared Alexey Dobriyan
@ 2008-11-03 15:08 ` Mikael Pettersson
2008-11-03 15:31 ` Russell King
0 siblings, 1 reply; 18+ messages in thread
From: Mikael Pettersson @ 2008-11-03 15:08 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Stephen Rothwell, linux-next, linux-kernel, rmk+kernel
Alexey Dobriyan writes:
> s/e_flags/eflags/ but I'm not sure.
Correct. I sent the fixup patch below to rmk and the linux arm mailing
list yesterday, but I guess it hasn't found it's way to linux-next yet:
--- linux-2.6.28-rc2/arch/arm/kernel/elf.c.~1~ 2008-11-02 16:24:46.000000000 +0100
+++ linux-2.6.28-rc2/arch/arm/kernel/elf.c 2008-11-02 16:25:49.000000000 +0100
@@ -27,7 +27,7 @@ int elf_check_arch(const struct elf32_hd
if ((eflags & EF_ARM_APCS_26) && !(elf_hwcap & HWCAP_26BIT))
return 0;
- flt_fmt = e_flags & (EF_ARM_VFP_FLOAT | EF_ARM_SOFT_FLOAT);
+ flt_fmt = eflags & (EF_ARM_VFP_FLOAT | EF_ARM_SOFT_FLOAT);
/* VFP requires the supporting code */
if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP))
^ permalink raw reply [flat|nested] 18+ messages in thread
* next-20081103: voyager
2008-11-03 7:32 linux-next: Tree for November 3 Stephen Rothwell
2008-11-03 13:58 ` next-20081103: error: asm/ftrace.h: No such file or directory Alexey Dobriyan
2008-11-03 14:28 ` next-20081103: arch/arm/kernel/elf.c:30: error: 'e_flags' undeclared Alexey Dobriyan
@ 2008-11-03 14:54 ` Alexey Dobriyan
2008-11-03 15:08 ` Ingo Molnar
2008-11-03 15:50 ` next-20081103: oxu210hp-hcd.c:3849: error: implicit declaration of function 'set_irq_type' Alexey Dobriyan
` (3 subsequent siblings)
6 siblings, 1 reply; 18+ messages in thread
From: Alexey Dobriyan @ 2008-11-03 14:54 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, James.Bottomley, mingo
On i386-voyager:
CC arch/x86/mach-voyager/setup.o
arch/x86/mach-voyager/setup.c: In function 'intr_init_hook':
arch/x86/mach-voyager/setup.c:30: error: implicit declaration of function 'smp_intr_init'
arch/x86/mach-voyager/setup.c: In function 'machine_specific_memory_setup':
arch/x86/mach-voyager/setup.c:65: warning: unused variable 'new_nr'
make[2]: *** [arch/x86/mach-voyager/setup.o] Error 1
CC arch/x86/mach-voyager/voyager_smp.o
arch/x86/mach-voyager/voyager_smp.c:67: error: conflicting types for 'phys_cpu_present_map'
arch/x86/include/asm/mpspec.h:143: error: previous declaration of 'phys_cpu_present_map' was here
arch/x86/mach-voyager/voyager_smp.c: In function 'start_secondary':
arch/x86/mach-voyager/voyager_smp.c:452: error: implicit declaration of function 'notify_cpu_starting'
arch/x86/mach-voyager/voyager_smp.c: In function 'smp_call_function_interrupt':
arch/x86/mach-voyager/voyager_smp.c:965: error: implicit declaration of function 'generic_smp_call_function_interrupt'
arch/x86/mach-voyager/voyager_smp.c: In function 'smp_call_function_single_interrupt':
arch/x86/mach-voyager/voyager_smp.c:973: error: implicit declaration of function 'generic_smp_call_function_single_interrupt'
^ permalink raw reply [flat|nested] 18+ messages in thread* next-20081103: oxu210hp-hcd.c:3849: error: implicit declaration of function 'set_irq_type'
2008-11-03 7:32 linux-next: Tree for November 3 Stephen Rothwell
` (2 preceding siblings ...)
2008-11-03 14:54 ` next-20081103: voyager Alexey Dobriyan
@ 2008-11-03 15:50 ` Alexey Dobriyan
[not found] ` <20081103155047.GA14489-2ev+ksY9ol182hYKe6nXyg@public.gmane.org>
[not found] ` <20081103112018.5823291b.randy.dunlap@oracle.com>
` (2 subsequent siblings)
6 siblings, 1 reply; 18+ messages in thread
From: Alexey Dobriyan @ 2008-11-03 15:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, linux-usb, giometti, gregkh
On sparc:
drivers/usb/host/oxu210hp-hcd.c:3849: error: implicit declaration of function 'set_irq_type'
and including linux/irq.h doesn't cut it CONFIG_GENERIC_HARDIRQS aren't set.
^ permalink raw reply [flat|nested] 18+ messages in thread[parent not found: <20081103112018.5823291b.randy.dunlap@oracle.com>]
* Re: linux-next: Tree for November 3 (kvm)(resend/lost)
[not found] ` <20081103112018.5823291b.randy.dunlap@oracle.com>
@ 2008-11-04 9:23 ` Avi Kivity
0 siblings, 0 replies; 18+ messages in thread
From: Avi Kivity @ 2008-11-04 9:23 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML
Randy Dunlap wrote:
> On Mon, 3 Nov 2008 18:32:14 +1100 Stephen Rothwell wrote:
>
>
> When CONFIG_PCI=n, kvm build on i386 gets:
>
> arch/x86/kvm/../../../virt/kvm/kvm_main.c: In function 'kvm_free_assigned_device':
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:155: error: implicit declaration of function 'pci_reset_function'
> make[2]: *** [arch/x86/kvm/../../../virt/kvm/kvm_main.o] Error 1
>
I'll add a depends on PCI. Thanks.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 18+ messages in thread
* next-20081103 - possible circular locking dependency detected while bring up eth1
2008-11-03 7:32 linux-next: Tree for November 3 Stephen Rothwell
` (4 preceding siblings ...)
[not found] ` <20081103112018.5823291b.randy.dunlap@oracle.com>
@ 2008-11-05 7:13 ` Kamalesh Babulal
2008-11-05 7:48 ` Peter Zijlstra
2008-11-06 10:18 ` linux-next: Tree for November 3 Nico -telmich- Schottelius
6 siblings, 1 reply; 18+ messages in thread
From: Kamalesh Babulal @ 2008-11-05 7:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, netdev, mel, peterz
While booting with the next-20081103 kernel on x86 box, circular locking
dependency is detected.
Bringing up interface eth1: [ 31.988230]
[ 31.988234] =======================================================
[ 31.989072] [ INFO: possible circular locking dependency detected ]
[ 31.989072] 2.6.28-rc3-next-20081103-autotest #1
[ 31.989072] -------------------------------------------------------
[ 31.989072] events/3/18 is trying to acquire lock:
[ 32.074777] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 31.989072] (rtnl_mutex){--..}, at: [<c05e8ef5>] rtnl_lock+0xf/0x11
[ 31.989072]
[ 31.989072] but task is already holding lock:
[ 31.989072] ((linkwatch_work).work){--..}, at: [<c04367bf>] run_workqueue+0x80/0x189
[ 31.989072]
[ 31.989072] which lock already depends on the new lock.
[ 31.989072]
[ 31.989072]
[ 31.989072] the existing dependency chain (in reverse order) is:
[ 31.989072]
[ 31.989072] -> #4 ((linkwatch_work).work){--..}:
[ 31.989072] [<c0445edb>] validate_chain+0x86e/0xb35
[ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
[ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
[ 31.989072] [<c04367f8>] run_workqueue+0xb9/0x189
[ 31.989072] [<c04371f3>] worker_thread+0xb4/0xbf
[ 31.989072] [<c04396a6>] kthread+0x3b/0x61
[ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
[ 31.989072] [<ffffffff>] 0xffffffff
[ 31.989072]
[ 31.989072] -> #3 (events){--..}:
[ 31.989072] [<c0445edb>] validate_chain+0x86e/0xb35
[ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
[ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
[ 31.989072] [<c0436e21>] flush_work+0x45/0xb6
[ 31.989072] [<c043729a>] schedule_on_each_cpu+0x9c/0xca
[ 31.989072] [<c0466c97>] lru_add_drain_all+0xd/0xf
[ 31.989072] [<c046f1b6>] __mlock_vma_pages_range+0x96/0x1e5
[ 31.989072] [<c046f43a>] mlock_fixup+0x135/0x199
[ 31.989072] [<c046f50b>] do_mlockall+0x6d/0x82
[ 31.989072] [<c046f839>] sys_mlockall+0x7b/0x9e
[ 31.989072] [<c040398d>] sysenter_do_call+0x12/0x31
[ 31.989072] [<ffffffff>] 0xffffffff
[ 31.989072]
[ 31.989072] -> #2 (&mm->mmap_sem){----}:
[ 31.989072] [<c0445edb>] validate_chain+0x86e/0xb35
[ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
[ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
[ 31.989072] [<c046e570>] might_fault+0x53/0x73
[ 31.989072] [<c0508bf5>] copy_to_user+0x28/0x3f
[ 31.989072] [<c048cd11>] filldir+0x88/0xc8
[ 31.989072] [<c04bee82>] sysfs_readdir+0x11d/0x156
[ 31.989072] [<c048cdb9>] vfs_readdir+0x68/0x94
[ 31.989072] [<c048d00b>] sys_getdents+0x5f/0xa0
[ 31.989072] [<c0403a66>] syscall_call+0x7/0xb
[ 31.989072] [<ffffffff>] 0xffffffff
[ 31.989072]
[ 31.989072] -> #1 (sysfs_mutex){--..}:
[ 31.989072] [<c0445edb>] validate_chain+0x86e/0xb35
[ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
[ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
[ 31.989072] [<c0651c04>] mutex_lock_nested+0xdf/0x251
[ 31.989072] [<c04bf039>] sysfs_addrm_start+0x23/0x90
[ 31.989072] [<c04bf4af>] create_dir+0x3a/0x72
[ 31.989072] [<c04bf514>] sysfs_create_dir+0x2d/0x41
[ 31.989072] [<c0503e05>] kobject_add_internal+0xe5/0x189
[ 31.989072] [<c0503f54>] kobject_add_varg+0x35/0x41
[ 31.989072] [<c05042f7>] kobject_add+0x49/0x4f
[ 31.989072] [<c05777e1>] device_add+0x76/0x4c8
[ 31.989072] [<c05eb70e>] netdev_register_kobject+0x64/0x69
[ 31.989072] [<c05e1581>] register_netdevice+0x1fe/0x274
[ 31.989072] [<c05e1629>] register_netdev+0x32/0x3f
[ 31.989072] [<c07fa965>] loopback_net_init+0x2e/0x5d
[ 31.989072] [<c05de93b>] register_pernet_operations+0x13/0x15
[ 31.989072] [<c05de9a4>] register_pernet_device+0x1f/0x4c
[ 31.989072] [<c07fa935>] loopback_init+0xd/0xf
[ 31.989072] [<c0401130>] _stext+0x48/0x10d
[ 31.989072] [<c07db530>] kernel_init+0xf1/0x142
[ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
[ 31.989072] [<ffffffff>] 0xffffffff
[ 31.989072]
[ 31.989072] -> #0 (rtnl_mutex){--..}:
[ 31.989072] [<c0445c10>] validate_chain+0x5a3/0xb35
[ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
[ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
[ 31.989072] [<c0651c04>] mutex_lock_nested+0xdf/0x251
[ 31.989072] [<c05e8ef5>] rtnl_lock+0xf/0x11
[ 31.989072] [<c05ea07a>] linkwatch_event+0x8/0x27
[ 31.989072] [<c04367fd>] run_workqueue+0xbe/0x189
[ 31.989072] [<c04371f3>] worker_thread+0xb4/0xbf
[ 31.989072] [<c04396a6>] kthread+0x3b/0x61
[ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
[ 31.989072] [<ffffffff>] 0xffffffff
[ 31.989072]
[ 31.989072] other info that might help us debug this:
[ 31.989072]
[ 31.989072] 2 locks held by events/3/18:
[ 31.989072] #0: (events){--..}, at: [<c04367bf>] run_workqueue+0x80/0x189
[ 31.989072] #1: ((linkwatch_work).work){--..}, at: [<c04367bf>] run_workqueue+0x80/0x189
[ 31.989072]
[ 31.989072] stack backtrace:
[ 31.989072] Pid: 18, comm: events/3 Not tainted 2.6.28-rc3-next-20081103-autotest #1
[ 31.989072] Call Trace:
[ 31.989072] [<c0445662>] print_circular_bug_tail+0xa4/0xaf
[ 31.989072] [<c0445c10>] validate_chain+0x5a3/0xb35
[ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
[ 31.989072] [<c04367bf>] ? run_workqueue+0x80/0x189
[ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
[ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
[ 31.989072] [<c0651c04>] mutex_lock_nested+0xdf/0x251
[ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
[ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
[ 31.989072] [<c05e8ef5>] rtnl_lock+0xf/0x11
[ 31.989072] [<c05ea07a>] linkwatch_event+0x8/0x27
[ 31.989072] [<c04367fd>] run_workqueue+0xbe/0x189
[ 31.989072] [<c04367bf>] ? run_workqueue+0x80/0x189
[ 31.989072] [<c05ea072>] ? linkwatch_event+0x0/0x27
[ 31.989072] [<c043713f>] ? worker_thread+0x0/0xbf
[ 31.989072] [<c04371f3>] worker_thread+0xb4/0xbf
[ 31.989072] [<c0439765>] ? autoremove_wake_function+0x0/0x33
[ 31.989072] [<c04396a6>] kthread+0x3b/0x61
[ 33.690691] tg3: eth1: Link is up at 100 Mbps, full duplex.
[ 33.690696] tg3: eth1: Flow control is off for TX and off for RX.
[ 31.989072] [<c043966b>] ? kthread+0x0/0x61
[ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
[ 33.762336] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ OK ]
0xc05e8ef5 is in rtnl_lock (net/core/rtnetlink.c:67).
62 static DEFINE_MUTEX(rtnl_mutex);
63
64 void rtnl_lock(void)
65 {
66 mutex_lock(&rtnl_mutex);
67 }
68
69 void __rtnl_unlock(void)
70 {
71 mutex_unlock(&rtnl_mutex);
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: next-20081103 - possible circular locking dependency detected while bring up eth1
2008-11-05 7:13 ` next-20081103 - possible circular locking dependency detected while bring up eth1 Kamalesh Babulal
@ 2008-11-05 7:48 ` Peter Zijlstra
2008-11-05 9:14 ` KOSAKI Motohiro
0 siblings, 1 reply; 18+ messages in thread
From: Peter Zijlstra @ 2008-11-05 7:48 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Stephen Rothwell, linux-next, LKML, netdev, mel, KOSAKI Motohiro
On Wed, 2008-11-05 at 12:43 +0530, Kamalesh Babulal wrote:
> While booting with the next-20081103 kernel on x86 box, circular locking
> dependency is detected.
>
> Bringing up interface eth1: [ 31.988230]
> [ 31.988234] =======================================================
> [ 31.989072] [ INFO: possible circular locking dependency detected ]
> [ 31.989072] 2.6.28-rc3-next-20081103-autotest #1
> [ 31.989072] -------------------------------------------------------
> [ 31.989072] events/3/18 is trying to acquire lock:
> [ 32.074777] ADDRCONF(NETDEV_UP): eth1: link is not ready
> [ 31.989072] (rtnl_mutex){--..}, at: [<c05e8ef5>] rtnl_lock+0xf/0x11
> [ 31.989072]
> [ 31.989072] but task is already holding lock:
> [ 31.989072] ((linkwatch_work).work){--..}, at: [<c04367bf>] run_workqueue+0x80/0x189
> [ 31.989072]
> [ 31.989072] which lock already depends on the new lock.
> [ 31.989072]
> [ 31.989072]
> [ 31.989072] the existing dependency chain (in reverse order) is:
> [ 31.989072]
> [ 31.989072] -> #4 ((linkwatch_work).work){--..}:
> [ 31.989072] [<c0445edb>] validate_chain+0x86e/0xb35
> [ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
> [ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
> [ 31.989072] [<c04367f8>] run_workqueue+0xb9/0x189
> [ 31.989072] [<c04371f3>] worker_thread+0xb4/0xbf
> [ 31.989072] [<c04396a6>] kthread+0x3b/0x61
> [ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
> [ 31.989072] [<ffffffff>] 0xffffffff
> [ 31.989072]
> [ 31.989072] -> #3 (events){--..}:
> [ 31.989072] [<c0445edb>] validate_chain+0x86e/0xb35
> [ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
> [ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
> [ 31.989072] [<c0436e21>] flush_work+0x45/0xb6
> [ 31.989072] [<c043729a>] schedule_on_each_cpu+0x9c/0xca
> [ 31.989072] [<c0466c97>] lru_add_drain_all+0xd/0xf
> [ 31.989072] [<c046f1b6>] __mlock_vma_pages_range+0x96/0x1e5
> [ 31.989072] [<c046f43a>] mlock_fixup+0x135/0x199
> [ 31.989072] [<c046f50b>] do_mlockall+0x6d/0x82
> [ 31.989072] [<c046f839>] sys_mlockall+0x7b/0x9e
> [ 31.989072] [<c040398d>] sysenter_do_call+0x12/0x31
> [ 31.989072] [<ffffffff>] 0xffffffff
> [ 31.989072]
> [ 31.989072] -> #2 (&mm->mmap_sem){----}:
> [ 31.989072] [<c0445edb>] validate_chain+0x86e/0xb35
> [ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
> [ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
> [ 31.989072] [<c046e570>] might_fault+0x53/0x73
> [ 31.989072] [<c0508bf5>] copy_to_user+0x28/0x3f
> [ 31.989072] [<c048cd11>] filldir+0x88/0xc8
> [ 31.989072] [<c04bee82>] sysfs_readdir+0x11d/0x156
> [ 31.989072] [<c048cdb9>] vfs_readdir+0x68/0x94
> [ 31.989072] [<c048d00b>] sys_getdents+0x5f/0xa0
> [ 31.989072] [<c0403a66>] syscall_call+0x7/0xb
> [ 31.989072] [<ffffffff>] 0xffffffff
> [ 31.989072]
> [ 31.989072] -> #1 (sysfs_mutex){--..}:
> [ 31.989072] [<c0445edb>] validate_chain+0x86e/0xb35
> [ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
> [ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
> [ 31.989072] [<c0651c04>] mutex_lock_nested+0xdf/0x251
> [ 31.989072] [<c04bf039>] sysfs_addrm_start+0x23/0x90
> [ 31.989072] [<c04bf4af>] create_dir+0x3a/0x72
> [ 31.989072] [<c04bf514>] sysfs_create_dir+0x2d/0x41
> [ 31.989072] [<c0503e05>] kobject_add_internal+0xe5/0x189
> [ 31.989072] [<c0503f54>] kobject_add_varg+0x35/0x41
> [ 31.989072] [<c05042f7>] kobject_add+0x49/0x4f
> [ 31.989072] [<c05777e1>] device_add+0x76/0x4c8
> [ 31.989072] [<c05eb70e>] netdev_register_kobject+0x64/0x69
> [ 31.989072] [<c05e1581>] register_netdevice+0x1fe/0x274
> [ 31.989072] [<c05e1629>] register_netdev+0x32/0x3f
> [ 31.989072] [<c07fa965>] loopback_net_init+0x2e/0x5d
> [ 31.989072] [<c05de93b>] register_pernet_operations+0x13/0x15
> [ 31.989072] [<c05de9a4>] register_pernet_device+0x1f/0x4c
> [ 31.989072] [<c07fa935>] loopback_init+0xd/0xf
> [ 31.989072] [<c0401130>] _stext+0x48/0x10d
> [ 31.989072] [<c07db530>] kernel_init+0xf1/0x142
> [ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
> [ 31.989072] [<ffffffff>] 0xffffffff
> [ 31.989072]
> [ 31.989072] -> #0 (rtnl_mutex){--..}:
> [ 31.989072] [<c0445c10>] validate_chain+0x5a3/0xb35
> [ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
> [ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
> [ 31.989072] [<c0651c04>] mutex_lock_nested+0xdf/0x251
> [ 31.989072] [<c05e8ef5>] rtnl_lock+0xf/0x11
> [ 31.989072] [<c05ea07a>] linkwatch_event+0x8/0x27
> [ 31.989072] [<c04367fd>] run_workqueue+0xbe/0x189
> [ 31.989072] [<c04371f3>] worker_thread+0xb4/0xbf
> [ 31.989072] [<c04396a6>] kthread+0x3b/0x61
> [ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
> [ 31.989072] [<ffffffff>] 0xffffffff
> [ 31.989072]
> [ 31.989072] other info that might help us debug this:
> [ 31.989072]
> [ 31.989072] 2 locks held by events/3/18:
> [ 31.989072] #0: (events){--..}, at: [<c04367bf>] run_workqueue+0x80/0x189
> [ 31.989072] #1: ((linkwatch_work).work){--..}, at: [<c04367bf>] run_workqueue+0x80/0x189
> [ 31.989072]
> [ 31.989072] stack backtrace:
> [ 31.989072] Pid: 18, comm: events/3 Not tainted 2.6.28-rc3-next-20081103-autotest #1
> [ 31.989072] Call Trace:
> [ 31.989072] [<c0445662>] print_circular_bug_tail+0xa4/0xaf
> [ 31.989072] [<c0445c10>] validate_chain+0x5a3/0xb35
> [ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
> [ 31.989072] [<c04367bf>] ? run_workqueue+0x80/0x189
> [ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
> [ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
> [ 31.989072] [<c0651c04>] mutex_lock_nested+0xdf/0x251
> [ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
> [ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
> [ 31.989072] [<c05e8ef5>] rtnl_lock+0xf/0x11
> [ 31.989072] [<c05ea07a>] linkwatch_event+0x8/0x27
> [ 31.989072] [<c04367fd>] run_workqueue+0xbe/0x189
> [ 31.989072] [<c04367bf>] ? run_workqueue+0x80/0x189
> [ 31.989072] [<c05ea072>] ? linkwatch_event+0x0/0x27
> [ 31.989072] [<c043713f>] ? worker_thread+0x0/0xbf
> [ 31.989072] [<c04371f3>] worker_thread+0xb4/0xbf
> [ 31.989072] [<c0439765>] ? autoremove_wake_function+0x0/0x33
> [ 31.989072] [<c04396a6>] kthread+0x3b/0x61
> [ 33.690691] tg3: eth1: Link is up at 100 Mbps, full duplex.
> [ 33.690696] tg3: eth1: Flow control is off for TX and off for RX.
> [ 31.989072] [<c043966b>] ? kthread+0x0/0x61
> [ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
> [ 33.762336] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> [ OK ]
I think we have to go with Kosaki-san's vm workqueue...
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: next-20081103 - possible circular locking dependency detected while bring up eth1
2008-11-05 7:48 ` Peter Zijlstra
@ 2008-11-05 9:14 ` KOSAKI Motohiro
0 siblings, 0 replies; 18+ messages in thread
From: KOSAKI Motohiro @ 2008-11-05 9:14 UTC (permalink / raw)
To: Peter Zijlstra
Cc: kosaki.motohiro, Kamalesh Babulal, Stephen Rothwell, linux-next,
LKML, netdev, mel
> > [ 31.989072] 2 locks held by events/3/18:
> > [ 31.989072] #0: (events){--..}, at: [<c04367bf>] run_workqueue+0x80/0x189
> > [ 31.989072] #1: ((linkwatch_work).work){--..}, at: [<c04367bf>] run_workqueue+0x80/0x189
> > [ 31.989072]
> > [ 31.989072] stack backtrace:
> > [ 31.989072] Pid: 18, comm: events/3 Not tainted 2.6.28-rc3-next-20081103-autotest #1
> > [ 31.989072] Call Trace:
> > [ 31.989072] [<c0445662>] print_circular_bug_tail+0xa4/0xaf
> > [ 31.989072] [<c0445c10>] validate_chain+0x5a3/0xb35
> > [ 31.989072] [<c0446822>] __lock_acquire+0x680/0x70e
> > [ 31.989072] [<c04367bf>] ? run_workqueue+0x80/0x189
> > [ 31.989072] [<c044690d>] lock_acquire+0x5d/0x7a
> > [ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
> > [ 31.989072] [<c0651c04>] mutex_lock_nested+0xdf/0x251
> > [ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
> > [ 31.989072] [<c05e8ef5>] ? rtnl_lock+0xf/0x11
> > [ 31.989072] [<c05e8ef5>] rtnl_lock+0xf/0x11
> > [ 31.989072] [<c05ea07a>] linkwatch_event+0x8/0x27
> > [ 31.989072] [<c04367fd>] run_workqueue+0xbe/0x189
> > [ 31.989072] [<c04367bf>] ? run_workqueue+0x80/0x189
> > [ 31.989072] [<c05ea072>] ? linkwatch_event+0x0/0x27
> > [ 31.989072] [<c043713f>] ? worker_thread+0x0/0xbf
> > [ 31.989072] [<c04371f3>] worker_thread+0xb4/0xbf
> > [ 31.989072] [<c0439765>] ? autoremove_wake_function+0x0/0x33
> > [ 31.989072] [<c04396a6>] kthread+0x3b/0x61
> > [ 33.690691] tg3: eth1: Link is up at 100 Mbps, full duplex.
> > [ 33.690696] tg3: eth1: Flow control is off for TX and off for RX.
> > [ 31.989072] [<c043966b>] ? kthread+0x0/0x61
> > [ 31.989072] [<c040481b>] kernel_thread_helper+0x7/0x10
> > [ 33.762336] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> > [ OK ]
>
> I think we have to go with Kosaki-san's vm workqueue...
Very sorry for my lazyness.
akpm did nak vm workqueue patch.
So I prepare new patch now. (it is under testing now)
I expect I can post it tommorow.
Thanks.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: linux-next: Tree for November 3
2008-11-03 7:32 linux-next: Tree for November 3 Stephen Rothwell
` (5 preceding siblings ...)
2008-11-05 7:13 ` next-20081103 - possible circular locking dependency detected while bring up eth1 Kamalesh Babulal
@ 2008-11-06 10:18 ` Nico -telmich- Schottelius
6 siblings, 0 replies; 18+ messages in thread
From: Nico -telmich- Schottelius @ 2008-11-06 10:18 UTC (permalink / raw)
To: linux-next, LKML, trivial
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
Stephen Rothwell [Mon, Nov 03, 2008 at 06:32:14PM +1100]:
> Changes since 20081031:
> [...]
> Removed tree:
> trivial (Jesper no longer has the time to maintain it)
> [...]
Jesper, don't you maintain the linux-next branch anymore
or did you stop accepting trivial patches at all?
In both cases: Is there somebody who continues your work?
Sincerly,
Nico
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread