* linux-next: rr tree build warning
From: Stephen Rothwell @ 2009-11-12 8:21 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, linux-kernel, Alan Jenkins
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hi Rusty,
Today's linux-next build (i386 defconfig) produced this warning:
kernel/module.c:1953: warning: 'crc_section_names' defined but not used
Introduced by commit 67260d90118a2394df528fe4e37e814d950ca5b5 ("module:
refactor symbol tables and try to reduce code size of each_symbol()").
This build has CONFIG_MODVERSIONS disabled.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* linux-next: rr/sparc tree build failure
From: Stephen Rothwell @ 2009-11-12 8:30 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, linux-kernel, David S. Miller
Hi Rusty, Dave,
Today's linux-next build (sparc64 defconfig) failed like this:
.tmp_exports-asm.o: In function `__ksymtab_pci_alloc_consistent':
(__ksymtab_sorted+0x6650): undefined reference to `pci_alloc_consistent'
.tmp_exports-asm.o: In function `__ksymtab_pci_dma_supported':
(__ksymtab_sorted+0x6810): undefined reference to `pci_dma_supported'
.tmp_exports-asm.o: In function `__ksymtab_pci_dma_sync_sg_for_cpu':
(__ksymtab_sorted+0x6820): undefined reference to `pci_dma_sync_sg_for_cpu'
.tmp_exports-asm.o: In function `__ksymtab_pci_dma_sync_single_for_cpu':
(__ksymtab_sorted+0x6830): undefined reference to `pci_dma_sync_single_for_cpu'
.tmp_exports-asm.o: In function `__ksymtab_pci_free_consistent':
(__ksymtab_sorted+0x6910): undefined reference to `pci_free_consistent'
.tmp_exports-asm.o: In function `__ksymtab_pci_map_sg':
(__ksymtab_sorted+0x69b0): undefined reference to `pci_map_sg'
.tmp_exports-asm.o: In function `__ksymtab_pci_map_single':
(__ksymtab_sorted+0x69c0): undefined reference to `pci_map_single'
.tmp_exports-asm.o: In function `__ksymtab_pci_unmap_sg':
(__ksymtab_sorted+0x6c40): undefined reference to `pci_unmap_sg'
.tmp_exports-asm.o: In function `__ksymtab_pci_unmap_single':
(__ksymtab_sorted+0x6c50): undefined reference to `pci_unmap_single'
Caused by sparc64 exporting static inline functions. This has interacted
with changes in the rr tree to produce these errors.
I have applied this patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Nov 2009 19:26:14 +1100
Subject: [PATCH] sparc64: don't export static inline pci_ functions
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/kernel/pci.c | 1 -
arch/sparc/kernel/sparc_ksyms_64.c | 12 ------------
2 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index b85374f..539e83f 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -1064,7 +1064,6 @@ int pci64_dma_supported(struct pci_dev *pdev, u64 device_mask)
return (device_mask & dma_addr_mask) == dma_addr_mask;
}
-EXPORT_SYMBOL(pci_dma_supported);
void pci_resource_to_user(const struct pci_dev *pdev, int bar,
const struct resource *rp, resource_size_t *start,
diff --git a/arch/sparc/kernel/sparc_ksyms_64.c b/arch/sparc/kernel/sparc_ksyms_64.c
index 0f26066..372ad59 100644
--- a/arch/sparc/kernel/sparc_ksyms_64.c
+++ b/arch/sparc/kernel/sparc_ksyms_64.c
@@ -38,17 +38,5 @@ EXPORT_SYMBOL(sun4v_niagara_setperf);
EXPORT_SYMBOL(sun4v_niagara2_getperf);
EXPORT_SYMBOL(sun4v_niagara2_setperf);
-#ifdef CONFIG_PCI
-/* inline functions in asm/pci_64.h */
-EXPORT_SYMBOL(pci_alloc_consistent);
-EXPORT_SYMBOL(pci_free_consistent);
-EXPORT_SYMBOL(pci_map_single);
-EXPORT_SYMBOL(pci_unmap_single);
-EXPORT_SYMBOL(pci_map_sg);
-EXPORT_SYMBOL(pci_unmap_sg);
-EXPORT_SYMBOL(pci_dma_sync_single_for_cpu);
-EXPORT_SYMBOL(pci_dma_sync_sg_for_cpu);
-#endif
-
/* Exporting a symbol from /init/main.c */
EXPORT_SYMBOL(saved_command_line);
--
1.6.5.2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* linux-next: Tree for November 12
From: Stephen Rothwell @ 2009-11-12 8:51 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 9198 bytes --]
Hi all,
Changes since 20091111:
Linus' tree gained a build failure for which I applied a patch.
The net tree lost 3 conflicts.
The cpufreq tree gained a conflict against the acpi tree.
The rr tree lost its build failure but exposed build failures in the
powerpc and sparc trees for which I applied patches. It also had another
build failure due to an interaction with the kbuild tree for which I
applied another patch.
The i7core_edac tree gained a build failure for which I have applied a
patch.
The tip tree lost its build failure.
The sysctl tree gained a build failure for which I applied a patch.
The usb tree lost its conflicts.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/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 (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 148 trees (counting Linus' and 22 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 fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Applying: jbd: export log_start_commit for ext3
Merging arm/devel
Merging davinci/davinci-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging avr32/avr32-arch
CONFLICT (content): Merge conflict in arch/avr32/mach-at32ap/include/mach/cpu.h
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
CONFLICT (content): Merge conflict in drivers/rtc/Kconfig
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in drivers/media/common/tuners/tda18271-fe.c
Merging kbuild/master
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
CONFLICT (content): Merge conflict in arch/powerpc/kvm/timing.h
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging net/master
CONFLICT (delete/modify): drivers/net/sfc/sfe4001.c deleted in net/master and modified in HEAD. Version HEAD of drivers/net/sfc/sfe4001.c left in tree.
CONFLICT (content): Merge conflict in drivers/net/wireless/libertas/cmd.c
CONFLICT (content): Merge conflict in drivers/staging/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/Makefile
CONFLICT (content): Merge conflict in drivers/staging/rtl8187se/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/rtl8192e/Kconfig
$ git rm -f drivers/net/sfc/sfe4001.c
Applying: net: merge fixup for drivers/net/sfc/falcon_boards.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3evm.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in include/acpi/processor.h
Merging quilt/rr
Merging mmc/next
Merging tmio-mmc/linux-next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
CONFLICT (content): Merge conflict in drivers/mtd/maps/pcmciamtd.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ray_cs.c
CONFLICT (content): Merge conflict in drivers/pcmcia/Makefile
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
CONFLICT (content): Merge conflict in drivers/mfd/Kconfig
CONFLICT (content): Merge conflict in drivers/mfd/Makefile
Merging security-testing/next
CONFLICT (content): Merge conflict in Documentation/dontdiff
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
CONFLICT (content): Merge conflict in drivers/misc/Makefile
Merging drbd/for-jens
Merging catalin/for-next
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in drivers/net/Kconfig
CONFLICT (content): Merge conflict in include/linux/Kbuild
CONFLICT (content): Merge conflict in lib/Kconfig
Merging i7core_edac/linux_next
Applying: i7core_edac: do not export static functions
Merging devicetree/next-devicetree
Merging limits/writable_limits
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/kernel/kgdb.c
CONFLICT (content): Merge conflict in kernel/irq/chip.c
Merging oprofile/for-next
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/powerpc/platforms/pseries/hvCall.S
CONFLICT (content): Merge conflict in arch/x86/kvm/svm.c
CONFLICT (content): Merge conflict in kernel/softlockup.c
CONFLICT (content): Merge conflict in mm/percpu.c
Applying: percpu: merge fixup for variable renaming
Merging sfi/sfi-test
Merging asm-generic/next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging quilt/driver-core
Merging quilt/tty
Merging quilt/usb
Merging quilt/staging
CONFLICT (content): Merge conflict in drivers/staging/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/Makefile
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/cb_das16_cs.c
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/ni_labpc_cs.c
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/ni_mio_cs.c
Merging scsi-post-merge/master
Applying: modpost: autoconf.h has moved to include/generated
Applying: sysctl: fix build dependency on CONFIG_NET
Applying: powerpc: do not export pci_alloc/free_consistent
Applying: sparc64: don't export static inline pci_ functions
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: rr tree build failure
From: Benjamin Herrenschmidt @ 2009-11-12 9:02 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linuxppc-dev, Rusty Russell, Paul Mackerras, linux-next,
linux-kernel
In-Reply-To: <20091112190308.443d97a3.sfr@canb.auug.org.au>
On Thu, 2009-11-12 at 19:03 +1100, Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
> .tmp_exports-asm.o: In function `__ksymtab_pci_alloc_consistent':
> (__ksymtab_sorted+0x2a30): undefined reference to `pci_alloc_consistent'
> .tmp_exports-asm.o: In function `__ksymtab_pci_free_consistent':
> (__ksymtab_sorted+0x2b70): undefined reference to `pci_free_consistent'
>
> Caused by the powerpc architecture EXPORTing static inlines (for 32 bit
> builds) interacting with changes in the rr tree.
>
> I have applied this patch for today:
Thanks. Our EXPORTs are bogus (probably leftovers) it seems. I'll dbl
check tomorrow but that looks like a patch I should pickup in powerpc
-next anyways.
Cheers,
Ben.
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 12 Nov 2009 18:54:13 +1100
> Subject: [PATCH] powerpc: do not export pci_alloc/free_consistent
>
> Since they are static inline functions.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/kernel/ppc_ksyms.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
> index 07115d6..4254514 100644
> --- a/arch/powerpc/kernel/ppc_ksyms.c
> +++ b/arch/powerpc/kernel/ppc_ksyms.c
> @@ -96,8 +96,6 @@ EXPORT_SYMBOL(copy_4K_page);
> EXPORT_SYMBOL(isa_io_base);
> EXPORT_SYMBOL(isa_mem_base);
> EXPORT_SYMBOL(pci_dram_offset);
> -EXPORT_SYMBOL(pci_alloc_consistent);
> -EXPORT_SYMBOL(pci_free_consistent);
> #endif /* CONFIG_PCI */
>
> EXPORT_SYMBOL(start_thread);
> --
> 1.6.5.2
>
^ permalink raw reply
* Re: linux-next: sysctl tree build failure
From: Eric W. Biederman @ 2009-11-12 9:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20091112191451.d21250f2.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Eric,
>
> On Thu, 12 Nov 2009 00:08:59 -0800 ebiederm@xmission.com (Eric W. Biederman) wrote:
>>
>> Thank you, and my apologies. I thought I had tried it with every
>> applicable compile option but apparently not.
>>
>> Ugh. It looks like I have a small refcount leak in that case as
>> well. Blind I was.
>>
>> Thank you very I will have this fixed shortly.
>
> Thanks.
Any clue how all_noconfig happened to have CONFIG_SYSCTL_SYSCALL set?
Eric
^ permalink raw reply
* Re: linux-next: sysctl tree build failure
From: Stephen Rothwell @ 2009-11-12 10:47 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-next, linux-kernel
In-Reply-To: <m1fx8kp0op.fsf@fess.ebiederm.org>
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
Hi Eric,
On Thu, 12 Nov 2009 01:11:34 -0800 ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Any clue how all_noconfig happened to have CONFIG_SYSCTL_SYSCALL set?
CONFIG_SYSCTL_SYSCALL defaults to y and only depends on
CONFIG_PROC_SYSCTL which also defaults to y and depends on CONFIG_PROC_FS
which also defaults to y. All three are only selectable if
CONFIG_EMBEDDED is y (which it obviously isn't).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: rr tree build failure
From: Stephen Rothwell @ 2009-11-12 10:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rusty Russell, linux-next, linux-kernel, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1258016520.2140.329.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Hi Ben,
On Thu, 12 Nov 2009 20:02:00 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Thanks. Our EXPORTs are bogus (probably leftovers) it seems. I'll dbl
> check tomorrow but that looks like a patch I should pickup in powerpc
> -next anyways.
That was the idea, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [powerpc] Next tree Nov 2 : kernel BUG at mm/mmap.c:2135!
From: Sachin Sant @ 2009-11-12 11:16 UTC (permalink / raw)
To: dwg
Cc: Linux/PPC Development, Stephen Rothwell, linux-next,
Benjamin Herrenschmidt
In-Reply-To: <20091105001650.GD3613@yookeroo.seuss>
David Gibson wrote:
> On Wed, Nov 04, 2009 at 06:08:44PM +0530, Sachin Sant wrote:
>
>> Sachin Sant wrote:
>>
>>> Today's next tree failed to boot on a POWER 6 box with :
>>>
>>> ------------[ cut here ]------------
>>> kernel BUG at mm/mmap.c:2135!
>>> Oops: Exception in kernel mode, sig: 5 [#2]
>>> SMP NR_CPUS=1024 NUMA pSeries
>>>
>> Problem exists with today's next as well.
>>
>> Likely cause for this problem seems to the following commit.
>> If i revert this patch the machine boots fine.
>>
>> commit a0668cdc154e54bf0c85182e0535eea237d53146
>> powerpc/mm: Cleanup management of kmem_caches for pagetables
>>
>
> Ugh. Ok, it's not at all obvious how my patch could cause this bug.
> Can you send your .config?
>
>
Still present in today's next.
Thanks
-Sachin
>>> Modules linked in: ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
>>> NIP: c00000000014e30c LR: c00000000014e2f8 CTR: c00000000014db88
>>> REGS: c0000000db703620 TRAP: 0700 Tainted: G D
>>> (2.6.32-rc5-autotest-next-20091102)
>>> MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24022442 XER: 2000000c
>>> TASK = c0000000db7f6fe0[76] 'init' THREAD: c0000000db700000 CPU: 1
>>> GPR00: 0000000000000001 c0000000db7038a0 c000000000b19900
>>> 0000000000000000
>>> GPR04: c0000000db406a40 000000000000000c c0000000fe10c370
>>> c000000000bb2800
>>> GPR08: 000000000000db40 0000000000000000 c0000000dfdc0e00
>>> 000000000000000c
>>> GPR12: 0000000044022442 c000000000bb2800 00000000ffffffff
>>> ffffffffffffffff
>>> GPR16: 0000000008430000 00000000003c0000 c0000000db703ea0
>>> c0000000db569108
>>> GPR20: c0000000db568908 0000000000000000 c0000000db703d60
>>> 0000000000000000
>>> GPR24: 0000000000000001 0000000000040100 c0000000fe503580
>>> c0000000db1ac180
>>> GPR28: 0000000000000000 c000000000f812d0 c000000000a84f00
>>> 0000000000000000
>>> NIP [c00000000014e30c] .exit_mmap+0x190/0x1b8
>>> LR [c00000000014e2f8] .exit_mmap+0x17c/0x1b8
>>> Call Trace:
>>> [c0000000db7038a0] [c00000000014e2f8] .exit_mmap+0x17c/0x1b8 (unreliable)
>>> [c0000000db703950] [c0000000000916cc] .mmput+0x54/0x164
>>> [c0000000db7039e0] [c0000000000968d8] .exit_mm+0x17c/0x1a0
>>> [c0000000db703a90] [c000000000098cb8] .do_exit+0x248/0x784
>>> [c0000000db703b70] [c0000000000992a8] .do_group_exit+0xb4/0xe8
>>> [c0000000db703c00] [c0000000000aca2c] .get_signal_to_deliver+0x3ec/0x478
>>> [c0000000db703cf0] [c0000000000134ac] .do_signal+0x6c/0x31c
>>> [c0000000db703e30] [c000000000008b7c] do_work+0x24/0x28
>>> Instruction dump:
>>> 7c8407b4 387d0018 4800ab11 60000000 939d0008 7fe3fb78 4bfffdbd 7c7f1b79
>>> 4082fff4 e81b00e8 3120ffff 7c090110 <0b000000> 382100b0 e8010010 eb61ffd8
>>> ---[ end trace ec052ac77a8e7cb4 ]---
>>> Fixing recursive fault but reboot is needed!
>>>
>>> mm/mmap.c:2135 corresponds to :
>>>
>>> BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
>>>
>>>
>
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* -next: Nov 12 - kernel BUG at kernel/sched.c:7359!
From: Sachin Sant @ 2009-11-12 11:53 UTC (permalink / raw)
To: LKML; +Cc: Stephen Rothwell, linux-next, Ingo Molnar, peterz
In-Reply-To: <20091112195101.63263490.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20091111:
>
I came across the following bug while executing cpu hotplug tests
on a x86_64 box. This is with next version 2.6.32-rc6-20091112.
(20280eab85704dcd05a20903f0de80be1c761c6e)
This is a 4 way box. The problem is not always reproducible and
can be recreated only after some amount of activity.
------------[ cut here ]------------
kernel BUG at kernel/sched.c:7359!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu1/online
CPU 0
Modules linked in: ipv6 fuse loop dm_mod sg mptctl bnx2 rtc_cmos rtc_core
rtc_lib i2c_piix4 tpm_tis serio_raw button shpchp pcspkr tpm i2c_core
pci_hotplug k8temp tpm_bios ohci_hcd ehci_hcd sd_mod crc_t10dif usbcore edd fan
thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas
scsi_mod
Pid: 11504, comm: hotplug04.sh Not tainted 2.6.32-rc6-autotest-next-20091112 #1
BladeCenter LS21 -[79716AA]-
RIP: 0010:[<ffffffff8134a744>] [<ffffffff8134a744>] migration_call+0x381/0x51a
RSP: 0018:ffff8801159fdd48 EFLAGS: 00010046
RAX: 0000000000000001 RBX: ffff88011e2de180 RCX: ffffffffff8d8f20
RDX: ffff880028280000 RSI: ffff880028293f88 RDI: ffff880127a3e708
RBP: ffff8801159fdd98 R08: 0000000000000000 R09: 000000046c250cb4
R10: dead000000100100 R11: 7fffffffffffffff R12: ffffffff816d7020
R13: ffff880028293f00 R14: ffff880127a3e6c0 R15: ffff880028293f00
FS: 00007f782aef66f0(0000) GS:ffff880028200000(0000) knlGS:0000000055731b00
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000061f4f0 CR3: 00000001271a0000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process hotplug04.sh (pid: 11504, threadinfo ffff8801159fc000, task
ffff8801293e2600)
Stack:
0000000000000001 0000000000013f00 0000000100000000 0000000000000001
<0> ffff8801159fddb8 0000000000000000 00000000fffffffe ffffffff8176c800
<0> 0000000000000001 0000000000000007 ffff8801159fddd8 ffffffff81351b16
Call Trace:
[<ffffffff81351b16>] notifier_call_chain+0x33/0x5b
[<ffffffff8105db28>] raw_notifier_call_chain+0xf/0x11
[<ffffffff8133db32>] _cpu_down+0x1f7/0x2f1
[<ffffffff8134cb6a>] ? wait_for_completion+0x18/0x1a
[<ffffffff8133dc74>] cpu_down+0x48/0x80
[<ffffffff8133f89a>] store_online+0x2c/0x6f
[<ffffffff8128c44b>] sysdev_store+0x1b/0x1d
[<ffffffff811382f8>] sysfs_write_file+0xdf/0x114
[<ffffffff810e4401>] vfs_write+0xb4/0x186
[<ffffffff810e4597>] sys_write+0x47/0x6e
[<ffffffff81002a6b>] system_call_fastpath+0x16/0x1b
Code: c6 75 05 48 8b 1b eb ed 49 8b 46 30 4c 89 f6 4c 89 ff ff 50 30 41 83 be
78 04 00 00 00 48 8b 45 b0 48 8b 14 c5 70 4d 77 81 75 04 <0f> 0b eb fe 49 8b 06
48 83 f8 40 75 04 0f 0b eb fe 48 8b 5d b8
RIP [<ffffffff8134a744>] migration_call+0x381/0x51a
kernel/sched.c:7359 corresponds to
/* called under rq->lock with disabled interrupts */
static void migrate_dead(unsigned int dead_cpu, struct task_struct *p)
{
struct rq *rq = cpu_rq(dead_cpu);
/* Must be exiting, otherwise would be on tasklist. */
BUG_ON(!p->exit_state); <<====
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: -next: Nov 12 - kernel BUG at kernel/sched.c:7359!
From: Peter Zijlstra @ 2009-11-12 12:10 UTC (permalink / raw)
To: Sachin Sant; +Cc: LKML, Stephen Rothwell, linux-next, Ingo Molnar
In-Reply-To: <4AFBF73B.5040500@in.ibm.com>
On Thu, 2009-11-12 at 17:23 +0530, Sachin Sant wrote:
> Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20091111:
> >
> I came across the following bug while executing cpu hotplug tests
> on a x86_64 box. This is with next version 2.6.32-rc6-20091112.
> (20280eab85704dcd05a20903f0de80be1c761c6e)
>
> This is a 4 way box. The problem is not always reproducible and
> can be recreated only after some amount of activity.
>
> ------------[ cut here ]------------
> kernel BUG at kernel/sched.c:7359!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/devices/system/cpu/cpu1/online
> CPU 0
> Modules linked in: ipv6 fuse loop dm_mod sg mptctl bnx2 rtc_cmos rtc_core
> rtc_lib i2c_piix4 tpm_tis serio_raw button shpchp pcspkr tpm i2c_core
> pci_hotplug k8temp tpm_bios ohci_hcd ehci_hcd sd_mod crc_t10dif usbcore edd fan
> thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas
> scsi_mod
> Pid: 11504, comm: hotplug04.sh Not tainted 2.6.32-rc6-autotest-next-20091112 #1
> BladeCenter LS21 -[79716AA]-
> RIP: 0010:[<ffffffff8134a744>] [<ffffffff8134a744>] migration_call+0x381/0x51a
> RSP: 0018:ffff8801159fdd48 EFLAGS: 00010046
> RAX: 0000000000000001 RBX: ffff88011e2de180 RCX: ffffffffff8d8f20
> RDX: ffff880028280000 RSI: ffff880028293f88 RDI: ffff880127a3e708
> RBP: ffff8801159fdd98 R08: 0000000000000000 R09: 000000046c250cb4
> R10: dead000000100100 R11: 7fffffffffffffff R12: ffffffff816d7020
> R13: ffff880028293f00 R14: ffff880127a3e6c0 R15: ffff880028293f00
> FS: 00007f782aef66f0(0000) GS:ffff880028200000(0000) knlGS:0000000055731b00
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000000061f4f0 CR3: 00000001271a0000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process hotplug04.sh (pid: 11504, threadinfo ffff8801159fc000, task
> ffff8801293e2600)
> Stack:
> 0000000000000001 0000000000013f00 0000000100000000 0000000000000001
> <0> ffff8801159fddb8 0000000000000000 00000000fffffffe ffffffff8176c800
> <0> 0000000000000001 0000000000000007 ffff8801159fddd8 ffffffff81351b16
> Call Trace:
> [<ffffffff81351b16>] notifier_call_chain+0x33/0x5b
> [<ffffffff8105db28>] raw_notifier_call_chain+0xf/0x11
> [<ffffffff8133db32>] _cpu_down+0x1f7/0x2f1
> [<ffffffff8134cb6a>] ? wait_for_completion+0x18/0x1a
> [<ffffffff8133dc74>] cpu_down+0x48/0x80
> [<ffffffff8133f89a>] store_online+0x2c/0x6f
> [<ffffffff8128c44b>] sysdev_store+0x1b/0x1d
> [<ffffffff811382f8>] sysfs_write_file+0xdf/0x114
> [<ffffffff810e4401>] vfs_write+0xb4/0x186
> [<ffffffff810e4597>] sys_write+0x47/0x6e
> [<ffffffff81002a6b>] system_call_fastpath+0x16/0x1b
> Code: c6 75 05 48 8b 1b eb ed 49 8b 46 30 4c 89 f6 4c 89 ff ff 50 30 41 83 be
> 78 04 00 00 00 48 8b 45 b0 48 8b 14 c5 70 4d 77 81 75 04 <0f> 0b eb fe 49 8b 06
> 48 83 f8 40 75 04 0f 0b eb fe 48 8b 5d b8
> RIP [<ffffffff8134a744>] migration_call+0x381/0x51a
>
> kernel/sched.c:7359 corresponds to
>
> /* called under rq->lock with disabled interrupts */
> static void migrate_dead(unsigned int dead_cpu, struct task_struct *p)
> {
> struct rq *rq = cpu_rq(dead_cpu);
>
> /* Must be exiting, otherwise would be on tasklist. */
> BUG_ON(!p->exit_state); <<====
I'm pretty sure we stumbled on a TASK_WAKING task there, trying to sort
out the locking there, its a bit of a maze :/
How reproducable is this?
^ permalink raw reply
* Re: linux-next: sysctl tree build failure
From: Eric W. Biederman @ 2009-11-12 12:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20091112214706.7c7b3168.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Eric,
>
> On Thu, 12 Nov 2009 01:11:34 -0800 ebiederm@xmission.com (Eric W. Biederman) wrote:
>>
>> Any clue how all_noconfig happened to have CONFIG_SYSCTL_SYSCALL set?
>
> CONFIG_SYSCTL_SYSCALL defaults to y and only depends on
> CONFIG_PROC_SYSCTL which also defaults to y and depends on CONFIG_PROC_FS
> which also defaults to y. All three are only selectable if
> CONFIG_EMBEDDED is y (which it obviously isn't).
Ah so. An interesting twist of fate. Thank you for satisfying my
curiosity.
Eric
^ permalink raw reply
* Re: linux-next: manual merge of the cpufreq tree with the acpi tree
From: Thomas Renninger @ 2009-11-12 12:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Dave Jones, linux-next, linux-kernel, Zhao Yakui, Len Brown
In-Reply-To: <20091112134524.d9854379.sfr@canb.auug.org.au>
On Wednesday 11 November 2009 08:45:24 pm Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next merge of the cpufreq tree got a conflict in
> include/acpi/processor.h between commit
> d81c45e1c9369855901420f79114852eba2ea16a ("ACPI: Notify the _PPC
> evaluation status to the platform") from the acpi tree and commit
> b02d803d0fa3a395ba32bc5e5e3e7a3385ca7237 ("[CPUFREQ] Introduce bios_limit
> per cpu cpufreq sysfs interface") from the cpufreq tree.
First, thanks everybody for picking this up.
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
>
> By the way, Dave, Thomas, shouldn't the second version of
> acpi_processor_get_bios_limit() in include/acpi/processor.h introduced by
> the above cpufreq tree patch be "static inline"?
Yes, good catch.
Shall I send an on top fix somewhere?
Thomas
@@ -295,6 +295,7 @@ static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
void acpi_processor_ppc_init(void);
void acpi_processor_ppc_exit(void);
int acpi_processor_ppc_has_changed(struct acpi_processor *pr);
+extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
#else
static inline void acpi_processor_ppc_init(void)
{
@@ -316,6 +317,11 @@ static inline int acpi_processor_ppc_has_changed(struct acpi_processor *pr)
}
return 0;
}
+int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
+{
+ return -ENODEV;
+}
+
#endif /* CONFIG_CPU_FREQ */
^ permalink raw reply
* Re: -next: Nov 12 - kernel BUG at kernel/sched.c:7359!
From: Sachin Sant @ 2009-11-12 12:23 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: LKML, Stephen Rothwell, linux-next, Ingo Molnar
In-Reply-To: <1258027820.4039.129.camel@laptop>
Peter Zijlstra wrote:
>> ------------[ cut here ]------------
>> kernel BUG at kernel/sched.c:7359!
>> invalid opcode: 0000 [#1] SMP
>> last sysfs file: /sys/devices/system/cpu/cpu1/online
>> CPU 0
>> Modules linked in: ipv6 fuse loop dm_mod sg mptctl bnx2 rtc_cmos rtc_core
>> rtc_lib i2c_piix4 tpm_tis serio_raw button shpchp pcspkr tpm i2c_core
>> pci_hotplug k8temp tpm_bios ohci_hcd ehci_hcd sd_mod crc_t10dif usbcore edd fan
>> thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas
>> scsi_mod
>> Pid: 11504, comm: hotplug04.sh Not tainted 2.6.32-rc6-autotest-next-20091112 #1
>> BladeCenter LS21 -[79716AA]-
>> RIP: 0010:[<ffffffff8134a744>] [<ffffffff8134a744>] migration_call+0x381/0x51a
>> RSP: 0018:ffff8801159fdd48 EFLAGS: 00010046
>> RAX: 0000000000000001 RBX: ffff88011e2de180 RCX: ffffffffff8d8f20
>> RDX: ffff880028280000 RSI: ffff880028293f88 RDI: ffff880127a3e708
>> RBP: ffff8801159fdd98 R08: 0000000000000000 R09: 000000046c250cb4
>> R10: dead000000100100 R11: 7fffffffffffffff R12: ffffffff816d7020
>> R13: ffff880028293f00 R14: ffff880127a3e6c0 R15: ffff880028293f00
>> FS: 00007f782aef66f0(0000) GS:ffff880028200000(0000) knlGS:0000000055731b00
>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 000000000061f4f0 CR3: 00000001271a0000 CR4: 00000000000006f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process hotplug04.sh (pid: 11504, threadinfo ffff8801159fc000, task
>> ffff8801293e2600)
>> Stack:
>> 0000000000000001 0000000000013f00 0000000100000000 0000000000000001
>> <0> ffff8801159fddb8 0000000000000000 00000000fffffffe ffffffff8176c800
>> <0> 0000000000000001 0000000000000007 ffff8801159fddd8 ffffffff81351b16
>> Call Trace:
>> [<ffffffff81351b16>] notifier_call_chain+0x33/0x5b
>> [<ffffffff8105db28>] raw_notifier_call_chain+0xf/0x11
>> [<ffffffff8133db32>] _cpu_down+0x1f7/0x2f1
>> [<ffffffff8134cb6a>] ? wait_for_completion+0x18/0x1a
>> [<ffffffff8133dc74>] cpu_down+0x48/0x80
>> [<ffffffff8133f89a>] store_online+0x2c/0x6f
>> [<ffffffff8128c44b>] sysdev_store+0x1b/0x1d
>> [<ffffffff811382f8>] sysfs_write_file+0xdf/0x114
>> [<ffffffff810e4401>] vfs_write+0xb4/0x186
>> [<ffffffff810e4597>] sys_write+0x47/0x6e
>> [<ffffffff81002a6b>] system_call_fastpath+0x16/0x1b
>> Code: c6 75 05 48 8b 1b eb ed 49 8b 46 30 4c 89 f6 4c 89 ff ff 50 30 41 83 be
>> 78 04 00 00 00 48 8b 45 b0 48 8b 14 c5 70 4d 77 81 75 04 <0f> 0b eb fe 49 8b 06
>> 48 83 f8 40 75 04 0f 0b eb fe 48 8b 5d b8
>> RIP [<ffffffff8134a744>] migration_call+0x381/0x51a
> I'm pretty sure we stumbled on a TASK_WAKING task there, trying to sort
> out the locking there, its a bit of a maze :/
>
> How reproducable is this?
>
I was able to recreate this once out of three tries.
When i was able to recreate this bug, the box had been
running for a while and i had executed series of tests
(kernbench, hackbench, hugetlbfs) before cpu_hotplug.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: -next: Nov 12 - kernel BUG at kernel/sched.c:7359!
From: Peter Zijlstra @ 2009-11-12 12:27 UTC (permalink / raw)
To: Sachin Sant; +Cc: LKML, Stephen Rothwell, linux-next, Ingo Molnar
In-Reply-To: <4AFBFE3D.80507@in.ibm.com>
On Thu, 2009-11-12 at 17:53 +0530, Sachin Sant wrote:
> > How reproducable is this?
> >
> I was able to recreate this once out of three tries.
>
> When i was able to recreate this bug, the box had been
> running for a while and i had executed series of tests
> (kernbench, hackbench, hugetlbfs) before cpu_hotplug.
OK good, its easier to test patches when the thing is relatively easy to
reproduce. I'll send you something to test once I've got a handle on it.
Thanks!
^ permalink raw reply
* Re: linux-next: i7core_edac tree build failure
From: Rusty Russell @ 2009-11-12 13:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Mauro Carvalho Chehab, linux-next, linux-kernel, Aristeu Rozanski
In-Reply-To: <20091112165852.855d1e5d.sfr@canb.auug.org.au>
On Thu, 12 Nov 2009 04:28:52 pm Stephen Rothwell wrote:
> Hi Mauro,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> tmp_exports-asm.o: In function `__ksymtab_pci_legacy_init':
> (__ksymtab_gpl_sorted+0x3120): undefined reference to `pci_legacy_init'
>
> Caused by commit a120a84ebbc4cbc9c1addddd2b491e3683b842a6 ("pci: Add a
> probing code that seeks for an specific bus") (which applies
> EXPORT_SYMBOL_GPL() to a static function) interacting with the rr tree's
> changes.
Yep, thanks Stephen. I can't apply this fix to my tree since that function
isn't exported in Linus' tree. I've pulled in the ppc and sparc fixes to my
tree though, but assume they'll go into their proper homes soon.
Thanks,
Rusty.
^ permalink raw reply
* Re: linux-next: rr tree build warning
From: Rusty Russell @ 2009-11-12 13:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Alan Jenkins
In-Reply-To: <20091112192114.dcf32d16.sfr@canb.auug.org.au>
On Thu, 12 Nov 2009 06:51:14 pm Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (i386 defconfig) produced this warning:
>
> kernel/module.c:1953: warning: 'crc_section_names' defined but not used
>
> Introduced by commit 67260d90118a2394df528fe4e37e814d950ca5b5 ("module:
> refactor symbol tables and try to reduce code size of each_symbol()").
> This build has CONFIG_MODVERSIONS disabled.
Thanks. I hit that warning in my config too, but didn't notice :(
Subject: Fix warning for CONFIG_MODVERSIONS=n:
linux-next Maestro Stephen Rothwell reports:
Today's linux-next build (i386 defconfig) produced this warning:
kernel/module.c:1953: warning: 'crc_section_names' defined but not used
Introduced by commit 67260d90118a2394df528fe4e37e814d950ca5b5 ("module:
refactor symbol tables and try to reduce code size of each_symbol()").
This build has CONFIG_MODVERSIONS disabled.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1075,6 +1075,16 @@ static int try_to_force_load(struct modu
}
#ifdef CONFIG_MODVERSIONS
+static const char *crc_section_names[] = {
+ [EXPORT_TYPE_PLAIN] = "__kcrctab",
+ [EXPORT_TYPE_GPL] = "__kcrctab_gpl",
+#ifdef CONFIG_UNUSED_SYMBOLS
+ [EXPORT_TYPE_UNUSED] = "__kcrctab_unused",
+ [EXPORT_TYPE_UNUSED_GPL] = "__kcrctab_unused_gpl",
+#endif
+ [EXPORT_TYPE_GPL_FUTURE] = "__kcrctab_gpl_future",
+};
+
static int check_version(Elf_Shdr *sechdrs,
unsigned int versindex,
const char *symname,
@@ -2103,16 +2113,6 @@ static const char *export_section_names[
[EXPORT_TYPE_GPL_FUTURE] = "__ksymtab_gpl_future",
};
-static const char *crc_section_names[] = {
- [EXPORT_TYPE_PLAIN] = "__kcrctab",
- [EXPORT_TYPE_GPL] = "__kcrctab_gpl",
-#ifdef CONFIG_UNUSED_SYMBOLS
- [EXPORT_TYPE_UNUSED] = "__kcrctab_unused",
- [EXPORT_TYPE_UNUSED_GPL] = "__kcrctab_unused_gpl",
-#endif
- [EXPORT_TYPE_GPL_FUTURE] = "__kcrctab_gpl_future",
-};
-
/* Allocate and load the module: note that size of section 0 is always
zero, and we rely on this for optional sections. */
static noinline struct module *load_module(void __user *umod,
^ permalink raw reply
* Re: linux-next: percpu tree build warning
From: Christoph Lameter @ 2009-11-12 15:16 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Tejun Heo, Rusty Russell, Ingo Molnar, linux-next, linux-kernel
In-Reply-To: <20091112174558.128cea97.sfr@canb.auug.org.au>
On Thu, 12 Nov 2009, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
>
> drivers/net/loopback.c: In function 'loopback_get_stats':
> drivers/net/loopback.c:109: warning: initialization discards qualifiers from pointer target type
>
> The line in question is:
>
> lb_stats = per_cpu_ptr(pcpu_lstats, i);
>
> Where "lb_stats" and "pcpu_lstats" are both "const struct pcpu_lstats
> *". I guess this is because of __verify_pcpu_ptr().
hmm... pcpu_lstats needs to be correctly qualified I guess.
^ permalink raw reply
* Re: -next: Nov 12 - kernel BUG at kernel/sched.c:7359!
From: Peter Zijlstra @ 2009-11-12 17:10 UTC (permalink / raw)
To: Sachin Sant
Cc: LKML, Stephen Rothwell, linux-next, Ingo Molnar, Mike Galbraith,
Gautham R Shenoy
In-Reply-To: <1258028831.4039.152.camel@laptop>
On Thu, 2009-11-12 at 13:27 +0100, Peter Zijlstra wrote:
> On Thu, 2009-11-12 at 17:53 +0530, Sachin Sant wrote:
> > > How reproducable is this?
> > >
> > I was able to recreate this once out of three tries.
> >
> > When i was able to recreate this bug, the box had been
> > running for a while and i had executed series of tests
> > (kernbench, hackbench, hugetlbfs) before cpu_hotplug.
>
> OK good, its easier to test patches when the thing is relatively easy to
> reproduce. I'll send you something to test once I've got a handle on it.
OK.. so on hotplug we do:
cpu_down
set_cpu_active(false)
_cpu_down
notify(CPU_DOWN_PREPARE)
stop_machine(take_cpu_down)
__cpu_disable()
set_cpu_online(false);
notify(CPU_DYING)
__cpu_die() /* note no more stop_machine */
notify(CPU_DEAD)
Then on the scheduler hotplug notifier (migration_call), we mostly deal
with CPU_DEAD, where we do:
case CPU_DEAD:
case CPU_DEAD_FROZEN:
cpuset_lock(); /* around calls to cpuset_cpus_allowed_lock() */
migrate_live_tasks(cpu);
rq = cpu_rq(cpu);
kthread_stop(rq->migration_thread);
put_task_struct(rq->migration_thread);
rq->migration_thread = NULL;
/* Idle task back to normal (off runqueue, low prio) */
spin_lock_irq(&rq->lock);
update_rq_clock(rq);
deactivate_task(rq, rq->idle, 0);
rq->idle->static_prio = MAX_PRIO;
__setscheduler(rq, rq->idle, SCHED_NORMAL, 0);
rq->idle->sched_class = &idle_sched_class;
migrate_dead_tasks(cpu);
spin_unlock_irq(&rq->lock);
cpuset_unlock();
Where migrate_list_tasks() basically iterates the full task list, and
for each task where task_cpu() == dead_cpu invokes __migrate_task() to
move it to an online cpu.
Furthermore, the sched_domain notifier (update_sched_domains), will on
CPU_DEAD rebuild the sched_domain tree.
Now, I think this all can race against try_to_wake_up() when
select_task_rq_fair() hits the old sched_domain tree, because it only
overlays the sched_domain masks against p->cpus_allowed, without regard
for cpu_online_mask.
It could therefore return an offline cpu and move a task onto it after
migrate_live_tasks() and before migrate_dead_tasks().
The trivial solution that comes to mind is something like this:
diff --git a/kernel/sched.c b/kernel/sched.c
index 1f2e99d..15dcb41 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2376,7 +2376,11 @@ static int try_to_wake_up(struct task_struct *p, unsigned int state,
p->state = TASK_WAKING;
task_rq_unlock(rq, &flags);
+again:
cpu = p->sched_class->select_task_rq(p, SD_BALANCE_WAKE, wake_flags);
+ if (!cpu_active(cpu))
+ goto again;
+
if (cpu != orig_cpu) {
local_irq_save(flags);
rq = cpu_rq(cpu);
However, Mike ran into a similar problem and we tried something similar
and that deadlocked for him -- something which I can see happen when we
do this from an interrupt on the machine running the CPU_DEAD notifier
and the update_sched_domains() notifier will be run after the
migration_call() notifier.
So what we need to do is make the whole of select_task_rq_fair()
cpu_online/active_mask aware, or give up and simply punt:
diff --git a/kernel/sched.c b/kernel/sched.c
index 1f2e99d..62df61c 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2377,6 +2377,9 @@ static int try_to_wake_up(struct task_struct *p, unsigned int state,
task_rq_unlock(rq, &flags);
cpu = p->sched_class->select_task_rq(p, SD_BALANCE_WAKE, wake_flags);
+ if (!cpu_active(cpu))
+ cpu = cpumask_any_and(&p->cpus_allowed, cpu_active_mask);
+
if (cpu != orig_cpu) {
local_irq_save(flags);
rq = cpu_rq(cpu);
Something I think Mike also tried and didn't deadlock for him..
Sachin, Mike, could you try the above snippet and verify if it does
indeed solve your respective issues?
/me prays it does, because otherwise I'm fresh out of clue...
^ permalink raw reply related
* Re: linux-next: manual merge of the cpufreq tree with the acpi tree
From: Dave Jones @ 2009-11-12 17:13 UTC (permalink / raw)
To: Thomas Renninger
Cc: Stephen Rothwell, linux-next, linux-kernel, Zhao Yakui, Len Brown
In-Reply-To: <200911120615.38067.trenn@suse.de>
On Thu, Nov 12, 2009 at 06:15:37AM -0600, Thomas Renninger wrote:
> > evaluation status to the platform") from the acpi tree and commit
> > b02d803d0fa3a395ba32bc5e5e3e7a3385ca7237 ("[CPUFREQ] Introduce bios_limit
> > per cpu cpufreq sysfs interface") from the cpufreq tree.
> First, thanks everybody for picking this up.
np, apologies for the delay.
> > By the way, Dave, Thomas, shouldn't the second version of
> > acpi_processor_get_bios_limit() in include/acpi/processor.h introduced by
> > the above cpufreq tree patch be "static inline"?
> Yes, good catch.
> Shall I send an on top fix somewhere?
Yeah, an incremental will be fine. I'll fold it into the original.
thanks,
Dave
^ permalink raw reply
* Re: linux-next: Tree for November 12 (acpi/processor.h)
From: Randy Dunlap @ 2009-11-12 17:40 UTC (permalink / raw)
To: Stephen Rothwell, lenb; +Cc: linux-next, LKML, linux-acpi
In-Reply-To: <20091112195101.63263490.sfr@canb.auug.org.au>
On Thu, 12 Nov 2009 19:51:01 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20091111:
>
> The cpufreq tree gained a conflict against the acpi tree.
when CONFIG_CPU_FREQ=n:
arch/x86/kernel/acpi/processor.o: In function `acpi_processor_get_bios_limit':
(.text+0x0): multiple definition of `acpi_processor_get_bios_limit'
arch/x86/kernel/acpi/cstate.o:(.text+0x0): first defined here
The function definition in include/apci/procssor.h needs to be "static inline"
at line 323.
---
~Randy
^ permalink raw reply
* Re: linux-next: Tree for November 12 (acpi_processor_get_bios_limit)
From: Randy Dunlap @ 2009-11-12 18:09 UTC (permalink / raw)
To: linux-next; +Cc: Stephen Rothwell, lenb, LKML, linux-acpi
In-Reply-To: <20091112094012.2ef401ad.randy.dunlap@oracle.com>
On Thu, 12 Nov 2009 09:40:12 -0800 Randy Dunlap wrote:
> On Thu, 12 Nov 2009 19:51:01 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20091111:
> >
> > The cpufreq tree gained a conflict against the acpi tree.
>
> when CONFIG_CPU_FREQ=n:
>
> arch/x86/kernel/acpi/processor.o: In function `acpi_processor_get_bios_limit':
> (.text+0x0): multiple definition of `acpi_processor_get_bios_limit'
> arch/x86/kernel/acpi/cstate.o:(.text+0x0): first defined here
>
>
> The function definition in include/apci/procssor.h needs to be "static inline"
> at line 323.
---
however, even with that fixed, when
CONFIG_CPU_FREQ=y
CONFIG_ACPI=n
CONFIG_SFI=y
CONFIG_APM=y
there is this build error:
arch/x86/kernel/cpu/cpufreq/powernow-k7.c:720: error: 'acpi_processor_get_bios_limit' undeclared here (not in a function)
---
~Randy
^ permalink raw reply
* [PATCH -next] staging/line6: fix printk formats
From: Randy Dunlap @ 2009-11-12 23:46 UTC (permalink / raw)
To: Stephen Rothwell, gregkh; +Cc: linux-next, LKML, devel
In-Reply-To: <20091112195101.63263490.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix printk format warnings in line6/pod.c; sizeof() is of type
size_t, so use %zu.
drivers/staging/line6/pod.c:581: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
drivers/staging/line6/pod.c:693: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/staging/line6/pod.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20091112.orig/drivers/staging/line6/pod.c
+++ linux-next-20091112/drivers/staging/line6/pod.c
@@ -579,7 +579,7 @@ static ssize_t pod_set_dump(struct devic
if (count != sizeof(pod->prog_data)) {
dev_err(pod->line6.ifcdev,
- "data block must be exactly %d bytes\n",
+ "data block must be exactly %zu bytes\n",
sizeof(pod->prog_data));
return -EINVAL;
}
@@ -691,7 +691,7 @@ static ssize_t pod_set_dump_buf(struct d
if (count != sizeof(pod->prog_data)) {
dev_err(pod->line6.ifcdev,
- "data block must be exactly %d bytes\n",
+ "data block must be exactly %zu bytes\n",
sizeof(pod->prog_data));
return -EINVAL;
}
^ permalink raw reply
* Re: linux-next: i7core_edac tree build failure
From: Stephen Rothwell @ 2009-11-12 23:54 UTC (permalink / raw)
To: Rusty Russell
Cc: Mauro Carvalho Chehab, linux-next, linux-kernel, Aristeu Rozanski
In-Reply-To: <200911122340.26317.rusty@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
Hi Rusty, Mauro,
On Thu, 12 Nov 2009 23:40:25 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> Yep, thanks Stephen. I can't apply this fix to my tree since that function
> isn't exported in Linus' tree. I've pulled in the ppc and sparc fixes to my
> tree though, but assume they'll go into their proper homes soon.
Yeah, the i7core_edac fix needs to stay in my tree as it is an
interaction between two trees in linux-next. The others should be
applied to the powerpc and sparc trees, as you say, since they fix the
current code in those trees.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [powerpc] Next tree Nov 2 : kernel BUG at mm/mmap.c:2135!
From: David Gibson @ 2009-11-13 1:37 UTC (permalink / raw)
To: Sachin Sant
Cc: Linux/PPC Development, Stephen Rothwell, linux-next,
Benjamin Herrenschmidt
In-Reply-To: <4AFBEE98.2070208@in.ibm.com>
On Thu, Nov 12, 2009 at 04:46:40PM +0530, Sachin Sant wrote:
> David Gibson wrote:
> >On Wed, Nov 04, 2009 at 06:08:44PM +0530, Sachin Sant wrote:
> >>Sachin Sant wrote:
> >>>Today's next tree failed to boot on a POWER 6 box with :
> >>>
> >>>------------[ cut here ]------------
> >>>kernel BUG at mm/mmap.c:2135!
> >>>Oops: Exception in kernel mode, sig: 5 [#2]
> >>>SMP NR_CPUS=1024 NUMA pSeries
> >>Problem exists with today's next as well.
> >>
> >>Likely cause for this problem seems to the following commit.
> >>If i revert this patch the machine boots fine.
> >>
> >>commit a0668cdc154e54bf0c85182e0535eea237d53146
> >>powerpc/mm: Cleanup management of kmem_caches for pagetables
> >
> >Ugh. Ok, it's not at all obvious how my patch could cause this bug.
> >Can you send your .config?
> >
> Still present in today's next.
Sorry, I've been sidetracked by other issues and have only managed to
look into this today. My initial attempts to reproduce the bug with
your config on both POWER6 and POWER5+ have failed though.
Is it possible to get the complete boot log from this system - not
just the [cut here] section around the BUG()? This should help to
determine exactly when during boot the bug is being triggered.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [powerpc] Next tree Nov 2 : kernel BUG at mm/mmap.c:2135!
From: David Gibson @ 2009-11-13 2:10 UTC (permalink / raw)
To: Sachin Sant, Linux/PPC Development, Stephen Rothwell, linux-next,
Benjamin Herrenschmidt
In-Reply-To: <20091113013729.GB18848@yookeroo.seuss>
On Fri, Nov 13, 2009 at 12:37:29PM +1100, David Gibson wrote:
> On Thu, Nov 12, 2009 at 04:46:40PM +0530, Sachin Sant wrote:
> > David Gibson wrote:
> > >On Wed, Nov 04, 2009 at 06:08:44PM +0530, Sachin Sant wrote:
> > >>Sachin Sant wrote:
> > >>>Today's next tree failed to boot on a POWER 6 box with :
> > >>>
> > >>>------------[ cut here ]------------
> > >>>kernel BUG at mm/mmap.c:2135!
> > >>>Oops: Exception in kernel mode, sig: 5 [#2]
> > >>>SMP NR_CPUS=1024 NUMA pSeries
> > >>Problem exists with today's next as well.
> > >>
> > >>Likely cause for this problem seems to the following commit.
> > >>If i revert this patch the machine boots fine.
> > >>
> > >>commit a0668cdc154e54bf0c85182e0535eea237d53146
> > >>powerpc/mm: Cleanup management of kmem_caches for pagetables
> > >
> > >Ugh. Ok, it's not at all obvious how my patch could cause this bug.
> > >Can you send your .config?
> > >
> > Still present in today's next.
>
> Sorry, I've been sidetracked by other issues and have only managed to
> look into this today. My initial attempts to reproduce the bug with
> your config on both POWER6 and POWER5+ have failed though.
>
> Is it possible to get the complete boot log from this system - not
> just the [cut here] section around the BUG()? This should help to
> determine exactly when during boot the bug is being triggered.
Also, could you try booting the kernel with the patch below, which
should give a bit more information about the problem.
Index: working-2.6/mm/mmap.c
===================================================================
--- working-2.6.orig/mm/mmap.c 2009-11-13 13:08:29.000000000 +1100
+++ working-2.6/mm/mmap.c 2009-11-13 13:09:26.000000000 +1100
@@ -2136,6 +2136,8 @@ void exit_mmap(struct mm_struct *mm)
while (vma)
vma = remove_vma(vma);
+ if (nr_ptes != 0)
+ printk("exit_mmap(): mm %p nr_ptes %d\n", mm, mm->nr_ptes);
BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox