lkml.org 
[lkml]   [1999]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: SMP lockup & 3c509 on 2.2.x [aka. the Deadly 'ping -f']
On Fri, 23 Apr 1999, Andrea Arcangeli wrote:

>> bh 2[0,0]

I have a cleanup:

Index: arch/i386/kernel/irq.c
===================================================================
RCS file: /var/cvs/linux/arch/i386/kernel/irq.c,v
retrieving revision 1.1.2.14
diff -u -r1.1.2.14 irq.c
--- irq.c 1999/04/17 14:58:41 1.1.2.14
+++ linux/arch/i386/kernel/irq.c 1999/04/23 14:54:20
@@ -442,11 +442,11 @@
*/
#ifdef __SMP__
unsigned char global_irq_holder = NO_PROC_ID;
-unsigned volatile int global_irq_lock;
-atomic_t global_irq_count;
+unsigned long global_irq_lock = 0;
+atomic_t global_irq_count = ATOMIC_INIT(0);

-atomic_t global_bh_count;
-atomic_t global_bh_lock;
+unsigned long global_bh_count = 0;
+atomic_t global_bh_lock = ATOMIC_INIT(0);
spinlock_t i386_bh_lock = SPIN_LOCK_UNLOCKED;

/*
@@ -467,7 +467,6 @@

static void show(char * str)
{
- int i;
unsigned long *stack;
int cpu = smp_processor_id();
extern char *get_options(char *str, int *ints);
@@ -476,13 +475,15 @@
printk("irq: %d [%d %d]\n",
atomic_read(&global_irq_count), local_irq_count[0], local_irq_count[1]);
printk("bh: %d [%d %d]\n",
- atomic_read(&global_bh_count), local_bh_count[0], local_bh_count[1]);
+ test_bit(0, &global_bh_count), local_bh_count[0], local_bh_count[1]);
stack = (unsigned long *) &stack;
- for (i = 40; i ; i--) {
+ for (;;) {
unsigned long x = *++stack;
if (x > (unsigned long) &get_options && x < (unsigned long) &vsprintf) {
printk("<[%08lx]> ", x);
}
+ if (!(x & 0x2000)) /* break if we finished the stack */
+ break;
}
}

@@ -497,7 +498,7 @@
count = ~0;
}
/* nothing .. wait for the other bh's to go away */
- } while (atomic_read(&global_bh_count) != 0);
+ } while (test_bit(0, &global_bh_count));
}

/*
@@ -539,7 +540,7 @@
* already executing in one..
*/
if (!atomic_read(&global_irq_count)) {
- if (local_bh_count[cpu] || !atomic_read(&global_bh_count))
+ if (local_bh_count[cpu] || !test_bit(0, &global_bh_count))
break;
}

@@ -557,9 +558,9 @@
check_smp_invalidate(cpu);
if (atomic_read(&global_irq_count))
continue;
- if (global_irq_lock)
+ if (test_bit(0, &global_irq_lock))
continue;
- if (!local_bh_count[cpu] && atomic_read(&global_bh_count))
+ if (!local_bh_count[cpu] && test_bit(0, &global_bh_count))
continue;
if (!test_and_set_bit(0,&global_irq_lock))
break;
@@ -577,7 +578,7 @@
*/
void synchronize_bh(void)
{
- if (atomic_read(&global_bh_count) && !in_interrupt())
+ if (test_bit(0, &global_bh_count) && !in_interrupt())
wait_on_bh();
}

Index: include/asm-i386/hardirq.h
===================================================================
RCS file: /var/cvs/linux/include/asm-i386/hardirq.h,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 hardirq.h
--- hardirq.h 1999/03/23 15:02:23 1.1.2.2
+++ linux/include/asm-i386/hardirq.h 1999/04/23 15:04:56
@@ -27,7 +27,7 @@
#include <asm/atomic.h>

extern unsigned char global_irq_holder;
-extern unsigned volatile int global_irq_lock;
+extern unsigned long global_irq_lock;
extern atomic_t global_irq_count;

static inline void release_irqlock(int cpu)
Index: include/asm-i386/softirq.h
===================================================================
RCS file: /var/cvs/linux/include/asm-i386/softirq.h,v
retrieving revision 1.1.2.6
diff -u -r1.1.2.6 softirq.h
--- softirq.h 1999/04/06 00:51:30 1.1.2.6
+++ linux/include/asm-i386/softirq.h 1999/04/23 15:04:57
@@ -17,7 +17,7 @@
* referenced at all outside of this file.
*/
extern atomic_t global_bh_lock;
-extern atomic_t global_bh_count;
+extern unsigned long global_bh_count;
extern spinlock_t i386_bh_lock;

extern void synchronize_bh(void);


Note, it should make no difference at all, it's only that I don't like to
use test_and_set over an atomic_t (an atomic_t is an int while
test_and_set works on ulong) considering that you have global_bh_count ==
2 and it can't be > 1... Maybe it's happened by memory corruption or by an
hardware bug? Is your harware trustable??
So please reverse the old patch I sent to you to get the longer trace
(that it's merged here as well) and apply this new patch and try to
reproduce (you should be able to do that but this time you won't get a
global_bh_count == 2 ;).

Andrea Arcangeli


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

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.466 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site