test11-pre2 compile error undefined reference to `bust_spinlocks'

When attempting to compile test11-pre2, I get the following compile error.

arch/i386/mm/mm.o: In function `do_page_fault':
arch/i386/mm/mm.o(.text+0x781): undefined reference to `bust_spinlocks'
make: *** [vmlinux] Error 1

Index: 0-test11-pre2.1/arch/i386/kernel/traps.c

arch/i386/kernel/traps.c Fri, 10 Nov 2000 15:56:54 +1100 kaos (linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644) renamed from arch/i386/kernel/traps.c Fri, 10 Nov 2000 13:10:37 +1100 kaos (linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644) +11 -0

@@ -382,6 +382,17 @@ static void unknown_nmi_error(unsigned c
        printk("Do you have a strange power saving mode enabled?\n");
 }
 
+/*
+ * Unlock any spinlocks which will prevent us from getting the
+ * message out (timerlist_lock is acquired through the
+ * console unblank code)
+ */
+void bust_spinlocks(void)
+{
+       spin_lock_init(&console_lock);
+       spin_lock_init(&timerlist_lock);
+}
+
 #if CONFIG_X86_IO_APIC
 
 int nmi_watchdog = 1;

When attempting to compile test11-pre2, I get the following compile error.

arch/i386/mm/mm.o: In function `do_page_fault':
arch/i386/mm/mm.o(.text+0x781): undefined reference to `bust_spinlocks'
make: *** [vmlinux] Error 1

When attempting to compile test11-pre2, I get the following compile error.

arch/i386/mm/mm.o: In function `do_page_fault':
arch/i386/mm/mm.o(.text+0x781): undefined reference to `bust_spinlocks'
make: *** [vmlinux] Error 1

Quoted 6 lines · John Kacur

When attempting to compile test11-pre2, I get the following compile error.

arch/i386/mm/mm.o: In function `do_page_fault':
arch/i386/mm/mm.o(.text+0x781): undefined reference to `bust_spinlocks'
make: *** [vmlinux] Error 1

Oops, wrong patch.

Index: 0-test11-pre2.1/arch/i386/kernel/traps.c

arch/i386/kernel/traps.c Fri, 10 Nov 2000 16:06:48 +1100 kaos (linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644) renamed from arch/i386/kernel/traps.c Fri, 10 Nov 2000 13:10:37 +1100 kaos (linux-2.4/A/c/1_traps.c 1.1.2.2.1.1.2.1.2.3.1.2.3.1.1.2 644) +12 -13

@@ -382,6 +382,18 @@ static void unknown_nmi_error(unsigned c
        printk("Do you have a strange power saving mode enabled?\n");
 }
 
+extern spinlock_t console_lock, timerlist_lock;
+/*
+ * Unlock any spinlocks which will prevent us from getting the
+ * message out (timerlist_lock is acquired through the
+ * console unblank code)
+ */
+void bust_spinlocks(void)
+{
+       spin_lock_init(&console_lock);
+       spin_lock_init(&timerlist_lock);
+}
+
 #if CONFIG_X86_IO_APIC
 
 int nmi_watchdog = 1;

@@ -394,19 +406,7 @@ static int __init setup_nmi_watchdog(cha
 
 __setup("nmi_watchdog=", setup_nmi_watchdog);
 
-extern spinlock_t console_lock, timerlist_lock;
 static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
-
-/*
- * Unlock any spinlocks which will prevent us from getting the
- * message out (timerlist_lock is aquired through the
- * console unblank code)
- */
-void bust_spinlocks(void)
-{
-       spin_lock_init(&console_lock);
-       spin_lock_init(&timerlist_lock);
-}
 
 inline void nmi_watchdog_tick(struct pt_regs * regs)
 {
 
-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

The notion of releasing a spin lock by initializing it seems IMHO, on the face of it, way off.

The notion of releasing a spin lock by initializing it seems IMHO, on the face of it, way off. Firstly the protected area is no longer protected which could lead to undefined errors/ crashes and secondly, any future use of spinlocks to control preemption could have a lot of trouble with this, principally because the locker is unknown.

In the case at hand, it would seem that an unlocked path to the console is a more correct answer that gives the system a far better chance of actually remaining viable.

Quoted 11 lines · George Anzinger

The notion of releasing a spin lock by initializing it seems IMHO, on the face of it, way off. Firstly the protected area is no longer protected which could lead to undefined errors/ crashes and secondly, any future use of spinlocks to control preemption could have a lot of trouble with this, principally because the locker is unknown.

In the case at hand, it would seem that an unlocked path to the console is a more correct answer that gives the system a far better chance of actually remaining viable.

Does bust_spinlocks() muck up the preemptive kernel's spinlock counting? Would you prefer spin_trylock()/spin_unlock()? It doesn't matter - if we call bust_spinlocks() the kernel is known to be dead meat and there is a fsck in your near future.

We are still trying to find out why kumon@fujitsu's 8-way is crashing on the test10-pre5 sched.c. Looks like it's fixed in test11-pre2 but we want to know _why_ it's fixed. And at present each time he hits the bug, his printk() deadlocks.

So bust_spinlocks() is a RAS feature :) A very important one - it's terrible when your one-in-a-trillion bug happens and there are no diagnostics.

It's a work-in-progress. There are a lot of things which can cause printk to deadlock:

- console_lock
- timerlist_lock
- global_irq_lock (console code does global_cli)
- log_wait.lock
- tasklist_lock (printk does wake_up) (*)
- runqueue_lock (printk does wake_up)

I'll be proposing a better patch for this in a few days.

Quoted 11 lines · George Anzinger

The notion of releasing a spin lock by initializing it seems IMHO, on the face of it, way off. Firstly the protected area is no longer protected which could lead to undefined errors/ crashes and secondly, any future use of spinlocks to control preemption could have a lot of trouble with this, principally because the locker is unknown.

In the case at hand, it would seem that an unlocked path to the console is a more correct answer that gives the system a far better chance of actually remaining viable.

Does bust_spinlocks() muck up the preemptive kernel's spinlock counting? Would you prefer spin_trylock()/spin_unlock()? It doesn't matter - if we call bust_spinlocks() the kernel is known to be dead meat and there is a fsck in your near future.

We are still trying to find out why kumon@fujitsu's 8-way is crashing on the test10-pre5 sched.c. Looks like it's fixed in test11-pre2 but we want to know _why_ it's fixed. And at present each time he hits the bug, his printk() deadlocks.

So bust_spinlocks() is a RAS feature :) A very important one - it's terrible when your one-in-a-trillion bug happens and there are no diagnostics.

It's a work-in-progress. There are a lot of things which can cause printk to deadlock:

- console_lock
- timerlist_lock
- global_irq_lock (console code does global_cli)
- log_wait.lock
- tasklist_lock (printk does wake_up) (*)
- runqueue_lock (printk does wake_up)

I'll be proposing a better patch for this in a few days.

(*) Keith: this explains why you can't do a printk() in __wake_up_common: printk calls wake_up(). Duh.