Messages in this thread Patches in this message | | | From | "Khimenko Victor" <> | Date | Fri, 20 Nov 1998 21:43:09 +0300 (MSK) | Subject | Re: 128 Flu |
| |
20-Nov-98 04:43 you wrote: > George Bonser <grep@shorelink.com> wrote:
>> 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/
| |