linux-next: Tree for November 3 - Kernel

This is a discussion on linux-next: Tree for November 3 - Kernel ; Hi all, Changes since 20081031: Dropped trees (temporarily): v4l-dvb (due to an unfixed build failure) semaphore-removal (due to unfixed conflicts against Linus' tree) Removed tree: trivial (Jesper no longer has the time to maintain it) The USB tree had three ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: linux-next: Tree for November 3

  1. linux-next: Tree for November 3

    Hi all,

    Changes since 20081031:

    Dropped trees (temporarily):
    v4l-dvb (due to an unfixed build failure)
    semaphore-removal (due to unfixed conflicts against Linus' tree)

    Removed tree:
    trivial (Jesper no longer has the time to maintain it)

    The USB tree had three commits excluded (2 cause a build failure and the
    other is not intended for mainline).

    The net tree lost its conflict.

    The sound tree lost its conflict.

    The slab tree gained 3 conflicts against Linus' tree and the merge needed
    fixing.

    The creds tree lost 2 conflicts.

    I have also applied the following patches for known problems:

    sparc: qlogicpti fallout from sbus removal
    nfsctl: credentials error
    coda: credentials error
    cpu_alloc: per_cpu_offset is already defined for !CONFIG_SMP
    ia64: Fix gru compiler warning
    ps3: ps3-lpm.c compile fix
    cell: fix ras.c compilation

    ----------------------------------------------------------------------------

    I have created today's linux-next tree at
    git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
    (patches at
    http://www.kernel.org/pub/linux/kern...fr/linux-next/). If you
    are tracking the linux-next tree using git, you should not use "git pull"
    to do so as that will try to merge the new linux-next release with the
    old one. You should use "git fetch" as mentioned in the FAQ on the wiki
    (see below).

    You can see which trees have been included by looking in the Next/Trees
    file in the source. There are also quilt-import.log and merge.log files
    in the Next directory. Between each merge, the tree was built with
    a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
    final fixups, it is also built with powerpc allnoconfig,
    44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.

    Below is a summary of the state of the merge.

    We are up to 122 trees (counting Linus' and 14 trees of patches pending for
    Linus' tree), more are welcome (even if they are currently empty).
    Thanks to those who have contributed, and to those who haven't, please do.

    Status of my local build tests will be at
    http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
    advice about cross compilers/configs that work, we are always open to add
    more builds.

    Thanks to Jan Dittmer for adding the linux-next tree to his build tests
    at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
    Dunlap for doing many randconfig builds.

    There is a wiki covering stuff to do with linux-next at
    http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.

    --
    Cheers,
    Stephen Rothwell sfr@canb.auug.org.au

    $ git checkout master
    $ git reset --hard stable
    Merging origin/master
    Merging powerpc-merge/merge
    Merging scsi-rc-fixes/master
    Merging net-current/master
    Merging sparc-current/master
    Merging sound-current/for-linus
    Merging arm-current/master
    Merging pci-current/for-linus
    Merging wireless-current/master
    Merging kbuild-current/master
    Merging quilt/driver-core.current
    Merging quilt/usb.current
    Merging cpufreq-current/fixes
    Merging input-current/for-linus
    Merging md-current/for-2.6.26
    Merging dwmw2/master
    Merging arm/devel
    Merging avr32/avr32-arch
    Merging blackfin/for-linus
    Merging cris/for-next
    Merging ia64/test
    Merging quilt/m68k
    Merging m68knommu/for-next
    Merging mips/mips-for-linux-next
    Merging parisc/master
    Merging powerpc/powerpc-next
    Merging 4xx/next
    Merging galak/next
    Merging pxa/for-next
    Merging s390/features
    CONFLICT (content): Merge conflict in drivers/s390/net/qeth_l2_main.c
    CONFLICT (content): Merge conflict in drivers/s390/net/qeth_l3_main.c
    Merging sh/master
    Merging sparc/master
    Merging x86/auto-x86-next
    Merging xtensa/master
    Merging quilt/driver-core
    Merging quilt/usb
    $ git reset --hard HEAD^
    Merging tip-core/auto-core-next
    Merging cpus4096/auto-cpus4096-next
    Merging ftrace/auto-ftrace-next
    Merging genirq/auto-genirq-next
    Merging safe-poison-pointers/auto-safe-poison-pointers-next
    Merging sched/auto-sched-next
    Merging stackprotector/auto-stackprotector-next
    Merging timers/auto-timers-next
    Merging pci/linux-next
    Merging quilt/device-mapper
    Merging hid/mm
    Merging quilt/i2c
    Merging quilt/jdelvare-hwmon
    Merging quilt/kernel-doc
    Merging v4l-dvb/master
    $ git reset --hard HEAD^
    Merging jfs/next
    Merging kbuild/master
    Merging quilt/ide
    Merging libata/NEXT
    Merging nfs/linux-next
    Merging xfs/master
    Applying fs: xfs needs inode_wait to be exported
    Merging infiniband/for-next
    Merging acpi/test
    Merging nfsd/nfsd-next
    Merging ieee1394/for-next
    Merging ubi/linux-next
    Merging kvm/master
    Merging dlm/next
    Merging scsi/master
    Merging tests/master
    CONFLICT (content): Merge conflict in lib/Kconfig.debug
    Merging ocfs2/linux-next
    Merging ext4/next
    Merging async_tx/next
    Merging udf/for_next
    Merging net/master
    Merging mtd/master
    Merging wireless/master
    Merging crypto/master
    Merging vfs/for-next
    Merging sound/for-next
    Merging cpufreq/next
    Merging v9fs/for-next
    Merging quilt/rr
    Merging cifs/master
    Merging mmc/next
    Merging gfs2/master
    Merging input/next
    Merging semaphore/semaphore
    Merging semaphore-removal/semaphore-removal
    CONFLICT (content): Merge conflict in net/9p/trans_virtio.c
    $ git reset --hard
    Merging bkl-removal/bkl-removal
    Merging ubifs/linux-next
    Merging lsm/for-next
    Merging block/for-next
    Merging embedded/master
    Merging firmware/master
    CONFLICT (content): Merge conflict in drivers/scsi/qlogicpti.c
    CONFLICT (content): Merge conflict in firmware/WHENCE
    Merging pcmcia/master
    Merging battery/master
    Merging leds/for-mm
    Merging backlight/for-mm
    Merging kgdb/kgdb-next
    Merging slab/for-next
    CONFLICT (content): Merge conflict in fs/proc/inode.c
    CONFLICT (content): Merge conflict in mm/Makefile
    CONFLICT (content): Merge conflict in mm/vmscan.c
    CONFLICT (content): Merge conflict in mm/vmstat.c
    Applying slab: xfs mismerge fix
    Merging uclinux/for-next
    Merging md/for-next
    Merging kmemcheck/auto-kmemcheck-next
    CONFLICT (content): Merge conflict in MAINTAINERS
    CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
    CONFLICT (content): Merge conflict in mm/slab.c
    CONFLICT (content): Merge conflict in mm/slub.c
    Merging generic-ipi/auto-generic-ipi-next
    Merging mfd/for-next
    Merging hdlc/hdlc-next
    CONFLICT (delete/modify): Documentation/DocBook/wanbook.tmpl deleted in hdlc/hdlc-next and modified in HEAD. Version HEAD of Documentation/DocBook/wanbook.tmpl left in tree.
    CONFLICT (delete/modify): drivers/net/wan/syncppp.c deleted in hdlc/hdlc-next and modified in HEAD. Version HEAD of drivers/net/wan/syncppp.c left in tree.
    $ git rm -f drivers/net/wan/syncppp.c Documentation/DocBook/wanbook.tmpl
    Merging drm/drm-next
    Merging voltage/for-linus
    Merging security-testing/next
    Merging lblnet/master
    Merging quilt/ttydev
    Merging agp/agp-next
    Merging creds/creds-v4
    CONFLICT (content): Merge conflict in fs/ext4/balloc.c
    CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_cred.h
    CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_globals.h
    CONFLICT (content): Merge conflict in fs/xfs/xfs_vnodeops.h
    CONFLICT (content): Merge conflict in security/selinux/hooks.c
    Merging oprofile/auto-oprofile-next
    Merging fastboot/auto-fastboot-next
    Merging sparseirq/auto-sparseirq-next
    Merging iommu/auto-iommu-next
    Merging uwb/for-upstream
    Merging watchdog/master
    Merging proc/proc
    Merging bdev/master
    Merging dwmw2-iommu/master
    Merging cpu_alloc/cpu_alloc
    CONFLICT (content): Merge conflict in kernel/lockdep.c
    CONFLICT (content): Merge conflict in kernel/module.c
    Merging userns/next
    Merging scsi-post-merge/master
    Applying sparc: qlogicpti fallout from sbus removal
    Applying nfsctl: credentials error
    Applying coda: credentials error
    Applying cpu_alloc: per_cpu_offset is already defined for !CONFIG_SMP
    Applying ia64: Fix gru compiler warning
    Applying ps3: ps3-lpm.c compile fix
    Applying cell: fix ras.c compilation

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkkOqP4ACgkQjjKRsyhoI8xDYgCeINF4zBx9aa UMbKu9VIrnJoPM
    +SYAnjmDaQUg+Jvp9TsNWKDhyC8yUBUO
    =fIA8
    -----END PGP SIGNATURE-----


  2. next-20081103: error: asm/ftrace.h: No such file or directory

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: next-20081103: error: asm/ftrace.h: No such file or directory


    * Alexey Dobriyan wrote:

    > 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


    should be solved in the latest ftrace tree.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. next-20081103: arch/arm/kernel/elf.c:30: error: 'e_flags' undeclared

    s/e_flags/eflags/ but I'm not sure.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. next-20081103: voyager

    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'
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: next-20081103: voyager


    * Alexey Dobriyan wrote:

    > On i386-voyager:


    being worked on.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: next-20081103: arch/arm/kernel/elf.c:30: error: 'e_flags' undeclared

    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))

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: next-20081103: arch/arm/kernel/elf.c:30: error: 'e_flags' undeclared

    On Mon, Nov 03, 2008 at 04:08:10PM +0100, Mikael Pettersson wrote:
    > 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:


    I committed the fix yesterday, but I haven't pushed my tree out yet.

    --
    Russell King
    Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
    maintainer of:
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. next-20081103: oxu210hp-hcd.c:3849: error: implicit declaration of function 'set_irq_type'

    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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: linux-next: Tree for November 3 (kvm)(resend/lost)

    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

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: next-20081103: oxu210hp-hcd.c:3849: error: implicit declaration of function 'set_irq_type'

    On Mon, Nov 03, 2008 at 06:50:47PM +0300, Alexey Dobriyan wrote:
    > 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.


    Should I force CONFIG_GENERIC_HARDIRQS selection?

    Ciao,

    Rodolfo

    --

    GNU/Linux Solutions e-mail: giometti@enneenne.com
    Linux Device Driver giometti@linux.it
    Embedded Systems phone: +39 349 2432127
    UNIX programming skype: rodolfo.giometti
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: next-20081103: oxu210hp-hcd.c:3849: error: implicit declaration of function 'set_irq_type'

    On Tue, Nov 04, 2008 at 05:30:38PM +0100, Rodolfo Giometti wrote:
    > On Mon, Nov 03, 2008 at 06:50:47PM +0300, Alexey Dobriyan wrote:
    > > 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.

    >
    > Should I force CONFIG_GENERIC_HARDIRQS selection?


    Can this hardware work on SPARC?

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: next-20081103: oxu210hp-hcd.c:3849: error: implicit declaration of function 'set_irq_type'

    On Tue, Nov 04, 2008 at 10:43:34AM -0800, Greg KH wrote:
    > On Tue, Nov 04, 2008 at 05:30:38PM +0100, Rodolfo Giometti wrote:
    > > On Mon, Nov 03, 2008 at 06:50:47PM +0300, Alexey Dobriyan wrote:
    > > > 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.

    > >
    > > Should I force CONFIG_GENERIC_HARDIRQS selection?

    >
    > Can this hardware work on SPARC?


    I think so even if on the data sheet is not specified...

    Ciao,

    Rodolfo

    --

    GNU/Linux Solutions e-mail: giometti@enneenne.com
    Linux Device Driver giometti@linux.it
    Embedded Systems phone: +39 349 2432127
    UNIX programming skype: rodolfo.giometti
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. next-20081103 - possible circular locking dependency detected while bring up eth1

    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: [] rtnl_lock+0xf/0x11
    [ 31.989072]
    [ 31.989072] but task is already holding lock:
    [ 31.989072] ((linkwatch_work).work){--..}, at: [] 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] [] validate_chain+0x86e/0xb35
    [ 31.989072] [] __lock_acquire+0x680/0x70e
    [ 31.989072] [] lock_acquire+0x5d/0x7a
    [ 31.989072] [] run_workqueue+0xb9/0x189
    [ 31.989072] [] worker_thread+0xb4/0xbf
    [ 31.989072] [] kthread+0x3b/0x61
    [ 31.989072] [] kernel_thread_helper+0x7/0x10
    [ 31.989072] [] 0xffffffff
    [ 31.989072]
    [ 31.989072] -> #3 (events){--..}:
    [ 31.989072] [] validate_chain+0x86e/0xb35
    [ 31.989072] [] __lock_acquire+0x680/0x70e
    [ 31.989072] [] lock_acquire+0x5d/0x7a
    [ 31.989072] [] flush_work+0x45/0xb6
    [ 31.989072] [] schedule_on_each_cpu+0x9c/0xca
    [ 31.989072] [] lru_add_drain_all+0xd/0xf
    [ 31.989072] [] __mlock_vma_pages_range+0x96/0x1e5
    [ 31.989072] [] mlock_fixup+0x135/0x199
    [ 31.989072] [] do_mlockall+0x6d/0x82
    [ 31.989072] [] sys_mlockall+0x7b/0x9e
    [ 31.989072] [] sysenter_do_call+0x12/0x31
    [ 31.989072] [] 0xffffffff
    [ 31.989072]
    [ 31.989072] -> #2 (&mm->mmap_sem){----}:
    [ 31.989072] [] validate_chain+0x86e/0xb35
    [ 31.989072] [] __lock_acquire+0x680/0x70e
    [ 31.989072] [] lock_acquire+0x5d/0x7a
    [ 31.989072] [] might_fault+0x53/0x73
    [ 31.989072] [] copy_to_user+0x28/0x3f
    [ 31.989072] [] filldir+0x88/0xc8
    [ 31.989072] [] sysfs_readdir+0x11d/0x156
    [ 31.989072] [] vfs_readdir+0x68/0x94
    [ 31.989072] [] sys_getdents+0x5f/0xa0
    [ 31.989072] [] syscall_call+0x7/0xb
    [ 31.989072] [] 0xffffffff
    [ 31.989072]
    [ 31.989072] -> #1 (sysfs_mutex){--..}:
    [ 31.989072] [] validate_chain+0x86e/0xb35
    [ 31.989072] [] __lock_acquire+0x680/0x70e
    [ 31.989072] [] lock_acquire+0x5d/0x7a
    [ 31.989072] [] mutex_lock_nested+0xdf/0x251
    [ 31.989072] [] sysfs_addrm_start+0x23/0x90
    [ 31.989072] [] create_dir+0x3a/0x72
    [ 31.989072] [] sysfs_create_dir+0x2d/0x41
    [ 31.989072] [] kobject_add_internal+0xe5/0x189
    [ 31.989072] [] kobject_add_varg+0x35/0x41
    [ 31.989072] [] kobject_add+0x49/0x4f
    [ 31.989072] [] device_add+0x76/0x4c8
    [ 31.989072] [] netdev_register_kobject+0x64/0x69
    [ 31.989072] [] register_netdevice+0x1fe/0x274
    [ 31.989072] [] register_netdev+0x32/0x3f
    [ 31.989072] [] loopback_net_init+0x2e/0x5d
    [ 31.989072] [] register_pernet_operations+0x13/0x15
    [ 31.989072] [] register_pernet_device+0x1f/0x4c
    [ 31.989072] [] loopback_init+0xd/0xf
    [ 31.989072] [] _stext+0x48/0x10d
    [ 31.989072] [] kernel_init+0xf1/0x142
    [ 31.989072] [] kernel_thread_helper+0x7/0x10
    [ 31.989072] [] 0xffffffff
    [ 31.989072]
    [ 31.989072] -> #0 (rtnl_mutex){--..}:
    [ 31.989072] [] validate_chain+0x5a3/0xb35
    [ 31.989072] [] __lock_acquire+0x680/0x70e
    [ 31.989072] [] lock_acquire+0x5d/0x7a
    [ 31.989072] [] mutex_lock_nested+0xdf/0x251
    [ 31.989072] [] rtnl_lock+0xf/0x11
    [ 31.989072] [] linkwatch_event+0x8/0x27
    [ 31.989072] [] run_workqueue+0xbe/0x189
    [ 31.989072] [] worker_thread+0xb4/0xbf
    [ 31.989072] [] kthread+0x3b/0x61
    [ 31.989072] [] kernel_thread_helper+0x7/0x10
    [ 31.989072] [] 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: [] run_workqueue+0x80/0x189
    [ 31.989072] #1: ((linkwatch_work).work){--..}, at: [] 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] [] print_circular_bug_tail+0xa4/0xaf
    [ 31.989072] [] validate_chain+0x5a3/0xb35
    [ 31.989072] [] __lock_acquire+0x680/0x70e
    [ 31.989072] [] ? run_workqueue+0x80/0x189
    [ 31.989072] [] lock_acquire+0x5d/0x7a
    [ 31.989072] [] ? rtnl_lock+0xf/0x11
    [ 31.989072] [] mutex_lock_nested+0xdf/0x251
    [ 31.989072] [] ? rtnl_lock+0xf/0x11
    [ 31.989072] [] ? rtnl_lock+0xf/0x11
    [ 31.989072] [] rtnl_lock+0xf/0x11
    [ 31.989072] [] linkwatch_event+0x8/0x27
    [ 31.989072] [] run_workqueue+0xbe/0x189
    [ 31.989072] [] ? run_workqueue+0x80/0x189
    [ 31.989072] [] ? linkwatch_event+0x0/0x27
    [ 31.989072] [] ? worker_thread+0x0/0xbf
    [ 31.989072] [] worker_thread+0xb4/0xbf
    [ 31.989072] [] ? autoremove_wake_function+0x0/0x33
    [ 31.989072] [] 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] [] ? kthread+0x0/0x61
    [ 31.989072] [] 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: next-20081103 - possible circular locking dependency detected while bring up eth1

    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: [] rtnl_lock+0xf/0x11
    > [ 31.989072]
    > [ 31.989072] but task is already holding lock:
    > [ 31.989072] ((linkwatch_work).work){--..}, at: [] 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] [] validate_chain+0x86e/0xb35
    > [ 31.989072] [] __lock_acquire+0x680/0x70e
    > [ 31.989072] [] lock_acquire+0x5d/0x7a
    > [ 31.989072] [] run_workqueue+0xb9/0x189
    > [ 31.989072] [] worker_thread+0xb4/0xbf
    > [ 31.989072] [] kthread+0x3b/0x61
    > [ 31.989072] [] kernel_thread_helper+0x7/0x10
    > [ 31.989072] [] 0xffffffff
    > [ 31.989072]
    > [ 31.989072] -> #3 (events){--..}:
    > [ 31.989072] [] validate_chain+0x86e/0xb35
    > [ 31.989072] [] __lock_acquire+0x680/0x70e
    > [ 31.989072] [] lock_acquire+0x5d/0x7a
    > [ 31.989072] [] flush_work+0x45/0xb6
    > [ 31.989072] [] schedule_on_each_cpu+0x9c/0xca
    > [ 31.989072] [] lru_add_drain_all+0xd/0xf
    > [ 31.989072] [] __mlock_vma_pages_range+0x96/0x1e5
    > [ 31.989072] [] mlock_fixup+0x135/0x199
    > [ 31.989072] [] do_mlockall+0x6d/0x82
    > [ 31.989072] [] sys_mlockall+0x7b/0x9e
    > [ 31.989072] [] sysenter_do_call+0x12/0x31
    > [ 31.989072] [] 0xffffffff
    > [ 31.989072]
    > [ 31.989072] -> #2 (&mm->mmap_sem){----}:
    > [ 31.989072] [] validate_chain+0x86e/0xb35
    > [ 31.989072] [] __lock_acquire+0x680/0x70e
    > [ 31.989072] [] lock_acquire+0x5d/0x7a
    > [ 31.989072] [] might_fault+0x53/0x73
    > [ 31.989072] [] copy_to_user+0x28/0x3f
    > [ 31.989072] [] filldir+0x88/0xc8
    > [ 31.989072] [] sysfs_readdir+0x11d/0x156
    > [ 31.989072] [] vfs_readdir+0x68/0x94
    > [ 31.989072] [] sys_getdents+0x5f/0xa0
    > [ 31.989072] [] syscall_call+0x7/0xb
    > [ 31.989072] [] 0xffffffff
    > [ 31.989072]
    > [ 31.989072] -> #1 (sysfs_mutex){--..}:
    > [ 31.989072] [] validate_chain+0x86e/0xb35
    > [ 31.989072] [] __lock_acquire+0x680/0x70e
    > [ 31.989072] [] lock_acquire+0x5d/0x7a
    > [ 31.989072] [] mutex_lock_nested+0xdf/0x251
    > [ 31.989072] [] sysfs_addrm_start+0x23/0x90
    > [ 31.989072] [] create_dir+0x3a/0x72
    > [ 31.989072] [] sysfs_create_dir+0x2d/0x41
    > [ 31.989072] [] kobject_add_internal+0xe5/0x189
    > [ 31.989072] [] kobject_add_varg+0x35/0x41
    > [ 31.989072] [] kobject_add+0x49/0x4f
    > [ 31.989072] [] device_add+0x76/0x4c8
    > [ 31.989072] [] netdev_register_kobject+0x64/0x69
    > [ 31.989072] [] register_netdevice+0x1fe/0x274
    > [ 31.989072] [] register_netdev+0x32/0x3f
    > [ 31.989072] [] loopback_net_init+0x2e/0x5d
    > [ 31.989072] [] register_pernet_operations+0x13/0x15
    > [ 31.989072] [] register_pernet_device+0x1f/0x4c
    > [ 31.989072] [] loopback_init+0xd/0xf
    > [ 31.989072] [] _stext+0x48/0x10d
    > [ 31.989072] [] kernel_init+0xf1/0x142
    > [ 31.989072] [] kernel_thread_helper+0x7/0x10
    > [ 31.989072] [] 0xffffffff
    > [ 31.989072]
    > [ 31.989072] -> #0 (rtnl_mutex){--..}:
    > [ 31.989072] [] validate_chain+0x5a3/0xb35
    > [ 31.989072] [] __lock_acquire+0x680/0x70e
    > [ 31.989072] [] lock_acquire+0x5d/0x7a
    > [ 31.989072] [] mutex_lock_nested+0xdf/0x251
    > [ 31.989072] [] rtnl_lock+0xf/0x11
    > [ 31.989072] [] linkwatch_event+0x8/0x27
    > [ 31.989072] [] run_workqueue+0xbe/0x189
    > [ 31.989072] [] worker_thread+0xb4/0xbf
    > [ 31.989072] [] kthread+0x3b/0x61
    > [ 31.989072] [] kernel_thread_helper+0x7/0x10
    > [ 31.989072] [] 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: [] run_workqueue+0x80/0x189
    > [ 31.989072] #1: ((linkwatch_work).work){--..}, at: [] 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] [] print_circular_bug_tail+0xa4/0xaf
    > [ 31.989072] [] validate_chain+0x5a3/0xb35
    > [ 31.989072] [] __lock_acquire+0x680/0x70e
    > [ 31.989072] [] ? run_workqueue+0x80/0x189
    > [ 31.989072] [] lock_acquire+0x5d/0x7a
    > [ 31.989072] [] ? rtnl_lock+0xf/0x11
    > [ 31.989072] [] mutex_lock_nested+0xdf/0x251
    > [ 31.989072] [] ? rtnl_lock+0xf/0x11
    > [ 31.989072] [] ? rtnl_lock+0xf/0x11
    > [ 31.989072] [] rtnl_lock+0xf/0x11
    > [ 31.989072] [] linkwatch_event+0x8/0x27
    > [ 31.989072] [] run_workqueue+0xbe/0x189
    > [ 31.989072] [] ? run_workqueue+0x80/0x189
    > [ 31.989072] [] ? linkwatch_event+0x0/0x27
    > [ 31.989072] [] ? worker_thread+0x0/0xbf
    > [ 31.989072] [] worker_thread+0xb4/0xbf
    > [ 31.989072] [] ? autoremove_wake_function+0x0/0x33
    > [ 31.989072] [] 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] [] ? kthread+0x0/0x61
    > [ 31.989072] [] 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...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: next-20081103: oxu210hp-hcd.c:3849: error: implicit declaration of function 'set_irq_type'

    On Tue, Nov 04, 2008 at 05:30:38PM +0100, Rodolfo Giometti wrote:
    > On Mon, Nov 03, 2008 at 06:50:47PM +0300, Alexey Dobriyan wrote:
    > > 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.

    >
    > Should I force CONFIG_GENERIC_HARDIRQS selection?


    Of course, no!
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: next-20081103 - possible circular locking dependency detected while bring up eth1

    > > [ 31.989072] 2 locks held by events/3/18:
    > > [ 31.989072] #0: (events){--..}, at: [] run_workqueue+0x80/0x189
    > > [ 31.989072] #1: ((linkwatch_work).work){--..}, at: [] 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] [] print_circular_bug_tail+0xa4/0xaf
    > > [ 31.989072] [] validate_chain+0x5a3/0xb35
    > > [ 31.989072] [] __lock_acquire+0x680/0x70e
    > > [ 31.989072] [] ? run_workqueue+0x80/0x189
    > > [ 31.989072] [] lock_acquire+0x5d/0x7a
    > > [ 31.989072] [] ? rtnl_lock+0xf/0x11
    > > [ 31.989072] [] mutex_lock_nested+0xdf/0x251
    > > [ 31.989072] [] ? rtnl_lock+0xf/0x11
    > > [ 31.989072] [] ? rtnl_lock+0xf/0x11
    > > [ 31.989072] [] rtnl_lock+0xf/0x11
    > > [ 31.989072] [] linkwatch_event+0x8/0x27
    > > [ 31.989072] [] run_workqueue+0xbe/0x189
    > > [ 31.989072] [] ? run_workqueue+0x80/0x189
    > > [ 31.989072] [] ? linkwatch_event+0x0/0x27
    > > [ 31.989072] [] ? worker_thread+0x0/0xbf
    > > [ 31.989072] [] worker_thread+0xb4/0xbf
    > > [ 31.989072] [] ? autoremove_wake_function+0x0/0x33
    > > [ 31.989072] [] 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] [] ? kthread+0x0/0x61
    > > [ 31.989072] [] 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.




    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: linux-next: Tree for November 3

    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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkkSxGQACgkQuL75KpiFGIxaoQCcD+vw7oa9mI Hwe8tU6FFiSoOe
    e90AoLxyIhbmC4mU0LBaQT86d9t2ucS+
    =ZLnw
    -----END PGP SIGNATURE-----


+ Reply to Thread