>> Not sure if it made it to the list last night but it seems that
>> pre-2.1.127-6 is the oldest patch on kernel.org that will create this
>> problem. 2.1.127-3 will run fine if compiled with the spinlock.h from
>> 127-7. So I would say that something that is in pre-2.1.127-6 is the
>> source of the problem.
> Uhhmmm, this is strange. I read a comment from someone in Slashdot
> that said that Linus had said the UP flu was cured in 2.1.129.
> However, this does not seem to be the case because I am still
> experiencing the problem here (Pentium 75 on a UP-compiled 2.1.129).
Not exactly:
-- cut --
> On Thu, 19 Nov 1998, David Woodhouse wrote:
>>
>> torvalds@transmeta.com said:
>> > And the UP flu is fixed (not in 2.1.129, but elsewhere).
>>
>> I saw a patch on linux-kernel which involved commenting out hard_idle(). Was
>> that it, or was it elsewhere?
> No, the UP flu is a patch to arch/i386/kernel/fork.c and entry.S, it's a
> missing "current" initialization after a fork. I've posted two copies to
> linux-kernel (the first one with a obvious bug that caused it to not link
> due to me forgetting to update the name in the ".globl" declaration).
> Linus
-- cut --
On Thu, 19 Nov 1998, Andrea Arcangeli wrote:
>
> I am sure that the kernel run do_signal() from signal_return, even if
> sigpending is 0. This mean that %ebx got corrupted somewhere (and this
> explain very well also the need_resched flood I suspected some days ago).
> A patch for 2.1.128 that fix the UP hang fine here is this:
Good debugging, but the fix is incorrect (or at least unnecessarily slow).
I see where the problem is, and I also see why it _only_ happens on UP.
The problem is that the fork return point to the new process does not
initialize %ebx in the UP case.
It _does_ initialize it in the SMP case, and this is basically just an
oversight.
This patch should fix it properly, please tell me whether that is true..
Linus
-----
diff -u --recursive --new-file v2.1.129/linux/arch/i386/kernel/entry.S linux/arch/i386/kernel/entry.S
--- v2.1.129/linux/arch/i386/kernel/entry.S Sun Nov 8 14:02:42 1998
+++ linux/arch/i386/kernel/entry.S Thu Nov 19 09:53:08 1998
@@ -150,14 +150,14 @@
jmp ret_from_sys_call
-#ifdef __SMP__
ALIGN
.globl ret_from_smpfork
-ret_from_smpfork:
+ret_from_fork:
GET_CURRENT(%ebx)
+#ifdef __SMP__
btrl $0, SYMBOL_NAME(scheduler_lock)
- jmp ret_from_sys_call
#endif /* __SMP__ */
+ jmp ret_from_sys_call
/*
* Return to user mode is not as complex as all this looks,
diff -u --recursive --new-file v2.1.129/linux/arch/i386/kernel/process.c linux/arch/i386/kernel/process.c
--- v2.1.129/linux/arch/i386/kernel/process.c Fri Oct 9 13:27:05 1998
+++ linux/arch/i386/kernel/process.c Thu Nov 19 09:53:35 1998
@@ -50,11 +50,7 @@
spinlock_t semaphore_wake_lock = SPIN_LOCK_UNLOCKED;
-#ifdef __SMP__
-asmlinkage void ret_from_fork(void) __asm__("ret_from_smpfork");
-#else
-asmlinkage void ret_from_fork(void) __asm__("ret_from_sys_call");
-#endif
+asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
#ifdef CONFIG_APM
extern int apm_do_idle(void);
-- cut --
On Thu, 19 Nov 1998, Linus Torvalds wrote:
>
> This patch should fix it properly, please tell me whether that is true..
Duh, the ".globl" declaration should also obviously be fixed to be
ret_from_fork rather than ret_from_smpfork in order for this to link..
Linus
-----
> diff -u --recursive --new-file v2.1.129/linux/arch/i386/kernel/entry.S linux/arch/i386/kernel/entry.S
> --- v2.1.129/linux/arch/i386/kernel/entry.S Sun Nov 8 14:02:42 1998
> +++ linux/arch/i386/kernel/entry.S Thu Nov 19 09:53:08 1998
> @@ -150,14 +150,14 @@
> jmp ret_from_sys_call
>
>
> -#ifdef __SMP__
> ALIGN
> .globl ret_from_smpfork
-- cut -- ^^^^^^^^^^^^^^^^
-
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/