* Re: Next June 29: Boot failure with SLQB on s390
From: Sachin Sant @ 2009-06-30 10:56 UTC (permalink / raw)
To: Nick Piggin
Cc: Heiko Carstens, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090630083410.GA1114@wotan.suse.de>
Nick Piggin wrote:
> If you are not seeing any extra messages from the patch, then it
> could be that you are seeing ZERO_SIZE_PTR or similar errors as
> well. I will ask if you can try the patch I sent in the other
> thread.
Still facing same problem after applying the patch you mentioned.
Probably the s390 issue is different that the Power6 issue.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Nick Piggin @ 2009-06-30 10:29 UTC (permalink / raw)
To: Heiko Carstens
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090630100929.GA2559@osiris.boeblingen.de.ibm.com>
On Tue, Jun 30, 2009 at 12:09:29PM +0200, Heiko Carstens wrote:
> On Tue, Jun 30, 2009 at 11:06:31AM +0200, Nick Piggin wrote:
> > On Mon, Jun 29, 2009 at 04:12:34PM +0200, Heiko Carstens wrote:
> > > slqb returns ZERO_SIZE_PTR instead of NULL for large size requests it cannot
> > > handle.
> > > The patch below would fix it. But I think its too ugly. So I leave it up to
> > > Nick to come up with a real and nice patch ;)
> >
> > Could you try this patch and see if it helps? (it fixes a number
> > of simple corner cases here, *blush*)
>
> Yes, it does work now. Thanks!
Thanks. Pekka, can you please merge this with
Signed-off-by: Nick Piggin <npiggin@suse.de>
>
> > SLQB: fix allocation size checking
> >
> > SLQB would return ZERO_SIZE_PTR rather than NULL if the requested size is too
> > large. Debugged by Heiko Carstens. Fix this by checking size edge cases up
> > front rather than in the slab index calculation.
> >
> > Additionally, if the size parameter was non-constant and too large, then
> > the checks may not have been performed at all which could cause corruption.
> >
> > Next, ARCH_KMALLOC_MINALIGN may not be obeyed if size is non-constant. So
> > test for KMALLOC_MIN_SIZE in that case.
> >
> > Finally, if KMALLOC_SHIFT_SLQB_HIGH is larger than 2MB, then kmalloc_index
> > could silently run off the end of its precomputed table and return a -1
> > index into the kmalloc slab array, which could result in corruption. Extend
> > this to allow up to 32MB (to match SLAB), and add a compile-time error in
> > the case that the table is exceeded (also like SLAB).
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Heiko Carstens @ 2009-06-30 10:09 UTC (permalink / raw)
To: Nick Piggin
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090630090631.GB1114@wotan.suse.de>
On Tue, Jun 30, 2009 at 11:06:31AM +0200, Nick Piggin wrote:
> On Mon, Jun 29, 2009 at 04:12:34PM +0200, Heiko Carstens wrote:
> > slqb returns ZERO_SIZE_PTR instead of NULL for large size requests it cannot
> > handle.
> > The patch below would fix it. But I think its too ugly. So I leave it up to
> > Nick to come up with a real and nice patch ;)
>
> Could you try this patch and see if it helps? (it fixes a number
> of simple corner cases here, *blush*)
Yes, it does work now. Thanks!
> SLQB: fix allocation size checking
>
> SLQB would return ZERO_SIZE_PTR rather than NULL if the requested size is too
> large. Debugged by Heiko Carstens. Fix this by checking size edge cases up
> front rather than in the slab index calculation.
>
> Additionally, if the size parameter was non-constant and too large, then
> the checks may not have been performed at all which could cause corruption.
>
> Next, ARCH_KMALLOC_MINALIGN may not be obeyed if size is non-constant. So
> test for KMALLOC_MIN_SIZE in that case.
>
> Finally, if KMALLOC_SHIFT_SLQB_HIGH is larger than 2MB, then kmalloc_index
> could silently run off the end of its precomputed table and return a -1
> index into the kmalloc slab array, which could result in corruption. Extend
> this to allow up to 32MB (to match SLAB), and add a compile-time error in
> the case that the table is exceeded (also like SLAB).
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Pekka Enberg @ 2009-06-30 9:30 UTC (permalink / raw)
To: Nick Piggin
Cc: Heiko Carstens, Sachin Sant, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090630092704.GE1114@wotan.suse.de>
On Tue, 2009-06-30 at 11:06 +0200, Nick Piggin wrote:
> > > Finally, if KMALLOC_SHIFT_SLQB_HIGH is larger than 2MB, then kmalloc_index
> > > could silently run off the end of its precomputed table and return a -1
> > > index into the kmalloc slab array, which could result in corruption. Extend
> > > this to allow up to 32MB (to match SLAB), and add a compile-time error in
> > > the case that the table is exceeded (also like SLAB).
On Tue, Jun 30, 2009 at 12:20:10PM +0300, Pekka Enberg wrote:
> > I wonder if SLQB should just do page allocator pass-through for really
> > big allocations? That way callers don't need to worry about whether
> > they're running under SLAB/SLUB/SLOB/SQLB.
On Tue, 2009-06-30 at 11:27 +0200, Nick Piggin wrote:
> Well it could, OTOH it should be pretty well in line with SLAB
> after this patch so I don't see much need.
True. But with page allocator fall-through, we don't need to bump up
slab limit to 32 MB (which is pretty damn big IMHO). Anyway, up to you,
really.
Pekka
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Nick Piggin @ 2009-06-30 9:27 UTC (permalink / raw)
To: Pekka Enberg
Cc: Heiko Carstens, Sachin Sant, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <1246353610.8014.18.camel@penberg-laptop>
On Tue, Jun 30, 2009 at 12:20:10PM +0300, Pekka Enberg wrote:
> On Tue, 2009-06-30 at 11:06 +0200, Nick Piggin wrote:
> > Finally, if KMALLOC_SHIFT_SLQB_HIGH is larger than 2MB, then kmalloc_index
> > could silently run off the end of its precomputed table and return a -1
> > index into the kmalloc slab array, which could result in corruption. Extend
> > this to allow up to 32MB (to match SLAB), and add a compile-time error in
> > the case that the table is exceeded (also like SLAB).
>
> I wonder if SLQB should just do page allocator pass-through for really
> big allocations? That way callers don't need to worry about whether
> they're running under SLAB/SLUB/SLOB/SQLB.
Well it could, OTOH it should be pretty well in line with SLAB
after this patch so I don't see much need.
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Pekka Enberg @ 2009-06-30 9:20 UTC (permalink / raw)
To: Nick Piggin
Cc: Heiko Carstens, Sachin Sant, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090630090631.GB1114@wotan.suse.de>
On Tue, 2009-06-30 at 11:06 +0200, Nick Piggin wrote:
> Finally, if KMALLOC_SHIFT_SLQB_HIGH is larger than 2MB, then kmalloc_index
> could silently run off the end of its precomputed table and return a -1
> index into the kmalloc slab array, which could result in corruption. Extend
> this to allow up to 32MB (to match SLAB), and add a compile-time error in
> the case that the table is exceeded (also like SLAB).
I wonder if SLQB should just do page allocator pass-through for really
big allocations? That way callers don't need to worry about whether
they're running under SLAB/SLUB/SLOB/SQLB.
Pekka
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Nick Piggin @ 2009-06-30 9:06 UTC (permalink / raw)
To: Heiko Carstens
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629141234.GF9321@osiris.boeblingen.de.ibm.com>
On Mon, Jun 29, 2009 at 04:12:34PM +0200, Heiko Carstens wrote:
> slqb returns ZERO_SIZE_PTR instead of NULL for large size requests it cannot
> handle.
> The patch below would fix it. But I think its too ugly. So I leave it up to
> Nick to come up with a real and nice patch ;)
Could you try this patch and see if it helps? (it fixes a number
of simple corner cases here, *blush*)
--
SLQB: fix allocation size checking
SLQB would return ZERO_SIZE_PTR rather than NULL if the requested size is too
large. Debugged by Heiko Carstens. Fix this by checking size edge cases up
front rather than in the slab index calculation.
Additionally, if the size parameter was non-constant and too large, then
the checks may not have been performed at all which could cause corruption.
Next, ARCH_KMALLOC_MINALIGN may not be obeyed if size is non-constant. So
test for KMALLOC_MIN_SIZE in that case.
Finally, if KMALLOC_SHIFT_SLQB_HIGH is larger than 2MB, then kmalloc_index
could silently run off the end of its precomputed table and return a -1
index into the kmalloc slab array, which could result in corruption. Extend
this to allow up to 32MB (to match SLAB), and add a compile-time error in
the case that the table is exceeded (also like SLAB).
---
include/linux/slqb_def.h | 17 ++++++++++-------
mm/slqb.c | 18 ++++++++++++++----
2 files changed, 24 insertions(+), 11 deletions(-)
Index: linux-2.6/include/linux/slqb_def.h
===================================================================
--- linux-2.6.orig/include/linux/slqb_def.h
+++ linux-2.6/include/linux/slqb_def.h
@@ -184,10 +184,7 @@ extern struct kmem_cache kmalloc_caches_
*/
static __always_inline int kmalloc_index(size_t size)
{
- if (unlikely(!size))
- return 0;
- if (unlikely(size > 1UL << KMALLOC_SHIFT_SLQB_HIGH))
- return 0;
+ extern int ____kmalloc_too_large(void);
if (unlikely(size <= KMALLOC_MIN_SIZE))
return KMALLOC_SHIFT_LOW;
@@ -219,7 +216,11 @@ static __always_inline int kmalloc_index
if (size <= 512 * 1024) return 19;
if (size <= 1024 * 1024) return 20;
if (size <= 2 * 1024 * 1024) return 21;
- return -1;
+ if (size <= 4 * 1024 * 1024) return 22;
+ if (size <= 8 * 1024 * 1024) return 23;
+ if (size <= 16 * 1024 * 1024) return 24;
+ if (size <= 32 * 1024 * 1024) return 25;
+ return ____kmalloc_too_large();
}
#ifdef CONFIG_ZONE_DMA
@@ -238,10 +239,12 @@ static __always_inline struct kmem_cache
{
int index;
- index = kmalloc_index(size);
- if (unlikely(index == 0))
+ if (unlikely(size > 1UL << KMALLOC_SHIFT_SLQB_HIGH))
+ return NULL;
+ if (unlikely(!size))
return ZERO_SIZE_PTR;
+ index = kmalloc_index(size);
if (likely(!(flags & SLQB_DMA)))
return &kmalloc_caches[index];
else
Index: linux-2.6/mm/slqb.c
===================================================================
--- linux-2.6.orig/mm/slqb.c
+++ linux-2.6/mm/slqb.c
@@ -2514,18 +2514,28 @@ static struct kmem_cache *get_slab(size_
{
int index;
+ if (unlikely(size <= KMALLOC_MIN_SIZE)) {
+ if (unlikely(!size))
+ return ZERO_SIZE_PTR;
+
+ index = KMALLOC_SHIFT_LOW;
+ goto got_index;
+ }
+
#if L1_CACHE_BYTES >= 128
if (size <= 128) {
#else
if (size <= 192) {
#endif
- if (unlikely(!size))
- return ZERO_SIZE_PTR;
-
index = size_index[(size - 1) / 8];
- } else
+ } else {
+ if (unlikely(size > 1UL << KMALLOC_SHIFT_SLQB_HIGH))
+ return NULL;
+
index = fls(size - 1);
+ }
+got_index:
if (unlikely((flags & SLQB_DMA)))
return &kmalloc_caches_dma[index];
else
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Nick Piggin @ 2009-06-30 8:34 UTC (permalink / raw)
To: Sachin Sant
Cc: Heiko Carstens, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <4A49A3B4.5070501@in.ibm.com>
If you are not seeing any extra messages from the patch, then it
could be that you are seeing ZERO_SIZE_PTR or similar errors as
well. I will ask if you can try the patch I sent in the other
thread.
Thanks,
Nick
On Tue, Jun 30, 2009 at 11:03:40AM +0530, Sachin Sant wrote:
> Loglevel set to 8
> Unable to handle kernel paging request for data at address 0xc0000000008f4504
> Faulting instruction address: 0xc000000000391094
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 DEBUG_PAGEALLOC NUMA pSeries
> Modules linked in: scsi_mod(+)
> NIP: c000000000391094 LR: c00000000060cd88 CTR: 0000000000000008
> REGS: c0000000c63f3590 TRAP: 0300 Not tainted (2.6.31-rc1-next-20090629)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24222428 XER: 20000001
> DAR: c0000000008f4504, DSISR: 0000000040000000
> TASK = c0000000c63e0a80[62] 'modprobe' THREAD: c0000000c63f0000 CPU: 1
> GPR00: c00000000060cd88 c0000000c63f3810 c000000000b0c488 c0000000008f4500
> GPR04: c0000000ddcd0000 0000000000000001 0000000000000000 c0000000dfff8480
> GPR08: 0000000000000001 c0000000de000010 0000000000000002 c000000000c681f8
> GPR12: 0000000024222428 c000000000be2600 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000018 ffffffffffffffff 0000000000210d00 0000000000000010
> GPR24: 0000000000210d00 c0000000dfc60ea0 c000000000fc1580 c0000000008f4500
> GPR28: c0000000008f4448 c0000000008f4500 c000000000a87bd0 c0000000dfc60e80
> NIP [c000000000391094] ._raw_spin_lock+0x30/0x184
> LR [c00000000060cd88] ._spin_lock+0x10/0x24
> Call Trace:
> [c0000000c63f38b0] [c00000000060cd88] ._spin_lock+0x10/0x24
> [c0000000c63f3920] [c000000000150030] .__slab_alloc_page+0x390/0x430
> [c0000000c63f39e0] [c0000000001518f0] .kmem_cache_alloc+0x160/0x2bc
> [c0000000c63f3aa0] [c000000000152308] .kmem_cache_create+0x294/0x2a8
> [c0000000c63f3b90] [d000000000eb177c] .scsi_init_queue+0x38/0x170 [scsi_mod]
> [c0000000c63f3c20] [d000000000eb1678] .init_scsi+0x1c/0xe8 [scsi_mod]
> [c0000000c63f3ca0] [c0000000000097a0] .do_one_initcall+0x80/0x19c
> [c0000000c63f3d90] [c0000000000c7a08] .SyS_init_module+0x118/0x28c
> [c0000000c63f3e30] [c000000000008534] syscall_exit+0x0/0x40
> Instruction dump:
> 7c0802a6 fba1ffe8 7d800026 7c7d1b78 fbc1fff0 ebc2c268 f8010010 fb61ffd8
> fb81ffe0 fbe1fff8 91810008 f821ff61 <80030004> 6c09dead 2f894ead 419e000c
> ---[ end trace e7d1b9681037bc75 ]---
^ permalink raw reply
* linux-next: Tree for June 30
From: Stephen Rothwell @ 2009-06-30 8:22 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 7349 bytes --]
Hi all,
Changes since 20090629:
New tree: sfi
Dropped tree: sfi (build problems)
My fixes tree contains this commit:
fbdev: work around old compiler bug
This tree fails to build for powerpc allyesconfig.
The pci tree gained conflicts against Linus' tree and a build failure so
I used the version from next-20090629.
The acpi tree gained a build failure for which I reverted a commit.
The kvm tree lost its conflicts and build failure.
The sfi tree gained a build failure so I dropped it for today (since I
have no previous version to go back to).
----------------------------------------------------------------------------
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/kernel/people/sfr/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 (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) 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 132 trees (counting Linus' and 19 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/usb.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 dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
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 v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl-rc6
CONFLICT (content): Merge conflict in fs/reiserfs/super.c
Merging vfs/for-next
Merging pci/linux-next
CONFLICT (content): Merge conflict in arch/ia64/include/asm/pci.h
CONFLICT (content): Merge conflict in arch/mn10300/include/asm/pci.h
CONFLICT (content): Merge conflict in include/asm-generic/pci.h
$ git reset --hard HEAD^
Merging refs/next/20090629/pci
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
$ git checkout HEAD drivers/platform/x86/eeepc-laptop.c
[master b72a127] Revert "eeepc-laptop: Register as a pci-hotplug device"
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/powerpc/platforms/powermac/setup.c
CONFLICT (content): Merge conflict in kernel/cpu.c
Applying: rr/pmac: fix for cpumask accessor changes
Applying: UML: Fix some apparent bitrot in mmu_context.h
Merging mmc/next
Merging input/next
Merging bkl-removal/bkl-removal
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
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
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
CONFLICT (content): Merge conflict in drivers/char/tty_ldisc.c
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 omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/mn10300/kernel/vmlinux.lds.S
Merging sfi/sfi-test
$ git reset --hard HEAD^
Merging asm-generic/next
Merging quilt/driver-core
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Nick Piggin @ 2009-06-30 7:34 UTC (permalink / raw)
To: Heiko Carstens
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629141234.GF9321@osiris.boeblingen.de.ibm.com>
On Mon, Jun 29, 2009 at 04:12:34PM +0200, Heiko Carstens wrote:
> slqb returns ZERO_SIZE_PTR instead of NULL for large size requests it cannot
> handle.
Ah, thank you for debugging this. Great.
> The patch below would fix it. But I think its too ugly. So I leave it up to
> Nick to come up with a real and nice patch ;)
The patch isn't so bad :) It is for the constant case anyway so it
should optimize away. But I think I have a similar problem for
the non constant case too, so I will look at doing another patch.
Thanks,
Nick
>
> diff --git a/include/linux/slqb_def.h b/include/linux/slqb_def.h
> index 7b4a601..9d03485 100644
> --- a/include/linux/slqb_def.h
> +++ b/include/linux/slqb_def.h
> @@ -187,7 +187,7 @@ static __always_inline int kmalloc_index(size_t size)
> if (unlikely(!size))
> return 0;
> if (unlikely(size > 1UL << KMALLOC_SHIFT_SLQB_HIGH))
> - return 0;
> + return -1;
>
> if (unlikely(size <= KMALLOC_MIN_SIZE))
> return KMALLOC_SHIFT_LOW;
> @@ -219,7 +219,7 @@ static __always_inline int kmalloc_index(size_t size)
> if (size <= 512 * 1024) return 19;
> if (size <= 1024 * 1024) return 20;
> if (size <= 2 * 1024 * 1024) return 21;
> - return -1;
> + return -2;
> }
>
> #ifdef CONFIG_ZONE_DMA
> @@ -239,8 +239,12 @@ static __always_inline struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags)
> int index;
>
> index = kmalloc_index(size);
> - if (unlikely(index == 0))
> - return ZERO_SIZE_PTR;
> + if (unlikely(index <= 0)) {
> + if (index == 0)
> + return ZERO_SIZE_PTR;
> + if (index == -1)
> + return NULL;
> + }
>
> if (likely(!(flags & SLQB_DMA)))
> return &kmalloc_caches[index];
^ permalink raw reply
* linux-next: sfi tree build failure
From: Stephen Rothwell @ 2009-06-30 7:19 UTC (permalink / raw)
To: sfi-devel; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
Hi all,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
In file included from include/acpi/platform/acenv.h:141,
from include/acpi/acpi.h:56,
from include/linux/acpi.h:38,
from init/main.c:27:
include/acpi/platform/aclinux.h:64:22: error: asm/acpi.h: No such file or directory
In file included from include/acpi/platform/aclinux.h:130,
from include/acpi/platform/acenv.h:141,
from include/acpi/acpi.h:56,
from include/linux/acpi.h:38,
from init/main.c:27:
include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'UINT64'
include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INT64'
include/acpi/actypes.h:910: error: expected ')' before '*' token
include/acpi/actypes.h:913: error: expected ')' before '*' token
and it went downhill from there :-(
I have dropped the sfi tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Remove 'SBC8240 Wind River' Device Driver Code
From: Subrata Modak @ 2009-06-30 5:45 UTC (permalink / raw)
To: Scott Wood, David Woodhouse
Cc: linux-kernel, Alexander Beregalov, linux-next, Jim Cromie,
Stephen Rothwell, Linuxppc-dev, carolyn.j.smith, Sachin P Sant,
Balbir Singh, Adrian Bunk
In-Reply-To: <20090626142513.10380.20811.sendpatchset@gekko-lp3.ltc.austin.ibm.com>
Scott/David,
Your say on this patch below ?
Regards--
Subrata
On Fri, 2009-06-26 at 09:25 -0500, Subrata Modak wrote:
> Hi David/Scott,
>
> Today's next tree(20090626) produced the following build error:
>
> CC [M] drivers/mtd/maps/sbc8240.o
> drivers/mtd/maps/sbc8240.c:31:1: warning: "DEBUG" redefined
> In file included from drivers/mtd/maps/sbc8240.c:23:
> include/linux/mtd/mtd.h:333:1: warning: this is the location of the previous definition
> drivers/mtd/maps/sbc8240.c: In function 'init_sbc8240_mtd':
> drivers/mtd/maps/sbc8240.c:172: warning: passing argument 1 of 'simple_map_init' from incompatible pointer type
> drivers/mtd/maps/sbc8240.c:177: error: 'struct mtd_info' has no member named 'module'
> make[3]: *** [drivers/mtd/maps/sbc8240.o] Error 1
> make[2]: *** [drivers/mtd/maps] Error 2
> make[1]: *** [drivers/mtd] Error 2
> make: *** [drivers] Error 2
>
> I remember reporting this log back in April, when you suggested in removing it:
> http://lkml.org/lkml/2009/4/21/476,
>
> >On Tue, 2009-04-21 at 15:00 -0500, Scott Wood wrote:
> >Subrata Modak wrote:
> > > This is a very old one. DoesnB4t seem to go away. Reported this earlier
> > > on 14th April:
> > > http://lkml.org/lkml/2009/4/14/483,
> > >
> > > CC [M] drivers/mtd/maps/sbc8240.o
> > > drivers/mtd/maps/sbc8240.c:31:1: warning: "DEBUG" redefined
> > > In file included from drivers/mtd/maps/sbc8240.c:23:
> > > include/linux/mtd/mtd.h:339:1: warning: this is the location of the
> > > previous definition
> > > drivers/mtd/maps/sbc8240.c: In function b\x18init_sbc8240_mtdb\x19:
> > > drivers/mtd/maps/sbc8240.c:172: error: b\x18sbc8240_mtdb\x19 undeclared (first
> > > use in this function)
> > > drivers/mtd/maps/sbc8240.c:172: error: (Each undeclared identifier is
> > > reported only once
> > > drivers/mtd/maps/sbc8240.c:172: error: for each function it appears in.)
> > > drivers/mtd/maps/sbc8240.c: In function b\x18cleanup_sbc8240_mtdb\x19:
> > > drivers/mtd/maps/sbc8240.c:233: error: b\x18sbc8240_mtdb\x19 undeclared (first
> > > use in this function)
> >
> > This looks like an arch/ppc orphan. It's not enabled by any defconfig,
> > and it doesn't look like it does anything that physmap_of can't do.
> >
> > I'd just remove it.
> >
> > -Scott
>
> I tried to gather some more info about this driver from the link
> mentioned in Kconfig:
> http://www.windriver.com/products/sbc8240/,
> without much success.
>
> If there are no issues, can you please apply this patch to remove it ?
>
> To: David Woodhouse <dwmw2@infradead.org>,
> To: Scott Wood <scottwood@freescale.com>,
> Cc: Jim Cromie <jim.cromie@gmail.com>,
> Cc: carolyn.j.smith@exgate.tek.com,
> Cc: Adrian Bunk <bunk@kernel.org>,
> Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>,
> Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
> Cc: linux-kernel <linux-kernel@vger.kernel.org>,
> Cc: Linuxppc-dev <Linuxppc-dev@ozlabs.org>,
> Cc: linux-next <linux-next@vger.kernel.org>,
> Cc: Alexander Beregalov <a.beregalov@gmail.com>
>
>
> Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
> Tested-on-PPC64-by: Subrata Modak <subrata@linux.vnet.ibm.com>
> ---
>
> diff -uprN a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> --- a/drivers/mtd/maps/Kconfig 2009-06-26 07:36:23.000000000 -0500
> +++ b/drivers/mtd/maps/Kconfig 2009-06-26 07:39:34.000000000 -0500
> @@ -284,13 +284,6 @@ config MTD_L440GX
>
> BE VERY CAREFUL.
>
> -config MTD_SBC8240
> - tristate "Flash device on SBC8240"
> - depends on MTD_JEDECPROBE && 8260
> - help
> - Flash access on the SBC8240 board from Wind River. See
> - <http://www.windriver.com/products/sbc8240/>
> -
> config MTD_TQM8XXL
> tristate "CFI Flash device mapped on TQM8XXL"
> depends on MTD_CFI && TQM8xxL
> diff -uprN a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
> --- a/drivers/mtd/maps/Makefile 2009-06-26 07:36:23.000000000 -0500
> +++ b/drivers/mtd/maps/Makefile 2009-06-26 07:40:03.000000000 -0500
> @@ -50,7 +50,6 @@ obj-$(CONFIG_MTD_UCLINUX) += uclinux.o
> obj-$(CONFIG_MTD_NETtel) += nettel.o
> obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
> obj-$(CONFIG_MTD_H720X) += h720x-flash.o
> -obj-$(CONFIG_MTD_SBC8240) += sbc8240.o
> obj-$(CONFIG_MTD_IXP4XX) += ixp4xx.o
> obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
> obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o
> diff -uprN a/drivers/mtd/maps/sbc8240.c b/drivers/mtd/maps/sbc8240.c
> --- a/drivers/mtd/maps/sbc8240.c 2009-06-26 07:36:23.000000000 -0500
> +++ b/drivers/mtd/maps/sbc8240.c 1969-12-31 18:00:00.000000000 -0600
> @@ -1,250 +0,0 @@
> -/*
> - * Handle mapping of the flash memory access routines on the SBC8240 board.
> - *
> - * Carolyn Smith, Tektronix, Inc.
> - *
> - * This code is GPLed
> - */
> -
> -/*
> - * The SBC8240 has 2 flash banks.
> - * Bank 0 is a 512 KiB AMD AM29F040B; 8 x 64 KiB sectors.
> - * It contains the U-Boot code (7 sectors) and the environment (1 sector).
> - * Bank 1 is 4 x 1 MiB AMD AM29LV800BT; 15 x 64 KiB sectors, 1 x 32 KiB sector,
> - * 2 x 8 KiB sectors, 1 x 16 KiB sectors.
> - * Both parts are JEDEC compatible.
> - */
> -
> -#include <linux/module.h>
> -#include <linux/types.h>
> -#include <linux/kernel.h>
> -#include <asm/io.h>
> -
> -#include <linux/mtd/mtd.h>
> -#include <linux/mtd/map.h>
> -#include <linux/mtd/cfi.h>
> -
> -#ifdef CONFIG_MTD_PARTITIONS
> -#include <linux/mtd/partitions.h>
> -#endif
> -
> -#define DEBUG
> -
> -#ifdef DEBUG
> -# define debugk(fmt,args...) printk(fmt ,##args)
> -#else
> -# define debugk(fmt,args...)
> -#endif
> -
> -
> -#define WINDOW_ADDR0 0xFFF00000 /* 512 KiB */
> -#define WINDOW_SIZE0 0x00080000
> -#define BUSWIDTH0 1
> -
> -#define WINDOW_ADDR1 0xFF000000 /* 4 MiB */
> -#define WINDOW_SIZE1 0x00400000
> -#define BUSWIDTH1 8
> -
> -#define MSG_PREFIX "sbc8240:" /* prefix for our printk()'s */
> -#define MTDID "sbc8240-%d" /* for mtdparts= partitioning */
> -
> -
> -static struct map_info sbc8240_map[2] = {
> - {
> - .name = "sbc8240 Flash Bank #0",
> - .size = WINDOW_SIZE0,
> - .bankwidth = BUSWIDTH0,
> - },
> - {
> - .name = "sbc8240 Flash Bank #1",
> - .size = WINDOW_SIZE1,
> - .bankwidth = BUSWIDTH1,
> - }
> -};
> -
> -#define NUM_FLASH_BANKS ARRAY_SIZE(sbc8240_map)
> -
> -/*
> - * The following defines the partition layout of SBC8240 boards.
> - *
> - * See include/linux/mtd/partitions.h for definition of the
> - * mtd_partition structure.
> - *
> - * The *_max_flash_size is the maximum possible mapped flash size
> - * which is not necessarily the actual flash size. It must correspond
> - * to the value specified in the mapping definition defined by the
> - * "struct map_desc *_io_desc" for the corresponding machine.
> - */
> -
> -#ifdef CONFIG_MTD_PARTITIONS
> -
> -static struct mtd_partition sbc8240_uboot_partitions [] = {
> - /* Bank 0 */
> - {
> - .name = "U-boot", /* U-Boot Firmware */
> - .offset = 0,
> - .size = 0x00070000, /* 7 x 64 KiB sectors */
> - .mask_flags = MTD_WRITEABLE, /* force read-only */
> - },
> - {
> - .name = "environment", /* U-Boot environment */
> - .offset = 0x00070000,
> - .size = 0x00010000, /* 1 x 64 KiB sector */
> - },
> -};
> -
> -static struct mtd_partition sbc8240_fs_partitions [] = {
> - {
> - .name = "jffs", /* JFFS filesystem */
> - .offset = 0,
> - .size = 0x003C0000, /* 4 * 15 * 64KiB */
> - },
> - {
> - .name = "tmp32",
> - .offset = 0x003C0000,
> - .size = 0x00020000, /* 4 * 32KiB */
> - },
> - {
> - .name = "tmp8a",
> - .offset = 0x003E0000,
> - .size = 0x00008000, /* 4 * 8KiB */
> - },
> - {
> - .name = "tmp8b",
> - .offset = 0x003E8000,
> - .size = 0x00008000, /* 4 * 8KiB */
> - },
> - {
> - .name = "tmp16",
> - .offset = 0x003F0000,
> - .size = 0x00010000, /* 4 * 16KiB */
> - }
> -};
> -
> -/* trivial struct to describe partition information */
> -struct mtd_part_def
> -{
> - int nums;
> - unsigned char *type;
> - struct mtd_partition* mtd_part;
> -};
> -
> -static struct mtd_info *sbc8240_mtd[NUM_FLASH_BANKS];
> -static struct mtd_part_def sbc8240_part_banks[NUM_FLASH_BANKS];
> -
> -
> -#endif /* CONFIG_MTD_PARTITIONS */
> -
> -
> -static int __init init_sbc8240_mtd (void)
> -{
> - static struct _cjs {
> - u_long addr;
> - u_long size;
> - } pt[NUM_FLASH_BANKS] = {
> - {
> - .addr = WINDOW_ADDR0,
> - .size = WINDOW_SIZE0
> - },
> - {
> - .addr = WINDOW_ADDR1,
> - .size = WINDOW_SIZE1
> - },
> - };
> -
> - int devicesfound = 0;
> - int i,j;
> -
> - for (i = 0; i < NUM_FLASH_BANKS; i++) {
> - printk (KERN_NOTICE MSG_PREFIX
> - "Probing 0x%08lx at 0x%08lx\n", pt[i].size, pt[i].addr);
> -
> - sbc8240_map[i].map_priv_1 =
> - (unsigned long) ioremap (pt[i].addr, pt[i].size);
> - if (!sbc8240_map[i].map_priv_1) {
> - printk (MSG_PREFIX "failed to ioremap\n");
> - for (j = 0; j < i; j++) {
> - iounmap((void *) sbc8240_map[j].map_priv_1);
> - sbc8240_map[j].map_priv_1 = 0;
> - }
> - return -EIO;
> - }
> - simple_map_init(&sbc8240_mtd[i]);
> -
> - sbc8240_mtd[i] = do_map_probe("jedec_probe", &sbc8240_map[i]);
> -
> - if (sbc8240_mtd[i]) {
> - sbc8240_mtd[i]->module = THIS_MODULE;
> - devicesfound++;
> - } else {
> - if (sbc8240_map[i].map_priv_1) {
> - iounmap((void *) sbc8240_map[i].map_priv_1);
> - sbc8240_map[i].map_priv_1 = 0;
> - }
> - }
> - }
> -
> - if (!devicesfound) {
> - printk(KERN_NOTICE MSG_PREFIX
> - "No suppported flash chips found!\n");
> - return -ENXIO;
> - }
> -
> -#ifdef CONFIG_MTD_PARTITIONS
> - sbc8240_part_banks[0].mtd_part = sbc8240_uboot_partitions;
> - sbc8240_part_banks[0].type = "static image";
> - sbc8240_part_banks[0].nums = ARRAY_SIZE(sbc8240_uboot_partitions);
> - sbc8240_part_banks[1].mtd_part = sbc8240_fs_partitions;
> - sbc8240_part_banks[1].type = "static file system";
> - sbc8240_part_banks[1].nums = ARRAY_SIZE(sbc8240_fs_partitions);
> -
> - for (i = 0; i < NUM_FLASH_BANKS; i++) {
> -
> - if (!sbc8240_mtd[i]) continue;
> - if (sbc8240_part_banks[i].nums == 0) {
> - printk (KERN_NOTICE MSG_PREFIX
> - "No partition info available, registering whole device\n");
> - add_mtd_device(sbc8240_mtd[i]);
> - } else {
> - printk (KERN_NOTICE MSG_PREFIX
> - "Using %s partition definition\n", sbc8240_part_banks[i].mtd_part->name);
> - add_mtd_partitions (sbc8240_mtd[i],
> - sbc8240_part_banks[i].mtd_part,
> - sbc8240_part_banks[i].nums);
> - }
> - }
> -#else
> - printk(KERN_NOTICE MSG_PREFIX
> - "Registering %d flash banks at once\n", devicesfound);
> -
> - for (i = 0; i < devicesfound; i++) {
> - add_mtd_device(sbc8240_mtd[i]);
> - }
> -#endif /* CONFIG_MTD_PARTITIONS */
> -
> - return devicesfound == 0 ? -ENXIO : 0;
> -}
> -
> -static void __exit cleanup_sbc8240_mtd (void)
> -{
> - int i;
> -
> - for (i = 0; i < NUM_FLASH_BANKS; i++) {
> - if (sbc8240_mtd[i]) {
> - del_mtd_device (sbc8240_mtd[i]);
> - map_destroy (sbc8240_mtd[i]);
> - }
> - if (sbc8240_map[i].map_priv_1) {
> - iounmap ((void *) sbc8240_map[i].map_priv_1);
> - sbc8240_map[i].map_priv_1 = 0;
> - }
> - }
> -}
> -
> -module_init (init_sbc8240_mtd);
> -module_exit (cleanup_sbc8240_mtd);
> -
> -MODULE_LICENSE ("GPL");
> -MODULE_AUTHOR ("Carolyn Smith <carolyn.smith@tektronix.com>");
> -MODULE_DESCRIPTION ("MTD map driver for SBC8240 boards");
> -
>
> ---
> Regards--
> Subrata
>
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Sachin Sant @ 2009-06-30 5:33 UTC (permalink / raw)
To: Nick Piggin
Cc: Heiko Carstens, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629103943.GA31299@wotan.suse.de>
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Nick Piggin wrote:
> This could I suppose be due to failed allocation where the caller
> isn't expecting failure (or using SLAB_PANIC).
>
> Did you manage to test with the prink debugging patch for SLQB that
> I sent for the power6 boot failure? I don't think I saw a reply from
> you but maybe I missed it?
>
Hi Nick,
Sorry for the delay in getting the debug o/p. Attaching the boot
log from the Power6 box with the debug patch, although i don't
see any extra messages .
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: boot-log --]
[-- Type: text/plain, Size: 13185 bytes --]
Using 007c5c91 bytes for initrd buffer
Please wait, loading kernel...
Allocated 01200000 bytes for kernel @ 02300000
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded 007c5c91 @ 03500000
OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 2.6.31-rc1-next-20090629 (root@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Tue Jun 30 10:31:38 IST 2009
Calling ibm,client-architecture... done
command line: root=/dev/sda3 sysrq=8 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M loglevel=8 mminit_loglevel=4
memory layout at init:
alloc_bottom : 0000000003cd0000
alloc_top : 0000000008000000
alloc_top_hi : 0000000008000000
rmo_top : 0000000008000000
ram_top : 0000000008000000
instantiating rtas at 0x00000000074e0000... done
boot cpu hw idx 0000000000000000
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000003ce0000 -> 0x0000000003ce15c2
Device tree struct 0x0000000003cf0000 -> 0x0000000003d10000
Calling quiesce...
returning from prom_init
Crash kernel location must be 0x2000000
Reserving 256MB of memory at 32MB for crashkernel (System RAM: 4096MB)
Phyp-dump disabled at boot time
Using pSeries machine description
Page orders: linear mapping = 16, virtual = 16, io = 12
Using 1TB segments
Found initrd at 0xc000000003500000:0xc000000003cc5c91
console [udbg0] enabled
Partition configured for 2 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #1 SMP Tue Jun 30 10:31:38 IST 2009
-----------------------------------------------------
ppc64_pft_size = 0x1a
physicalMemorySize = 0x100000000
htab_hash_mask = 0x7ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.31-rc1-next-20090629 (root@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Tue Jun 30 10:31:38 IST 2009
[boot]0012 Setup Arch
mminit::memory_register Entering add_active_range(2, 0x0, 0x800) 0 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x800, 0x1000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x1000, 0x1800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x1800, 0x2000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x2000, 0x2800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x2800, 0x3000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x3000, 0x3800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x3800, 0x4000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x4000, 0x4800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x4800, 0x5000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x5000, 0x5800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x5800, 0x6000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x6000, 0x6800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x6800, 0x7000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x7000, 0x7800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x7800, 0x8000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x8000, 0x8800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x8800, 0x9000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x9000, 0x9800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0x9800, 0xa000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0xa000, 0xa800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0xa800, 0xb000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0xb000, 0xb800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0xb800, 0xc000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0xc000, 0xc800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0xc800, 0xd000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0xd000, 0xd800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(2, 0xd800, 0xe000) 1 entries of 256 used
mminit::memory_register Entering add_active_range(3, 0xe000, 0xe800) 1 entries of 256 used
mminit::memory_register Entering add_active_range(3, 0xe800, 0xf000) 2 entries of 256 used
mminit::memory_register Entering add_active_range(3, 0xf000, 0xf800) 2 entries of 256 used
mminit::memory_register Entering add_active_range(3, 0xf800, 0x10000) 2 entries of 256 used
Node 0 Memory:
Node 2 Memory: 0x0-0xe0000000
Node 3 Memory: 0xe0000000-0x100000000
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Using shared processor idle loop
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal 0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
2: 0x00000000 -> 0x0000e000
3: 0x0000e000 -> 0x00010000
mminit::pageflags_layout_widths Section 20 Node 4 Zone 2 Flags 23
mminit::pageflags_layout_shifts Section 20 Node 4 Zone 2
mminit::pageflags_layout_offsets Section 44 Node 40 Zone 38
mminit::pageflags_layout_zoneid Zone ID: 38 -> 44
mminit::pageflags_layout_usage location: 64 -> 38 unused 38 -> 23 flags 23 -> 0
Could not find start_pfn for node 0
On node 0 totalpages: 0
On node 2 totalpages: 57344
DMA zone: 56 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 57288 pages, LIFO batch:1
mminit::memmap_init Initialising map node 2 zone 0 pfns 0 -> 57344
On node 3 totalpages: 8192
DMA zone: 8 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 8184 pages, LIFO batch:0
mminit::memmap_init Initialising map node 3 zone 0 pfns 57344 -> 65536
[boot]0015 Setup Done
mminit::zonelist general 2:DMA = 2:DMA 3:DMA
mminit::zonelist thisnode 2:DMA = 2:DMA
mminit::zonelist general 3:DMA = 3:DMA 2:DMA
mminit::zonelist thisnode 3:DMA = 3:DMA
Built 3 zonelists in Node order, mobility grouping on. Total pages: 65472
Policy zone: DMA
Kernel command line: root=/dev/sda3 sysrq=8 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M loglevel=8 mminit_loglevel=4
PID hash table entries: 4096 (order: 12, 32768 bytes)
freeing bootmem node 2
freeing bootmem node 3
Memory: 3897728k/4194304k available (9216k kernel code, 296576k reserved, 2112k data, 4289k bss, 512k init)
Experimental hierarchical RCU implementation.
RCU-based detection of stalled CPUs is enabled.
Experimental hierarchical RCU init done.
NR_IRQS:512
[boot]0020 XICS Init
[boot]0021 XICS Done
pic: no ISA interrupt controller
time_init: decrementer frequency = 512.000000 MHz
time_init: processor frequency = 4704.000000 MHz
clocksource: timebase mult[7d0000] shift[22] registered
clockevent: decrementer mult[83126e97] shift[32] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
allocated 2621440 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Security Framework initialized
SELinux: Disabled at boot.
Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
irq: irq 2 on host null mapped to virtual irq 16
clockevent: decrementer mult[83126e97] shift[32] cpu[1]
Processor 1 found.
Brought up 2 CPUs
Node 0 CPUs: 0-1
Node 2 CPUs:
Node 3 CPUs:
CPU0 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 0 1
domain 1: span 0-1 level NODE
groups: 0-1
CPU1 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 1 0
domain 1: span 0-1 level NODE
groups: 0-1
NET: Registered protocol family 16
IBM eBus Device Driver
POWER6 performance monitor hardware support registered
PCI: Probing PCI hardware
PCI: Probing PCI hardware done
bio: create slab <bio-0> at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 2, 262144 bytes)
TCP established hash table entries: 131072 (order: 5, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 5, 2097152 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Unpacking initramfs...
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
irq: irq 655360 on host null mapped to virtual irq 17
irq: irq 655367 on host null mapped to virtual irq 18
IOMMU table initialized, virtual merging enabled
irq: irq 589825 on host null mapped to virtual irq 19
RTAS daemon started
audit: initializing netlink socket (disabled)
type=2000 audit(1246339143.235:1): initialized
Kprobe smoke test started
Kprobe smoke test passed successfully
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 16 GB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
Btrfs loaded
msgmni has been set to 7612
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Generic RTC Driver v1.07
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Platform driver 'serial8250' needs updating - please use dev_pm_ops
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
input: Macintosh mouse button emulation as /devices/virtual/input/input0
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
IBM eHEA ethernet device driver (Release EHEA_0101)
irq: irq 590088 on host null mapped to virtual irq 264
ehea: eth0: Jumbo frames are disabled
ehea: eth0 -> logical port id #2
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
mice: PS/2 mouse device common for all mice
EDAC MC: Ver: 2.1.0 Jun 30 2009
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP cubic registered
NET: Registered protocol family 15
registered taskstats version 1
Freeing unused kernel memory: 512k freed
doing fast boot
SysRq : Changing Loglevel
Loglevel set to 8
Unable to handle kernel paging request for data at address 0xc0000000008f4504
Faulting instruction address: 0xc000000000391094
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 DEBUG_PAGEALLOC NUMA pSeries
Modules linked in: scsi_mod(+)
NIP: c000000000391094 LR: c00000000060cd88 CTR: 0000000000000008
REGS: c0000000c63f3590 TRAP: 0300 Not tainted (2.6.31-rc1-next-20090629)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24222428 XER: 20000001
DAR: c0000000008f4504, DSISR: 0000000040000000
TASK = c0000000c63e0a80[62] 'modprobe' THREAD: c0000000c63f0000 CPU: 1
GPR00: c00000000060cd88 c0000000c63f3810 c000000000b0c488 c0000000008f4500
GPR04: c0000000ddcd0000 0000000000000001 0000000000000000 c0000000dfff8480
GPR08: 0000000000000001 c0000000de000010 0000000000000002 c000000000c681f8
GPR12: 0000000024222428 c000000000be2600 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000018 ffffffffffffffff 0000000000210d00 0000000000000010
GPR24: 0000000000210d00 c0000000dfc60ea0 c000000000fc1580 c0000000008f4500
GPR28: c0000000008f4448 c0000000008f4500 c000000000a87bd0 c0000000dfc60e80
NIP [c000000000391094] ._raw_spin_lock+0x30/0x184
LR [c00000000060cd88] ._spin_lock+0x10/0x24
Call Trace:
[c0000000c63f38b0] [c00000000060cd88] ._spin_lock+0x10/0x24
[c0000000c63f3920] [c000000000150030] .__slab_alloc_page+0x390/0x430
[c0000000c63f39e0] [c0000000001518f0] .kmem_cache_alloc+0x160/0x2bc
[c0000000c63f3aa0] [c000000000152308] .kmem_cache_create+0x294/0x2a8
[c0000000c63f3b90] [d000000000eb177c] .scsi_init_queue+0x38/0x170 [scsi_mod]
[c0000000c63f3c20] [d000000000eb1678] .init_scsi+0x1c/0xe8 [scsi_mod]
[c0000000c63f3ca0] [c0000000000097a0] .do_one_initcall+0x80/0x19c
[c0000000c63f3d90] [c0000000000c7a08] .SyS_init_module+0x118/0x28c
[c0000000c63f3e30] [c000000000008534] syscall_exit+0x0/0x40
Instruction dump:
7c0802a6 fba1ffe8 7d800026 7c7d1b78 fbc1fff0 ebc2c268 f8010010 fb61ffd8
fb81ffe0 fbe1fff8 91810008 f821ff61 <80030004> 6c09dead 2f894ead 419e000c
---[ end trace e7d1b9681037bc75 ]---
^ permalink raw reply
* linux-next: acpi tree build failure
From: Stephen Rothwell @ 2009-06-30 3:16 UTC (permalink / raw)
To: Len Brown; +Cc: linux-next, linux-kernel, Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
Hi Len,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
GEN /scratch/sfr/powerpc_ppc64_defconfig/Makefile
drivers/platform/x86/Kconfig:353:error: found recursive dependency: EEEPC_LAPTOP -> HOTPLUG_PCI -> EEEPC_LAPTOP
Caused by commit 6af05c22969dce2776375953131b56e9f4282848 ("eeepc-laptop:
Register as a pci-hotplug device") interacting with commit
44b3615b8cb3b016a49eb7ef4236e77a77793cec ("eeepc-laptop: Fix build
failure with HOTPLUG_PCI && !SYSFS") from Linus' tree. Commit 6af05c2
from the acpi tree is the same as commit
2b121bc262fa03c94e653b2d44356c2f86c1bcdc in Linus' tree that 44b3615b is
fixing, so I have reverted the drivers/platform/x86/Kconfig part of
6af05c2 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: pci tree build failure
From: Matthew Wilcox @ 2009-06-30 2:24 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20090629191324.5c86bbc0@jbarnes-g45>
On Mon, Jun 29, 2009 at 07:13:24PM -0700, Jesse Barnes wrote:
> On Tue, 30 Jun 2009 12:07:27 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Jesse,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > ERROR: "pci_claim_resource" [drivers/pcmcia/yenta_socket.ko]
> > undefined!
> >
> > Caused by commit 6bb04b65dbff5a5bb01617351dbb0af577084752 ("yenta: Use
> > pci_claim_resource"). yenta can be built as a module, but
> > pci_claim_resource is not exported ...
> >
> > I have used the pci tree from next-20090629 for today.
>
> Damn, thought I built that. linux-next earns its keep yet again.
Sorry about that. I thought I'd checked that. Must have been confused
with another function. There do seem to be legitimate *drivers*
that could use it (i2o for one), so I propose making it a full-bodied
'EXPORT_SYMBOL' and not bother with the _GPL tag. Thoughts?
^ permalink raw reply
* Re: linux-next: manual merge of the pci tree with Linus' tree
From: Matthew Wilcox @ 2009-06-30 2:16 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Stephen Rothwell, linux-next, linux-kernel, Alex Chiang
In-Reply-To: <20090629190135.7ff6a089@jbarnes-g45>
On Mon, Jun 29, 2009 at 07:01:35PM -0700, Jesse Barnes wrote:
> On Tue, 30 Jun 2009 11:56:38 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Jesse,
> >
> > Today's linux-next merge of the pci tree got conflicts in
> > arch/ia64/include/asm/pci.h, arch/mn10300/include/asm/pci.h and
> > include/asm-generic/pci.h between commit
> > a6c140969b4685f9b9f6773c0760f55ca66d1825 ("Delete
> > pcibios_select_root") from Linus' tree and commit
> > a53cd7419b22c14b5a1e6859a940fb6bfa77963f ("PCI: remove
> > pcibios_scan_all_fns()") from the pci tree.
> >
> > Just context changes (adjacent removals). I fixed it up (see below)
> > and can carry the fix for a while.
>
> Ah ok, thanks. That'll get fixed up after I send the current for-linus
> bits over and refresh my PCI tree.
I think you need to pull from Linus' tree before you send the bits over
-- that's a conflict between Linus' tree and your tree, and you don't
want to annoy Linus by making him merge them ;-)
^ permalink raw reply
* Re: linux-next: pci tree build failure
From: Jesse Barnes @ 2009-06-30 2:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Matthew Wilcox
In-Reply-To: <20090630120727.24450bab.sfr@canb.auug.org.au>
On Tue, 30 Jun 2009 12:07:27 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Jesse,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> ERROR: "pci_claim_resource" [drivers/pcmcia/yenta_socket.ko]
> undefined!
>
> Caused by commit 6bb04b65dbff5a5bb01617351dbb0af577084752 ("yenta: Use
> pci_claim_resource"). yenta can be built as a module, but
> pci_claim_resource is not exported ...
>
> I have used the pci tree from next-20090629 for today.
Damn, thought I built that. linux-next earns its keep yet again.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* linux-next: pci tree build failure
From: Stephen Rothwell @ 2009-06-30 2:07 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-next, linux-kernel, Matthew Wilcox
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Hi Jesse,
Today's linux-next build (x86_64 allmodconfig) failed like this:
ERROR: "pci_claim_resource" [drivers/pcmcia/yenta_socket.ko] undefined!
Caused by commit 6bb04b65dbff5a5bb01617351dbb0af577084752 ("yenta: Use
pci_claim_resource"). yenta can be built as a module, but
pci_claim_resource is not exported ...
I have used the pci tree from next-20090629 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the pci tree with Linus' tree
From: Jesse Barnes @ 2009-06-30 2:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Matthew Wilcox, Alex Chiang
In-Reply-To: <20090630115638.7bfb8e21.sfr@canb.auug.org.au>
On Tue, 30 Jun 2009 11:56:38 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Jesse,
>
> Today's linux-next merge of the pci tree got conflicts in
> arch/ia64/include/asm/pci.h, arch/mn10300/include/asm/pci.h and
> include/asm-generic/pci.h between commit
> a6c140969b4685f9b9f6773c0760f55ca66d1825 ("Delete
> pcibios_select_root") from Linus' tree and commit
> a53cd7419b22c14b5a1e6859a940fb6bfa77963f ("PCI: remove
> pcibios_scan_all_fns()") from the pci tree.
>
> Just context changes (adjacent removals). I fixed it up (see below)
> and can carry the fix for a while.
Ah ok, thanks. That'll get fixed up after I send the current for-linus
bits over and refresh my PCI tree.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* linux-next: manual merge of the pci tree with Linus' tree
From: Stephen Rothwell @ 2009-06-30 1:56 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-next, linux-kernel, Matthew Wilcox, Alex Chiang
Hi Jesse,
Today's linux-next merge of the pci tree got conflicts in
arch/ia64/include/asm/pci.h, arch/mn10300/include/asm/pci.h and
include/asm-generic/pci.h between commit
a6c140969b4685f9b9f6773c0760f55ca66d1825 ("Delete pcibios_select_root")
from Linus' tree and commit a53cd7419b22c14b5a1e6859a940fb6bfa77963f
("PCI: remove pcibios_scan_all_fns()") from the pci tree.
Just context changes (adjacent removals). I fixed it up (see below) and
can carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/ia64/include/asm/pci.h
index fcfca56,55281aa..0000000
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
@@@ -135,7 -134,18 +134,6 @@@ extern void pcibios_resource_to_bus(str
extern void pcibios_bus_to_resource(struct pci_dev *dev,
struct resource *res, struct pci_bus_region *region);
- #define pcibios_scan_all_fns(a, b) 0
-static inline struct resource *
-pcibios_select_root(struct pci_dev *pdev, struct resource *res)
-{
- struct resource *root = NULL;
-
- if (res->flags & IORESOURCE_IO)
- root = &ioport_resource;
- if (res->flags & IORESOURCE_MEM)
- root = &iomem_resource;
-
- return root;
-}
#define HAVE_ARCH_PCI_GET_LEGACY_IDE_IRQ
static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
diff --cc arch/mn10300/include/asm/pci.h
index 35d2ed6,de52a27..0000000
--- a/arch/mn10300/include/asm/pci.h
+++ b/arch/mn10300/include/asm/pci.h
@@@ -102,7 -106,18 +102,6 @@@ extern void pcibios_bus_to_resource(str
struct resource *res,
struct pci_bus_region *region);
- #define pcibios_scan_all_fns(a, b) 0
-static inline struct resource *
-pcibios_select_root(struct pci_dev *pdev, struct resource *res)
-{
- struct resource *root = NULL;
-
- if (res->flags & IORESOURCE_IO)
- root = &ioport_resource;
- if (res->flags & IORESOURCE_MEM)
- root = &iomem_resource;
-
- return root;
-}
static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
{
diff --cc include/asm-generic/pci.h
index b4326b5,095cca8..0000000
--- a/include/asm-generic/pci.h
+++ b/include/asm-generic/pci.h
@@@ -30,7 -30,18 +30,6 @@@ pcibios_bus_to_resource(struct pci_dev
res->end = region->end;
}
- #define pcibios_scan_all_fns(a, b) 0
-static inline struct resource *
-pcibios_select_root(struct pci_dev *pdev, struct resource *res)
-{
- struct resource *root = NULL;
-
- if (res->flags & IORESOURCE_IO)
- root = &ioport_resource;
- if (res->flags & IORESOURCE_MEM)
- root = &iomem_resource;
-
- return root;
-}
#ifndef HAVE_ARCH_PCI_GET_LEGACY_IDE_IRQ
static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Heiko Carstens @ 2009-06-29 14:12 UTC (permalink / raw)
To: Nick Piggin
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629115835.GA2308@wotan.suse.de>
On Mon, Jun 29, 2009 at 01:58:35PM +0200, Nick Piggin wrote:
> n Mon, Jun 29, 2009 at 01:50:38PM +0200, Heiko Carstens wrote:
> > On Mon, Jun 29, 2009 at 12:39:43PM +0200, Nick Piggin wrote:
> > > On Mon, Jun 29, 2009 at 12:31:23PM +0200, Heiko Carstens wrote:
> > > > On Mon, Jun 29, 2009 at 03:14:40PM +0530, Sachin Sant wrote:
> > > > > I still have problems booting next with SLQB on a s390 box.
> > > > >
> > > > > Write protected kernel read-only data: 0x12000 - 0x446fff
> > > > > Experimental hierarchical RCU implementation.
> > > > > Experimental hierarchical RCU init done.
> > > > > console ÝttyS0¨ enabled
> > > > > Unable to handle kernel pointer dereference at virtual kernel address (null)
> > >
> > > This could I suppose be due to failed allocation where the caller
> > > isn't expecting failure (or using SLAB_PANIC).
> > >
> > > Did you manage to test with the prink debugging patch for SLQB that
> > > I sent for the power6 boot failure? I don't think I saw a reply from
> > > you but maybe I missed it?
> >
> > Could you send me the debug patch as well? I can give it a quick run as well.
>
> This is what I had. It is only helpful for the power6
> failure where there was a problem in an allocation from
> kmem_cache_create.
slqb returns ZERO_SIZE_PTR instead of NULL for large size requests it cannot
handle.
The patch below would fix it. But I think its too ugly. So I leave it up to
Nick to come up with a real and nice patch ;)
diff --git a/include/linux/slqb_def.h b/include/linux/slqb_def.h
index 7b4a601..9d03485 100644
--- a/include/linux/slqb_def.h
+++ b/include/linux/slqb_def.h
@@ -187,7 +187,7 @@ static __always_inline int kmalloc_index(size_t size)
if (unlikely(!size))
return 0;
if (unlikely(size > 1UL << KMALLOC_SHIFT_SLQB_HIGH))
- return 0;
+ return -1;
if (unlikely(size <= KMALLOC_MIN_SIZE))
return KMALLOC_SHIFT_LOW;
@@ -219,7 +219,7 @@ static __always_inline int kmalloc_index(size_t size)
if (size <= 512 * 1024) return 19;
if (size <= 1024 * 1024) return 20;
if (size <= 2 * 1024 * 1024) return 21;
- return -1;
+ return -2;
}
#ifdef CONFIG_ZONE_DMA
@@ -239,8 +239,12 @@ static __always_inline struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags)
int index;
index = kmalloc_index(size);
- if (unlikely(index == 0))
- return ZERO_SIZE_PTR;
+ if (unlikely(index <= 0)) {
+ if (index == 0)
+ return ZERO_SIZE_PTR;
+ if (index == -1)
+ return NULL;
+ }
if (likely(!(flags & SLQB_DMA)))
return &kmalloc_caches[index];
^ permalink raw reply related
* Re: Next June 29: Boot failure with SLQB on s390
From: Heiko Carstens @ 2009-06-29 13:09 UTC (permalink / raw)
To: Nick Piggin
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629115835.GA2308@wotan.suse.de>
> > > > > Unable to handle kernel pointer dereference at virtual kernel address (null)
> > >
> > > This could I suppose be due to failed allocation where the caller
> > > isn't expecting failure (or using SLAB_PANIC).
> > >
> > > Did you manage to test with the prink debugging patch for SLQB that
> > > I sent for the power6 boot failure? I don't think I saw a reply from
> > > you but maybe I missed it?
> >
> > Could you send me the debug patch as well? I can give it a quick run as well.
>
> This is what I had. It is only helpful for the power6
> failure where there was a problem in an allocation from
> kmem_cache_create.
It doesn't print anything out to the console. kmalloc_node returns 0x10 for
the large allocation in init_section_page_cgroup().
The page allocator won't be able to satisfy this request since the requested
order is larger than MAX_ORDER on our platform.
Now we only need to figure out why the SLQB allocator returns 0x10 instead
of NULL ;)
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Nick Piggin @ 2009-06-29 11:58 UTC (permalink / raw)
To: Heiko Carstens
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629115038.GD9321@osiris.boeblingen.de.ibm.com>
n Mon, Jun 29, 2009 at 01:50:38PM +0200, Heiko Carstens wrote:
> On Mon, Jun 29, 2009 at 12:39:43PM +0200, Nick Piggin wrote:
> > On Mon, Jun 29, 2009 at 12:31:23PM +0200, Heiko Carstens wrote:
> > > On Mon, Jun 29, 2009 at 03:14:40PM +0530, Sachin Sant wrote:
> > > > I still have problems booting next with SLQB on a s390 box.
> > > >
> > > > Write protected kernel read-only data: 0x12000 - 0x446fff
> > > > Experimental hierarchical RCU implementation.
> > > > Experimental hierarchical RCU init done.
> > > > console ÝttyS0¨ enabled
> > > > Unable to handle kernel pointer dereference at virtual kernel address (null)
> >
> > This could I suppose be due to failed allocation where the caller
> > isn't expecting failure (or using SLAB_PANIC).
> >
> > Did you manage to test with the prink debugging patch for SLQB that
> > I sent for the power6 boot failure? I don't think I saw a reply from
> > you but maybe I missed it?
>
> Could you send me the debug patch as well? I can give it a quick run as well.
This is what I had. It is only helpful for the power6
failure where there was a problem in an allocation from
kmem_cache_create.
---
mm/slqb.c | 40 ++++++++++++++++++++++++++++++++++------
1 file changed, 34 insertions(+), 6 deletions(-)
Index: linux-2.6/mm/slqb.c
===================================================================
--- linux-2.6.orig/mm/slqb.c
+++ linux-2.6/mm/slqb.c
@@ -1456,7 +1456,7 @@ static void *__remote_slab_alloc_node(st
}
static noinline void *__remote_slab_alloc(struct kmem_cache *s,
- gfp_t gfpflags, int node)
+ gfp_t gfpflags, int node, int trace)
{
void *object;
struct zonelist *zonelist;
@@ -1465,19 +1465,32 @@ static noinline void *__remote_slab_allo
enum zone_type high_zoneidx = gfp_zone(gfpflags);
object = __remote_slab_alloc_node(s, gfpflags, node);
+ if (trace && !object)
+ printk("__remote_slab_alloc_node(node:%d) failed\n", node);
if (likely(object || (gfpflags & __GFP_THISNODE)))
return object;
- zonelist = node_zonelist(slab_node(current->mempolicy), gfpflags);
+ node = slab_node(current->mempolicy);
+ if (trace)
+ printk("slab_node(current->mempolicy) = %d\n", node);
+
+ zonelist = node_zonelist(node, gfpflags);
for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
- if (!cpuset_zone_allowed_hardwall(zone, gfpflags))
+ if (!cpuset_zone_allowed_hardwall(zone, gfpflags)) {
+ if (trace)
+ printk("cpuset not allowed node:%d\n", zone_to_nid(zone));
continue;
+ }
node = zone_to_nid(zone);
object = __remote_slab_alloc_node(s, gfpflags, node);
if (likely(object))
return object;
+ if (trace)
+ printk("__remote_slab_alloc_node(node:%d) failed\n", node);
}
+ if (trace)
+ printk("__remote_slab_alloc failed\n");
return NULL;
}
#endif
@@ -1488,7 +1501,7 @@ static noinline void *__remote_slab_allo
* Must be called with interrupts disabled.
*/
static __always_inline void *__slab_alloc(struct kmem_cache *s,
- gfp_t gfpflags, int node)
+ gfp_t gfpflags, int node, int trace)
{
void *object;
struct kmem_cache_cpu *c;
@@ -1497,7 +1510,7 @@ static __always_inline void *__slab_allo
#ifdef CONFIG_NUMA
if (unlikely(node != -1) && unlikely(node != numa_node_id())) {
try_remote:
- return __remote_slab_alloc(s, gfpflags, node);
+ return __remote_slab_alloc(s, gfpflags, node, trace);
}
#endif
@@ -1509,6 +1522,8 @@ try_remote:
object = cache_list_get_page(s, l);
if (unlikely(!object)) {
object = __slab_alloc_page(s, gfpflags, node);
+ if (trace && !object)
+ printk("__slab_alloc_page(node:%d) failed\n", node);
#ifdef CONFIG_NUMA
if (unlikely(!object)) {
node = numa_node_id();
@@ -1532,10 +1547,11 @@ static __always_inline void *slab_alloc(
{
void *object;
unsigned long flags;
+ int trace = 0;
again:
local_irq_save(flags);
- object = __slab_alloc(s, gfpflags, node);
+ object = __slab_alloc(s, gfpflags, node, trace);
local_irq_restore(flags);
if (unlikely(slab_debug(s)) && likely(object)) {
@@ -1546,6 +1562,18 @@ again:
if (unlikely(gfpflags & __GFP_ZERO) && likely(object))
memset(object, 0, s->objsize);
+ if (!object && !trace) {
+ trace = 1;
+ dump_stack();
+ printk("slab_alloc allocation failed\n");
+ printk("slab:%s flags:%x node:%d\n", s->name, gfpflags, node);
+ goto again;
+ }
+ if (trace) {
+ if (object)
+ printk("slab_alloc allocation worked when being traced, bugger\n");
+ }
+
return object;
}
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Heiko Carstens @ 2009-06-29 11:50 UTC (permalink / raw)
To: Nick Piggin
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629103943.GA31299@wotan.suse.de>
On Mon, Jun 29, 2009 at 12:39:43PM +0200, Nick Piggin wrote:
> On Mon, Jun 29, 2009 at 12:31:23PM +0200, Heiko Carstens wrote:
> > On Mon, Jun 29, 2009 at 03:14:40PM +0530, Sachin Sant wrote:
> > > I still have problems booting next with SLQB on a s390 box.
> > >
> > > Write protected kernel read-only data: 0x12000 - 0x446fff
> > > Experimental hierarchical RCU implementation.
> > > Experimental hierarchical RCU init done.
> > > console ÝttyS0¨ enabled
> > > Unable to handle kernel pointer dereference at virtual kernel address (null)
>
> This could I suppose be due to failed allocation where the caller
> isn't expecting failure (or using SLAB_PANIC).
>
> Did you manage to test with the prink debugging patch for SLQB that
> I sent for the power6 boot failure? I don't think I saw a reply from
> you but maybe I missed it?
Could you send me the debug patch as well? I can give it a quick run as well.
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Nick Piggin @ 2009-06-29 10:39 UTC (permalink / raw)
To: Heiko Carstens
Cc: Sachin Sant, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090629103123.GC9321@osiris.boeblingen.de.ibm.com>
On Mon, Jun 29, 2009 at 12:31:23PM +0200, Heiko Carstens wrote:
> On Mon, Jun 29, 2009 at 03:14:40PM +0530, Sachin Sant wrote:
> > I still have problems booting next with SLQB on a s390 box.
> >
> > Write protected kernel read-only data: 0x12000 - 0x446fff
> > Experimental hierarchical RCU implementation.
> > Experimental hierarchical RCU init done.
> > console ÝttyS0¨ enabled
> > Unable to handle kernel pointer dereference at virtual kernel address (null)
This could I suppose be due to failed allocation where the caller
isn't expecting failure (or using SLAB_PANIC).
Did you manage to test with the prink debugging patch for SLQB that
I sent for the power6 boot failure? I don't think I saw a reply from
you but maybe I missed it?
Thanks,
Nick
^ 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