* [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
@ 2005-09-12 14:37 Tomasz Kłoczko
2005-09-12 14:45 ` [Aurora-sparc-devel] " Tom 'spot' Callaway
2005-09-12 23:13 ` David S. Miller
0 siblings, 2 replies; 10+ messages in thread
From: Tomasz Kłoczko @ 2005-09-12 14:37 UTC (permalink / raw)
To: linux-kernel; +Cc: David S. Miller, sparclinux, Aurora development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1620 bytes --]
Hardware: Sun E250 SMP (2x400MHz), 1.5GB RAM.
Kernel: 2.6.12-1.1505sp3 (from Aurora corona repo).
On first it looks like stack or buffer-cache corruption.
Slab corruption: (Not tainted) start=fffff8005d9be708, len=808
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [destroy_inode+100/144](destroy_inode+0x64/0x90)
Call Trace:
[00000000004759f4] free_block+0x160/0x1b4
[0000000000475bb8] cache_flusharray+0x98/0x128
[0000000000475704] kmem_cache_free+0x68/0x94
[00000000004a56c4] destroy_inode+0x64/0x90
[00000000004a68f4] dispose_list+0xf0/0x12c
[00000000004a6af8] shrink_icache_memory+0x1c8/0x22c
[0000000000478c74] shrink_slab+0xc8/0x148
[000000000047a298] kswapd+0x2ec/0x42c
[0000000000415800] kernel_thread+0x30/0x48
[0000000000714dc8] kswapd_init+0x24/0x6c
090: 6b 6b 6b 6b 6b 6b 6b 6b ff ff f8 00 5d 17 61 50
Prev obj: start=fffff8005d9be3c8, len=808
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [destroy_inode+100/144](destroy_inode+0x64/0x90)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=fffff8005d9bea48, len=808
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [destroy_inode+100/144](destroy_inode+0x64/0x90)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Aurora-sparc-devel] [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-12 14:37 [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption) Tomasz Kłoczko
@ 2005-09-12 14:45 ` Tom 'spot' Callaway
2005-09-12 15:39 ` Tomasz Kłoczko
2005-09-12 20:41 ` David S. Miller
2005-09-12 23:13 ` David S. Miller
1 sibling, 2 replies; 10+ messages in thread
From: Tom 'spot' Callaway @ 2005-09-12 14:45 UTC (permalink / raw)
To: Aurora development; +Cc: linux-kernel, David S. Miller, sparclinux
On Mon, 2005-09-12 at 16:37 +0200, Tomasz Kłoczko wrote:
> Hardware: Sun E250 SMP (2x400MHz), 1.5GB RAM.
> Kernel: 2.6.12-1.1505sp3 (from Aurora corona repo).
>
> On first it looks like stack or buffer-cache corruption.
>
> Slab corruption: (Not tainted) start=fffff8005d9be708, len=808
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [destroy_inode+100/144](destroy_inode+0x64/0x90)
> Call Trace:
> [00000000004759f4] free_block+0x160/0x1b4
> [0000000000475bb8] cache_flusharray+0x98/0x128
> [0000000000475704] kmem_cache_free+0x68/0x94
> [00000000004a56c4] destroy_inode+0x64/0x90
> [00000000004a68f4] dispose_list+0xf0/0x12c
> [00000000004a6af8] shrink_icache_memory+0x1c8/0x22c
> [0000000000478c74] shrink_slab+0xc8/0x148
> [000000000047a298] kswapd+0x2ec/0x42c
> [0000000000415800] kernel_thread+0x30/0x48
> [0000000000714dc8] kswapd_init+0x24/0x6c
> 090: 6b 6b 6b 6b 6b 6b 6b 6b ff ff f8 00 5d 17 61 50
> Prev obj: start=fffff8005d9be3c8, len=808
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [destroy_inode+100/144](destroy_inode+0x64/0x90)
> 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> Next obj: start=fffff8005d9bea48, len=808
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [destroy_inode+100/144](destroy_inode+0x64/0x90)
> 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
We've been seeing this intermittently on arthur since Aurora 1.0 (2.4).
~spot
--
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Aurora-sparc-devel] [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-12 14:45 ` [Aurora-sparc-devel] " Tom 'spot' Callaway
@ 2005-09-12 15:39 ` Tomasz Kłoczko
2005-09-12 20:41 ` David S. Miller
1 sibling, 0 replies; 10+ messages in thread
From: Tomasz Kłoczko @ 2005-09-12 15:39 UTC (permalink / raw)
To: Tom 'spot' Callaway
Cc: Aurora development, linux-kernel, David S. Miller, sparclinux
[-- Attachment #1: Type: TEXT/PLAIN, Size: 513 bytes --]
On Mon, 12 Sep 2005, Tom 'spot' Callaway wrote:
[..]
> We've been seeing this intermittently on arthur since Aurora 1.0 (2.4).
I see this secont time. Each time it was during dayly backup (dumping data
on NFS volume).
Can I do something more ?
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Aurora-sparc-devel] [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-12 14:45 ` [Aurora-sparc-devel] " Tom 'spot' Callaway
2005-09-12 15:39 ` Tomasz Kłoczko
@ 2005-09-12 20:41 ` David S. Miller
2005-09-12 20:45 ` Tom 'spot' Callaway
1 sibling, 1 reply; 10+ messages in thread
From: David S. Miller @ 2005-09-12 20:41 UTC (permalink / raw)
To: tcallawa; +Cc: aurora-sparc-devel, linux-kernel, davem, sparclinux
From: "Tom 'spot' Callaway" <tcallawa@redhat.com>
Date: Mon, 12 Sep 2005 09:45:16 -0500
> We've been seeing this intermittently on arthur since Aurora 1.0 (2.4).
That's amazing given that half of those SLAB functions in
the backtrace simply do not exist in 2.4.x :-) Can you quote
a 2.4.x version of such a backtrace? Thanks a lot.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Aurora-sparc-devel] [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-12 20:41 ` David S. Miller
@ 2005-09-12 20:45 ` Tom 'spot' Callaway
0 siblings, 0 replies; 10+ messages in thread
From: Tom 'spot' Callaway @ 2005-09-12 20:45 UTC (permalink / raw)
To: David S. Miller; +Cc: aurora-sparc-devel, linux-kernel, davem, sparclinux
On Mon, 2005-09-12 at 13:41 -0700, David S. Miller wrote:
> From: "Tom 'spot' Callaway" <tcallawa@redhat.com>
> Date: Mon, 12 Sep 2005 09:45:16 -0500
>
> > We've been seeing this intermittently on arthur since Aurora 1.0 (2.4).
>
> That's amazing given that half of those SLAB functions in
> the backtrace simply do not exist in 2.4.x :-) Can you quote
> a 2.4.x version of such a backtrace? Thanks a lot.
You're right. I first saw this on 2.6.4:
http://marc.theaimsgroup.com/?l=linux-sparc&m=107823740703651&w=2
~spot
--
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-12 14:37 [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption) Tomasz Kłoczko
2005-09-12 14:45 ` [Aurora-sparc-devel] " Tom 'spot' Callaway
@ 2005-09-12 23:13 ` David S. Miller
2005-09-13 10:12 ` Tomasz Kłoczko
1 sibling, 1 reply; 10+ messages in thread
From: David S. Miller @ 2005-09-12 23:13 UTC (permalink / raw)
To: kloczek; +Cc: linux-kernel, davem, sparclinux, aurora-sparc-devel
From: Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl>
Date: Mon, 12 Sep 2005 16:37:04 +0200 (CEST)
> On first it looks like stack or buffer-cache corruption.
>
> Slab corruption: (Not tainted) start=fffff8005d9be708, len=808
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [destroy_inode+100/144](destroy_inode+0x64/0x90)
> Call Trace:
> [00000000004759f4] free_block+0x160/0x1b4
> [0000000000475bb8] cache_flusharray+0x98/0x128
> [0000000000475704] kmem_cache_free+0x68/0x94
> [00000000004a56c4] destroy_inode+0x64/0x90
One way for destroy_inode() to be called twice on the same
inode would be if atomic_dec_and_test() was buggy in some way.
I think it might be on sparc64.
Therefore, would you mind giving this patch a test?
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -501,11 +501,6 @@ config SMP
If you don't know what to do here, say N.
-config HAVE_DEC_LOCK
- bool
- depends on SMP
- default y
-
config NR_CPUS
int "Maximum number of CPUs (2-64)"
range 2 64
diff --git a/arch/alpha/kernel/alpha_ksyms.c b/arch/alpha/kernel/alpha_ksyms.c
--- a/arch/alpha/kernel/alpha_ksyms.c
+++ b/arch/alpha/kernel/alpha_ksyms.c
@@ -184,7 +184,6 @@ EXPORT_SYMBOL(cpu_data);
EXPORT_SYMBOL(smp_num_cpus);
EXPORT_SYMBOL(smp_call_function);
EXPORT_SYMBOL(smp_call_function_on_cpu);
-EXPORT_SYMBOL(_atomic_dec_and_lock);
EXPORT_SYMBOL(cpu_present_mask);
#endif /* CONFIG_SMP */
diff --git a/arch/alpha/lib/Makefile b/arch/alpha/lib/Makefile
--- a/arch/alpha/lib/Makefile
+++ b/arch/alpha/lib/Makefile
@@ -40,8 +40,6 @@ lib-y = __divqu.o __remqu.o __divlu.o __
fpreg.o \
callback_srm.o srm_puts.o srm_printk.o
-lib-$(CONFIG_SMP) += dec_and_lock.o
-
# The division routines are built from single source, with different defines.
AFLAGS___divqu.o = -DDIV
AFLAGS___remqu.o = -DREM
diff --git a/arch/alpha/lib/dec_and_lock.c b/arch/alpha/lib/dec_and_lock.c
deleted file mode 100644
--- a/arch/alpha/lib/dec_and_lock.c
+++ /dev/null
@@ -1,42 +0,0 @@
-/*
- * arch/alpha/lib/dec_and_lock.c
- *
- * ll/sc version of atomic_dec_and_lock()
- *
- */
-
-#include <linux/spinlock.h>
-#include <asm/atomic.h>
-
- asm (".text \n\
- .global _atomic_dec_and_lock \n\
- .ent _atomic_dec_and_lock \n\
- .align 4 \n\
-_atomic_dec_and_lock: \n\
- .prologue 0 \n\
-1: ldl_l $1, 0($16) \n\
- subl $1, 1, $1 \n\
- beq $1, 2f \n\
- stl_c $1, 0($16) \n\
- beq $1, 4f \n\
- mb \n\
- clr $0 \n\
- ret \n\
-2: br $29, 3f \n\
-3: ldgp $29, 0($29) \n\
- br $atomic_dec_and_lock_1..ng \n\
- .subsection 2 \n\
-4: br 1b \n\
- .previous \n\
- .end _atomic_dec_and_lock");
-
-static int __attribute_used__
-atomic_dec_and_lock_1(atomic_t *atomic, spinlock_t *lock)
-{
- /* Slow path */
- spin_lock(lock);
- if (atomic_dec_and_test(atomic))
- return 1;
- spin_unlock(lock);
- return 0;
-}
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -908,11 +908,6 @@ config IRQBALANCE
The default yes will allow the kernel to do irq load balancing.
Saying no will keep the kernel from doing irq load balancing.
-config HAVE_DEC_LOCK
- bool
- depends on (SMP || PREEMPT) && X86_CMPXCHG
- default y
-
# turning this on wastes a bunch of space.
# Summit needs it only when NUMA is on
config BOOT_IOREMAP
diff --git a/arch/i386/lib/Makefile b/arch/i386/lib/Makefile
--- a/arch/i386/lib/Makefile
+++ b/arch/i386/lib/Makefile
@@ -7,4 +7,3 @@ lib-y = checksum.o delay.o usercopy.o ge
bitops.o
lib-$(CONFIG_X86_USE_3DNOW) += mmx.o
-lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
diff --git a/arch/i386/lib/dec_and_lock.c b/arch/i386/lib/dec_and_lock.c
deleted file mode 100644
--- a/arch/i386/lib/dec_and_lock.c
+++ /dev/null
@@ -1,42 +0,0 @@
-/*
- * x86 version of "atomic_dec_and_lock()" using
- * the atomic "cmpxchg" instruction.
- *
- * (For CPU's lacking cmpxchg, we use the slow
- * generic version, and this one never even gets
- * compiled).
- */
-
-#include <linux/spinlock.h>
-#include <linux/module.h>
-#include <asm/atomic.h>
-
-int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
-{
- int counter;
- int newcount;
-
-repeat:
- counter = atomic_read(atomic);
- newcount = counter-1;
-
- if (!newcount)
- goto slow_path;
-
- asm volatile("lock; cmpxchgl %1,%2"
- :"=a" (newcount)
- :"r" (newcount), "m" (atomic->counter), "0" (counter));
-
- /* If the above failed, "eax" will have changed */
- if (newcount != counter)
- goto repeat;
- return 0;
-
-slow_path:
- spin_lock(lock);
- if (atomic_dec_and_test(atomic))
- return 1;
- spin_unlock(lock);
- return 0;
-}
-EXPORT_SYMBOL(_atomic_dec_and_lock);
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -298,11 +298,6 @@ config PREEMPT
source "mm/Kconfig"
-config HAVE_DEC_LOCK
- bool
- depends on (SMP || PREEMPT)
- default y
-
config IA32_SUPPORT
bool "Support for Linux/x86 binaries"
help
diff --git a/arch/ia64/lib/Makefile b/arch/ia64/lib/Makefile
--- a/arch/ia64/lib/Makefile
+++ b/arch/ia64/lib/Makefile
@@ -15,7 +15,6 @@ lib-$(CONFIG_ITANIUM) += copy_page.o cop
lib-$(CONFIG_MCKINLEY) += copy_page_mck.o memcpy_mck.o
lib-$(CONFIG_PERFMON) += carta_random.o
lib-$(CONFIG_MD_RAID5) += xor.o
-lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
AFLAGS___divdi3.o =
AFLAGS___udivdi3.o = -DUNSIGNED
diff --git a/arch/ia64/lib/dec_and_lock.c b/arch/ia64/lib/dec_and_lock.c
deleted file mode 100644
--- a/arch/ia64/lib/dec_and_lock.c
+++ /dev/null
@@ -1,42 +0,0 @@
-/*
- * Copyright (C) 2003 Jerome Marchand, Bull S.A.
- * Cleaned up by David Mosberger-Tang <davidm@hpl.hp.com>
- *
- * This file is released under the GPLv2, or at your option any later version.
- *
- * ia64 version of "atomic_dec_and_lock()" using the atomic "cmpxchg" instruction. This
- * code is an adaptation of the x86 version of "atomic_dec_and_lock()".
- */
-
-#include <linux/compiler.h>
-#include <linux/module.h>
-#include <linux/spinlock.h>
-#include <asm/atomic.h>
-
-/*
- * Decrement REFCOUNT and if the count reaches zero, acquire the spinlock. Both of these
- * operations have to be done atomically, so that the count doesn't drop to zero without
- * acquiring the spinlock first.
- */
-int
-_atomic_dec_and_lock (atomic_t *refcount, spinlock_t *lock)
-{
- int old, new;
-
- do {
- old = atomic_read(refcount);
- new = old - 1;
-
- if (unlikely (old == 1)) {
- /* oops, we may be decrementing to zero, do it the slow way... */
- spin_lock(lock);
- if (atomic_dec_and_test(refcount))
- return 1;
- spin_unlock(lock);
- return 0;
- }
- } while (cmpxchg(&refcount->counter, old, new) != old);
- return 0;
-}
-
-EXPORT_SYMBOL(_atomic_dec_and_lock);
diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -220,11 +220,6 @@ config PREEMPT
Say Y here if you are building a kernel for a desktop, embedded
or real-time system. Say N if you are unsure.
-config HAVE_DEC_LOCK
- bool
- depends on (SMP || PREEMPT)
- default n
-
config SMP
bool "Symmetric multi-processing support"
---help---
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1009,10 +1009,6 @@ config GENERIC_CALIBRATE_DELAY
bool
default y
-config HAVE_DEC_LOCK
- bool
- default y
-
#
# Select some configuration options automatically based on user selections.
#
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -2,7 +2,7 @@
# Makefile for MIPS-specific library files..
#
-lib-y += csum_partial_copy.o dec_and_lock.o memcpy.o promlib.o \
+lib-y += csum_partial_copy.o memcpy.o promlib.o \
strlen_user.o strncpy_user.o strnlen_user.o
obj-y += iomap.o
diff --git a/arch/mips/lib/dec_and_lock.c b/arch/mips/lib/dec_and_lock.c
deleted file mode 100644
--- a/arch/mips/lib/dec_and_lock.c
+++ /dev/null
@@ -1,47 +0,0 @@
-/*
- * MIPS version of atomic_dec_and_lock() using cmpxchg
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/module.h>
-#include <linux/spinlock.h>
-#include <asm/atomic.h>
-#include <asm/system.h>
-
-/*
- * This is an implementation of the notion of "decrement a
- * reference count, and return locked if it decremented to zero".
- *
- * This implementation can be used on any architecture that
- * has a cmpxchg, and where atomic->value is an int holding
- * the value of the atomic (i.e. the high bits aren't used
- * for a lock or anything like that).
- */
-int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
-{
- int counter;
- int newcount;
-
- for (;;) {
- counter = atomic_read(atomic);
- newcount = counter - 1;
- if (!newcount)
- break; /* do it the slow way */
-
- newcount = cmpxchg(&atomic->counter, counter, newcount);
- if (newcount == counter)
- return 0;
- }
-
- spin_lock(lock);
- if (atomic_dec_and_test(atomic))
- return 1;
- spin_unlock(lock);
- return 0;
-}
-
-EXPORT_SYMBOL(_atomic_dec_and_lock);
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -26,10 +26,6 @@ config GENERIC_CALIBRATE_DELAY
bool
default y
-config HAVE_DEC_LOCK
- bool
- default y
-
config PPC
bool
default y
diff --git a/arch/ppc/lib/Makefile b/arch/ppc/lib/Makefile
--- a/arch/ppc/lib/Makefile
+++ b/arch/ppc/lib/Makefile
@@ -2,7 +2,7 @@
# Makefile for ppc-specific library files..
#
-obj-y := checksum.o string.o strcase.o dec_and_lock.o div64.o
+obj-y := checksum.o string.o strcase.o div64.o
obj-$(CONFIG_8xx) += rheap.o
obj-$(CONFIG_CPM2) += rheap.o
diff --git a/arch/ppc/lib/dec_and_lock.c b/arch/ppc/lib/dec_and_lock.c
deleted file mode 100644
--- a/arch/ppc/lib/dec_and_lock.c
+++ /dev/null
@@ -1,38 +0,0 @@
-#include <linux/module.h>
-#include <linux/spinlock.h>
-#include <asm/atomic.h>
-#include <asm/system.h>
-
-/*
- * This is an implementation of the notion of "decrement a
- * reference count, and return locked if it decremented to zero".
- *
- * This implementation can be used on any architecture that
- * has a cmpxchg, and where atomic->value is an int holding
- * the value of the atomic (i.e. the high bits aren't used
- * for a lock or anything like that).
- */
-int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
-{
- int counter;
- int newcount;
-
- for (;;) {
- counter = atomic_read(atomic);
- newcount = counter - 1;
- if (!newcount)
- break; /* do it the slow way */
-
- newcount = cmpxchg(&atomic->counter, counter, newcount);
- if (newcount == counter)
- return 0;
- }
-
- spin_lock(lock);
- if (atomic_dec_and_test(atomic))
- return 1;
- spin_unlock(lock);
- return 0;
-}
-
-EXPORT_SYMBOL(_atomic_dec_and_lock);
diff --git a/arch/ppc64/Kconfig b/arch/ppc64/Kconfig
--- a/arch/ppc64/Kconfig
+++ b/arch/ppc64/Kconfig
@@ -28,10 +28,6 @@ config GENERIC_ISA_DMA
bool
default y
-config HAVE_DEC_LOCK
- bool
- default y
-
config EARLY_PRINTK
bool
default y
diff --git a/arch/ppc64/lib/Makefile b/arch/ppc64/lib/Makefile
--- a/arch/ppc64/lib/Makefile
+++ b/arch/ppc64/lib/Makefile
@@ -2,7 +2,7 @@
# Makefile for ppc64-specific library files..
#
-lib-y := checksum.o dec_and_lock.o string.o strcase.o
+lib-y := checksum.o string.o strcase.o
lib-y += copypage.o memcpy.o copyuser.o usercopy.o
# Lock primitives are defined as no-ops in include/linux/spinlock.h
diff --git a/arch/ppc64/lib/dec_and_lock.c b/arch/ppc64/lib/dec_and_lock.c
deleted file mode 100644
--- a/arch/ppc64/lib/dec_and_lock.c
+++ /dev/null
@@ -1,47 +0,0 @@
-/*
- * ppc64 version of atomic_dec_and_lock() using cmpxchg
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/module.h>
-#include <linux/spinlock.h>
-#include <asm/atomic.h>
-#include <asm/system.h>
-
-/*
- * This is an implementation of the notion of "decrement a
- * reference count, and return locked if it decremented to zero".
- *
- * This implementation can be used on any architecture that
- * has a cmpxchg, and where atomic->value is an int holding
- * the value of the atomic (i.e. the high bits aren't used
- * for a lock or anything like that).
- */
-int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
-{
- int counter;
- int newcount;
-
- for (;;) {
- counter = atomic_read(atomic);
- newcount = counter - 1;
- if (!newcount)
- break; /* do it the slow way */
-
- newcount = cmpxchg(&atomic->counter, counter, newcount);
- if (newcount == counter)
- return 0;
- }
-
- spin_lock(lock);
- if (atomic_dec_and_test(atomic))
- return 1;
- spin_unlock(lock);
- return 0;
-}
-
-EXPORT_SYMBOL(_atomic_dec_and_lock);
diff --git a/arch/sparc64/Kconfig.debug b/arch/sparc64/Kconfig.debug
--- a/arch/sparc64/Kconfig.debug
+++ b/arch/sparc64/Kconfig.debug
@@ -33,14 +33,6 @@ config DEBUG_BOOTMEM
depends on DEBUG_KERNEL
bool "Debug BOOTMEM initialization"
-# We have a custom atomic_dec_and_lock() implementation but it's not
-# compatible with spinlock debugging so we need to fall back on
-# the generic version in that case.
-config HAVE_DEC_LOCK
- bool
- depends on SMP && !DEBUG_SPINLOCK
- default y
-
config MCOUNT
bool
depends on STACK_DEBUG
diff --git a/arch/sparc64/kernel/sparc64_ksyms.c b/arch/sparc64/kernel/sparc64_ksyms.c
--- a/arch/sparc64/kernel/sparc64_ksyms.c
+++ b/arch/sparc64/kernel/sparc64_ksyms.c
@@ -163,9 +163,6 @@ EXPORT_SYMBOL(atomic64_add);
EXPORT_SYMBOL(atomic64_add_ret);
EXPORT_SYMBOL(atomic64_sub);
EXPORT_SYMBOL(atomic64_sub_ret);
-#ifdef CONFIG_SMP
-EXPORT_SYMBOL(_atomic_dec_and_lock);
-#endif
/* Atomic bit operations. */
EXPORT_SYMBOL(test_and_set_bit);
diff --git a/arch/sparc64/lib/Makefile b/arch/sparc64/lib/Makefile
--- a/arch/sparc64/lib/Makefile
+++ b/arch/sparc64/lib/Makefile
@@ -14,6 +14,4 @@ lib-y := PeeCeeI.o copy_page.o clear_pag
copy_in_user.o user_fixup.o memmove.o \
mcount.o ipcsum.o rwsem.o xor.o find_bit.o delay.o
-lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
-
obj-y += iomap.o
diff --git a/arch/sparc64/lib/dec_and_lock.S b/arch/sparc64/lib/dec_and_lock.S
deleted file mode 100644
--- a/arch/sparc64/lib/dec_and_lock.S
+++ /dev/null
@@ -1,80 +0,0 @@
-/* $Id: dec_and_lock.S,v 1.5 2001/11/18 00:12:56 davem Exp $
- * dec_and_lock.S: Sparc64 version of "atomic_dec_and_lock()"
- * using cas and ldstub instructions.
- *
- * Copyright (C) 2000 David S. Miller (davem@redhat.com)
- */
-#include <linux/config.h>
-#include <asm/thread_info.h>
-
- .text
- .align 64
-
- /* CAS basically works like this:
- *
- * void CAS(MEM, REG1, REG2)
- * {
- * START_ATOMIC();
- * if (*(MEM) == REG1) {
- * TMP = *(MEM);
- * *(MEM) = REG2;
- * REG2 = TMP;
- * } else
- * REG2 = *(MEM);
- * END_ATOMIC();
- * }
- */
-
- .globl _atomic_dec_and_lock
-_atomic_dec_and_lock: /* %o0 = counter, %o1 = lock */
-loop1: lduw [%o0], %g2
- subcc %g2, 1, %g7
- be,pn %icc, start_to_zero
- nop
-nzero: cas [%o0], %g2, %g7
- cmp %g2, %g7
- bne,pn %icc, loop1
- mov 0, %g1
-
-out:
- membar #StoreLoad | #StoreStore
- retl
- mov %g1, %o0
-start_to_zero:
-#ifdef CONFIG_PREEMPT
- ldsw [%g6 + TI_PRE_COUNT], %g3
- add %g3, 1, %g3
- stw %g3, [%g6 + TI_PRE_COUNT]
-#endif
-to_zero:
- ldstub [%o1], %g3
- membar #StoreLoad | #StoreStore
- brnz,pn %g3, spin_on_lock
- nop
-loop2: cas [%o0], %g2, %g7 /* ASSERT(g7 == 0) */
- cmp %g2, %g7
-
- be,pt %icc, out
- mov 1, %g1
- lduw [%o0], %g2
- subcc %g2, 1, %g7
- be,pn %icc, loop2
- nop
- membar #StoreStore | #LoadStore
- stb %g0, [%o1]
-#ifdef CONFIG_PREEMPT
- ldsw [%g6 + TI_PRE_COUNT], %g3
- sub %g3, 1, %g3
- stw %g3, [%g6 + TI_PRE_COUNT]
-#endif
-
- b,pt %xcc, nzero
- nop
-spin_on_lock:
- ldub [%o1], %g3
- membar #LoadLoad
- brnz,pt %g3, spin_on_lock
- nop
- ba,pt %xcc, to_zero
- nop
- nop
diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -277,11 +277,6 @@ source "mm/Kconfig"
config HAVE_ARCH_EARLY_PFN_TO_NID
def_bool y
-config HAVE_DEC_LOCK
- bool
- depends on SMP
- default y
-
config NR_CPUS
int "Maximum number of CPUs (2-256)"
range 2 256
diff --git a/arch/x86_64/kernel/x8664_ksyms.c b/arch/x86_64/kernel/x8664_ksyms.c
--- a/arch/x86_64/kernel/x8664_ksyms.c
+++ b/arch/x86_64/kernel/x8664_ksyms.c
@@ -178,10 +178,6 @@ EXPORT_SYMBOL(rwsem_down_write_failed_th
EXPORT_SYMBOL(empty_zero_page);
-#ifdef CONFIG_HAVE_DEC_LOCK
-EXPORT_SYMBOL(_atomic_dec_and_lock);
-#endif
-
EXPORT_SYMBOL(die_chain);
EXPORT_SYMBOL(register_die_notifier);
diff --git a/arch/x86_64/lib/Makefile b/arch/x86_64/lib/Makefile
--- a/arch/x86_64/lib/Makefile
+++ b/arch/x86_64/lib/Makefile
@@ -10,5 +10,3 @@ lib-y := csum-partial.o csum-copy.o csum
usercopy.o getuser.o putuser.o \
thunk.o clear_page.o copy_page.o bitstr.o bitops.o
lib-y += memcpy.o memmove.o memset.o copy_user.o
-
-lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
diff --git a/arch/x86_64/lib/dec_and_lock.c b/arch/x86_64/lib/dec_and_lock.c
deleted file mode 100644
--- a/arch/x86_64/lib/dec_and_lock.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * x86 version of "atomic_dec_and_lock()" using
- * the atomic "cmpxchg" instruction.
- *
- * (For CPU's lacking cmpxchg, we use the slow
- * generic version, and this one never even gets
- * compiled).
- */
-
-#include <linux/spinlock.h>
-#include <asm/atomic.h>
-
-int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
-{
- int counter;
- int newcount;
-
-repeat:
- counter = atomic_read(atomic);
- newcount = counter-1;
-
- if (!newcount)
- goto slow_path;
-
- asm volatile("lock; cmpxchgl %1,%2"
- :"=a" (newcount)
- :"r" (newcount), "m" (atomic->counter), "0" (counter));
-
- /* If the above failed, "eax" will have changed */
- if (newcount != counter)
- goto repeat;
- return 0;
-
-slow_path:
- spin_lock(lock);
- if (atomic_dec_and_test(atomic))
- return 1;
- spin_unlock(lock);
- return 0;
-}
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -26,10 +26,6 @@ config RWSEM_XCHGADD_ALGORITHM
bool
default y
-config HAVE_DEC_LOCK
- bool
- default y
-
config GENERIC_HARDIRQS
bool
default y
diff --git a/lib/Makefile b/lib/Makefile
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -5,7 +5,7 @@
lib-y := errno.o ctype.o string.o vsprintf.o cmdline.o \
bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \
idr.o div64.o int_sqrt.o bitmap.o extable.o prio_tree.o \
- sha1.o
+ sha1.o dec_and_lock.o
lib-y += kobject.o kref.o kobject_uevent.o klist.o
@@ -24,10 +24,6 @@ lib-$(CONFIG_GENERIC_FIND_NEXT_BIT) += f
obj-$(CONFIG_LOCK_KERNEL) += kernel_lock.o
obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o
-ifneq ($(CONFIG_HAVE_DEC_LOCK),y)
- lib-y += dec_and_lock.o
-endif
-
obj-$(CONFIG_CRC_CCITT) += crc-ccitt.o
obj-$(CONFIG_CRC16) += crc16.o
obj-$(CONFIG_CRC32) += crc32.o
diff --git a/lib/dec_and_lock.c b/lib/dec_and_lock.c
--- a/lib/dec_and_lock.c
+++ b/lib/dec_and_lock.c
@@ -1,7 +1,41 @@
#include <linux/module.h>
#include <linux/spinlock.h>
#include <asm/atomic.h>
+#include <asm/system.h>
+#ifdef __HAVE_ARCH_CMPXCHG
+/*
+ * This is an implementation of the notion of "decrement a
+ * reference count, and return locked if it decremented to zero".
+ *
+ * This implementation can be used on any architecture that
+ * has a cmpxchg, and where atomic->value is an int holding
+ * the value of the atomic (i.e. the high bits aren't used
+ * for a lock or anything like that).
+ */
+int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
+{
+ int counter;
+ int newcount;
+
+ for (;;) {
+ counter = atomic_read(atomic);
+ newcount = counter - 1;
+ if (!newcount)
+ break; /* do it the slow way */
+
+ newcount = cmpxchg(&atomic->counter, counter, newcount);
+ if (newcount == counter)
+ return 0;
+ }
+
+ spin_lock(lock);
+ if (atomic_dec_and_test(atomic))
+ return 1;
+ spin_unlock(lock);
+ return 0;
+}
+#else
/*
* This is an architecture-neutral, but slow,
* implementation of the notion of "decrement
@@ -33,5 +67,6 @@ int _atomic_dec_and_lock(atomic_t *atomi
spin_unlock(lock);
return 0;
}
+#endif
EXPORT_SYMBOL(_atomic_dec_and_lock);
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-12 23:13 ` David S. Miller
@ 2005-09-13 10:12 ` Tomasz Kłoczko
2005-09-13 20:08 ` David S. Miller
0 siblings, 1 reply; 10+ messages in thread
From: Tomasz Kłoczko @ 2005-09-13 10:12 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, davem, sparclinux, aurora-sparc-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1704 bytes --]
On Mon, 12 Sep 2005, David S. Miller wrote:
> From: Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl>
> Date: Mon, 12 Sep 2005 16:37:04 +0200 (CEST)
>
>> On first it looks like stack or buffer-cache corruption.
>>
>> Slab corruption: (Not tainted) start=fffff8005d9be708, len=808
>> Redzone: 0x5a2cf071/0x5a2cf071.
>> Last user: [destroy_inode+100/144](destroy_inode+0x64/0x90)
>> Call Trace:
>> [00000000004759f4] free_block+0x160/0x1b4
>> [0000000000475bb8] cache_flusharray+0x98/0x128
>> [0000000000475704] kmem_cache_free+0x68/0x94
>> [00000000004a56c4] destroy_inode+0x64/0x90
>
> One way for destroy_inode() to be called twice on the same
> inode would be if atomic_dec_and_test() was buggy in some way.
> I think it might be on sparc64.
>
> Therefore, would you mind giving this patch a test?
I will. Thanks.
Dave I have next thing.
In kernel 2.6.13-rc6-git13 I observe relative very intensive emmiting some
kernel messages. From yesterday logs:
# grep "^Sep 12" /var/log/messages | grep kernel: | uniq | cut -d " " -f 6- | sort | uniq -c | sort -n | tail -n 2
509 svc: bad direction 268435456, dropping request
653 eth0: Happy Meal out of receive descriptors, packet dropped.
As you see one of this two messagess occures avarange one time per ~two
minutes.
Second looks like some error in sunhme.c. eth0 it is:
0001:00:01.1 Ethernet controller: Sun Microsystems Computer Corp. Happy Meal (rev 01)
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-13 10:12 ` Tomasz Kłoczko
@ 2005-09-13 20:08 ` David S. Miller
2005-09-14 11:16 ` Tomasz Kłoczko
0 siblings, 1 reply; 10+ messages in thread
From: David S. Miller @ 2005-09-13 20:08 UTC (permalink / raw)
To: kloczek; +Cc: linux-kernel, davem, sparclinux, aurora-sparc-devel
From: Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl>
Date: Tue, 13 Sep 2005 12:12:22 +0200 (CEST)
> # grep "^Sep 12" /var/log/messages | grep kernel: | uniq | cut -d " " -f 6- | sort | uniq -c | sort -n | tail -n 2
> 509 svc: bad direction 268435456, dropping request
> 653 eth0: Happy Meal out of receive descriptors, packet dropped.
>
> As you see one of this two messagess occures avarange one time per ~two
> minutes.
> Second looks like some error in sunhme.c. eth0 it is:
It's not a bug, per se, your system is simply receiving more
network traffic than the kernel can receive. So the network
adapter runs out of receive descriptors in which to receive
new packets, and starts dropping them until the kernel catches
up again. That's what that message means.
The "svc: " one I've seen before, it looks like something is
clobbering the sunrpc message, for example a freed up buffer is having
some bit set in one of it's words. This 268435456 value is
"0x10000000" hexadecimal. The code expects the value zero, and we
have a stray bit being set in there, bit 28 to be exact. This would
actually be expected after you trigger something like that
destroy_inode() bug as a buffer is being free'd up twice.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-13 20:08 ` David S. Miller
@ 2005-09-14 11:16 ` Tomasz Kłoczko
2005-09-14 11:40 ` Tomasz Kłoczko
0 siblings, 1 reply; 10+ messages in thread
From: Tomasz Kłoczko @ 2005-09-14 11:16 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, davem, sparclinux, aurora-sparc-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2490 bytes --]
On Tue, 13 Sep 2005, David S. Miller wrote:
> From: Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl>
> Date: Tue, 13 Sep 2005 12:12:22 +0200 (CEST)
>
>> # grep "^Sep 12" /var/log/messages | grep kernel: | uniq | cut -d " " -f 6- | sort | uniq -c | sort -n | tail -n 2
>> 509 svc: bad direction 268435456, dropping request
>> 653 eth0: Happy Meal out of receive descriptors, packet dropped.
>>
>> As you see one of this two messagess occures avarange one time per ~two
>> minutes.
>> Second looks like some error in sunhme.c. eth0 it is:
>
> It's not a bug, per se, your system is simply receiving more
> network traffic than the kernel can receive.
> So the network adapter runs out of receive descriptors in which to receive
> new packets, and starts dropping them until the kernel catches
> up again. That's what that message means.
Dave you touch core of problems .. messages occures constantly but
high network activity occures only at night on this interface (backup). In
attachment is weekly graph network acivity measured on SNMP agent on
switch on this port.
At day usualaly on this interface activity is is very low (5-40Kb/s
in/out).
> The "svc: " one I've seen before, it looks like something is
> clobbering the sunrpc message, for example a freed up buffer is having
> some bit set in one of it's words. This 268435456 value is
> "0x10000000" hexadecimal. The code expects the value zero, and we
> have a stray bit being set in there, bit 28 to be exact. This would
> actually be expected after you trigger something like that
> destroy_inode() bug as a buffer is being free'd up twice.
Good news. After switch to kernel 2.6.13-1.1552sp1 from corona with your
patch I don't see "svc: .." messages, but "eth0: Happy Meal .." still
occures (seems less but still).
After ~half of day (and pass one time backup at night):
[root@boss ~]# grep "^Sep 14" /var/log/kernel | grep kernel: | uniq | cut -d " " -f 6- | sort | uniq -c | sort -n | tail -n 3
2 udp v4 hw csum failure.
15 eth0: Happy Meal out of receive descriptors, packet dropped.
22 hw tcp v4 csum failed
[root@boss ~]# LANG= date
Wed Sep 14 13:15:01 CEST 2005
I'll try count of this for compare again at ~12:00 pm.
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
[-- Attachment #2: Type: APPLICATION/OCTET-STREAM, Size: 3474 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption)
2005-09-14 11:16 ` Tomasz Kłoczko
@ 2005-09-14 11:40 ` Tomasz Kłoczko
0 siblings, 0 replies; 10+ messages in thread
From: Tomasz Kłoczko @ 2005-09-14 11:40 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, davem, sparclinux, aurora-sparc-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 981 bytes --]
On Wed, 14 Sep 2005, Tomasz Kłoczko wrote:
[..]
> Dave you touch core of problems .. messages occures constantly but high
> network activity occures only at night on this interface (backup). In
> attachment is weekly graph network acivity measured on SNMP agent on switch
> on this port.
> At day usualaly on this interface activity is is very low (5-40Kb/s in/out).
In attachemnt is filtered kernel log with timestamps which shows all
"eth0: Happy Meal .." and "hw tcp/udp v4 csum failed" which was occure
after yesterday boot on kernel 2.6.13-1.1552sp1 (which bases on
2.6.14-rc1).
Backup was between 1:00 am and 4:00 am.
As you see there is no corelation between messages and high/low network
activity.
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
[-- Attachment #2: Type: TEXT/PLAIN, Size: 5388 bytes --]
Sep 13 21:58:22 boss kernel: device eth0 entered promiscuous mode
Sep 13 22:06:53 boss kernel: hw tcp v4 csum failed
Sep 13 22:16:44 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 13 22:21:00 boss last message repeated 3 times
Sep 13 22:51:10 boss last message repeated 3 times
Sep 13 22:51:11 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 13 22:58:06 boss kernel: hw tcp v4 csum failed
Sep 13 22:58:07 boss kernel: hw tcp v4 csum failed
Sep 13 22:58:50 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 13 23:02:16 boss last message repeated 3 times
Sep 13 23:08:02 boss last message repeated 3 times
Sep 13 23:27:03 boss last message repeated 3 times
Sep 13 23:55:45 boss last message repeated 2 times
Sep 14 00:10:58 boss last message repeated 6 times
Sep 14 00:11:08 boss last message repeated 3 times
Sep 14 00:23:09 boss kernel: hw tcp v4 csum failed
Sep 14 00:24:16 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 00:24:26 boss last message repeated 4 times
Sep 14 00:50:31 boss kernel: hw tcp v4 csum failed
Sep 14 00:53:36 boss kernel: hw tcp v4 csum failed
Sep 14 00:53:37 boss kernel: hw tcp v4 csum failed
Sep 14 01:10:31 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 01:12:23 boss kernel: hw tcp v4 csum failed
Sep 14 01:29:22 boss last message repeated 7 times
Sep 14 01:33:22 boss last message repeated 3 times
Sep 14 01:35:18 boss last message repeated 4 times
Sep 14 01:35:37 boss kernel: hw tcp v4 csum failed
Sep 14 01:40:49 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 01:40:51 boss last message repeated 2 times
Sep 14 01:43:16 boss kernel: hw tcp v4 csum failed
Sep 14 01:57:37 boss kernel: hw tcp v4 csum failed
Sep 14 02:06:30 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 02:14:34 boss last message repeated 3 times
Sep 14 02:14:36 boss last message repeated 2 times
Sep 14 02:30:56 boss kernel: hw tcp v4 csum failed
Sep 14 02:36:04 boss kernel: hw tcp v4 csum failed
Sep 14 02:59:06 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 03:12:37 boss last message repeated 2 times
Sep 14 03:49:08 boss last message repeated 3 times
Sep 14 04:43:55 boss last message repeated 3 times
Sep 14 05:10:00 boss last message repeated 3 times
Sep 14 05:44:44 boss last message repeated 3 times
Sep 14 05:52:18 boss last message repeated 3 times
Sep 14 05:56:45 boss last message repeated 3 times
Sep 14 06:09:41 boss last message repeated 3 times
Sep 14 06:09:46 boss last message repeated 4 times
Sep 14 06:24:28 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 06:24:30 boss last message repeated 2 times
Sep 14 07:05:59 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 07:42:16 boss last message repeated 3 times
Sep 14 07:42:18 boss last message repeated 2 times
Sep 14 08:08:38 boss kernel: hw tcp v4 csum failed
Sep 14 09:03:19 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 09:53:58 boss last message repeated 3 times
Sep 14 09:58:48 boss last message repeated 3 times
Sep 14 09:58:50 boss last message repeated 2 times
Sep 14 10:01:21 boss kernel: hw tcp v4 csum failed
Sep 14 10:05:29 boss kernel: hw tcp v4 csum failed
Sep 14 10:25:08 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 10:25:10 boss last message repeated 2 times
Sep 14 10:50:35 boss kernel: hw tcp v4 csum failed
Sep 14 10:53:25 boss kernel: hw tcp v4 csum failed
Sep 14 11:00:53 boss last message repeated 2 times
Sep 14 11:05:49 boss kernel: hw tcp v4 csum failed
Sep 14 11:11:45 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 11:11:47 boss last message repeated 2 times
Sep 14 11:12:04 boss kernel: udp v4 hw csum failure.
Sep 14 11:12:12 boss kernel: hw tcp v4 csum failed
Sep 14 11:26:52 boss kernel: hw tcp v4 csum failed
Sep 14 11:27:52 boss kernel: udp v4 hw csum failure.
Sep 14 11:31:38 boss kernel: hw tcp v4 csum failed
Sep 14 11:37:40 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 11:43:35 boss last message repeated 3 times
Sep 14 11:58:09 boss last message repeated 3 times
Sep 14 11:58:11 boss last message repeated 2 times
Sep 14 12:03:39 boss kernel: hw tcp v4 csum failed
Sep 14 12:10:48 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 12:10:54 boss last message repeated 3 times
Sep 14 12:15:00 boss kernel: hw tcp v4 csum failed
Sep 14 12:19:02 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 12:19:03 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 12:31:39 boss kernel: hw tcp v4 csum failed
Sep 14 12:44:50 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
Sep 14 13:05:27 boss last message repeated 3 times
Sep 14 13:17:06 boss last message repeated 3 times
Sep 14 13:23:17 boss last message repeated 3 times
Sep 14 13:23:19 boss last message repeated 2 times
Sep 14 13:24:34 boss kernel: hw tcp v4 csum failed
Sep 14 13:27:26 boss kernel: eth0: Happy Meal out of receive descriptors, packet dropped.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-09-14 11:40 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-12 14:37 [2.6.13-rc6-git13/sparc64]: Slab corruption (possible stack or buffer-cache corruption) Tomasz Kłoczko
2005-09-12 14:45 ` [Aurora-sparc-devel] " Tom 'spot' Callaway
2005-09-12 15:39 ` Tomasz Kłoczko
2005-09-12 20:41 ` David S. Miller
2005-09-12 20:45 ` Tom 'spot' Callaway
2005-09-12 23:13 ` David S. Miller
2005-09-13 10:12 ` Tomasz Kłoczko
2005-09-13 20:08 ` David S. Miller
2005-09-14 11:16 ` Tomasz Kłoczko
2005-09-14 11:40 ` Tomasz Kłoczko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox