Success kernel-243pre8-SMP(patch)(Re: spin_lock problem in recent k ernel

7 messages, 5 authors, 2001-03-30 · open the first message on its own page

Success kernel-243pre8-SMP(patch)(Re: spin_lock problem in recent k ernel

From: Kaoru Fukui <hidden>
Date: 2001-03-29 21:20:00

Many thanks Tom,

I have had a success for kernel-2.4.3.pre8-SMP on Dual G4.
This kernel needs the patch.

Kernel Guys, Please look the patch

I will be able to upload this binary kernel into my directory tomorrow.

Kaoru
-------- this patch is needed for SMP kernel-2.4.3.pre8  ---------

diff -urN base/arch/ppc/mm/init.c fixed/arch/ppc/mm/init.c
--- base/arch/ppc/mm/init.c	Thu Mar 29 06:02:35 2001
+++ fixed/arch/ppc/mm/init.c	Fri Mar 30 05:51:16 2001
@@ -437,12 +437,15 @@
 	/*
 	 * Should check if it is a candidate for a BAT mapping
 	 */
-
+#ifndef CONFIG_SMP
 	spin_lock(&init_mm.page_table_lock);
+#endif
 	err = 0;
 	for (i = 0; i < size && err == 0; i += PAGE_SIZE)
 		err = map_page(v+i, p+i, flags);
+#ifndef CONFIG_SMP
 	spin_unlock(&init_mm.page_table_lock);
+#endif
 	if (err) {
 		if (mem_init_done)
 			vfree((void *)v);
diff -urN base/mm/memory.c fixed/mm/memory.c
--- base/mm/memory.c	Thu Mar 29 09:22:35 2001
+++ fixed/mm/memory.c	Fri Mar 30 05:52:17 2001
@@ -1320,9 +1320,13 @@
 		/* "fast" allocation can happen without dropping the lock.. */
 		new = pte_alloc_one_fast(address);
 		if (!new) {
+#ifndef CONFIG_SMP
 			spin_unlock(&mm->page_table_lock);
+#endif
 			new = pte_alloc_one(address);
+#ifndef CONFIG_SMP
 			spin_lock(&mm->page_table_lock);
+#endif
 			if (!new)
 				return NULL;

---------- END -------------
quoted
This is booing message when kernel-2.4.3pre8-SMP.

<snip>
TCP: Hash tables configured (established 8192 bind 8192)
ip_conntrack(2048 buckets,16384 max)
_spin_lock(c02cc470) CPU# 1 NIP c0033404 holder: cpu 1 pc C002B384
_spin_lock(c02ce740) CPU# 0 NIP c0015890 holder: cpu 1 pc C0015890
  Can you look at your system.map for that kernel and tell me what is at
addresses:
This is getton  data from system.map
c00153b0 T schedule_tail
<C001589>
c0015a4c T __wake_up
<snip>
c002b28c T pte_alloc
<C002b384>
c002b3d8 T make_pages_present
<snip>
c02cc42c D init_mm
<c02cc470>
c02cc4d0 D init_task_union
<snip>
c02ce738 d null_pci_ops
<c02ce740>
c02ce750 D kernel_flag
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Success kernel-243pre8-SMP(patch)(Re: spin_lock problem in recent kernel

From: Takashi Oe <hidden>
Date: 2001-03-30 02:16:35

On Thu, 29 Mar 2001, Tom Gall wrote:
Hi Kaoru,

  I tried your patch on my 2 way Power3 Model 270 RS/6000 just before I
left but didn't have enough time to write this note until now.

  Your patch amazingly booted my box quite a bit further... it still
dies for me but in a new and interesting way, that doesn't appear to be
related to the page_table_lock. (Token Ring and shared memory
...sigh...)

  The part that REALLY REALLY bothers me tho is why does this patch
work? I *HAVE* CONFIG_SMP on... least I think I do... there's two
penguins on my screen ... two processors grinding away ... that's
CONFIG_SMP right??? I'm not losing my mind am I?

  So assuming that CONFIG_SMP is on, this patch shouldn't yeild anything
different what so ever from a codegen perspective with or without the
patch for an SMP kernel build. It doesn't make sense.
He is just commenting out those lines.  They are not "#ifdef CONFIG_SMP".


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Success kernel-243pre8-SMP(patch)(Re: spin_lock problem in recent kernel

From: Tom Gall <hidden>
Date: 2001-03-30 02:18:13

Hi Kaoru,

  I tried your patch on my 2 way Power3 Model 270 RS/6000 just before I
left but didn't have enough time to write this note until now.

  Your patch amazingly booted my box quite a bit further... it still
dies for me but in a new and interesting way, that doesn't appear to be
related to the page_table_lock. (Token Ring and shared memory
...sigh...)

  The part that REALLY REALLY bothers me tho is why does this patch
work? I *HAVE* CONFIG_SMP on... least I think I do... there's two
penguins on my screen ... two processors grinding away ... that's
CONFIG_SMP right??? I'm not losing my mind am I?

  So assuming that CONFIG_SMP is on, this patch shouldn't yeild anything
different what so ever from a codegen perspective with or without the
patch for an SMP kernel build. It doesn't make sense.

Kaoru Fukui wrote:
quoted hunk
Many thanks Tom,

I have had a success for kernel-2.4.3.pre8-SMP on Dual G4.
This kernel needs the patch.

Kernel Guys, Please look the patch

I will be able to upload this binary kernel into my directory tomorrow.

Kaoru
-------- this patch is needed for SMP kernel-2.4.3.pre8  ---------

diff -urN base/arch/ppc/mm/init.c fixed/arch/ppc/mm/init.c
--- base/arch/ppc/mm/init.c     Thu Mar 29 06:02:35 2001
+++ fixed/arch/ppc/mm/init.c    Fri Mar 30 05:51:16 2001
@@ -437,12 +437,15 @@
        /*
         * Should check if it is a candidate for a BAT mapping
         */
-
+#ifndef CONFIG_SMP
        spin_lock(&init_mm.page_table_lock);
+#endif
        err = 0;
        for (i = 0; i < size && err == 0; i += PAGE_SIZE)
                err = map_page(v+i, p+i, flags);
+#ifndef CONFIG_SMP
        spin_unlock(&init_mm.page_table_lock);
+#endif
        if (err) {
                if (mem_init_done)
                        vfree((void *)v);
diff -urN base/mm/memory.c fixed/mm/memory.c
--- base/mm/memory.c    Thu Mar 29 09:22:35 2001
+++ fixed/mm/memory.c   Fri Mar 30 05:52:17 2001
@@ -1320,9 +1320,13 @@
                /* "fast" allocation can happen without dropping the lock.. */
                new = pte_alloc_one_fast(address);
                if (!new) {
+#ifndef CONFIG_SMP
                        spin_unlock(&mm->page_table_lock);
+#endif
                        new = pte_alloc_one(address);
+#ifndef CONFIG_SMP
                        spin_lock(&mm->page_table_lock);
+#endif
                        if (!new)
                                return NULL;

---------- END -------------
quoted
quoted
This is booing message when kernel-2.4.3pre8-SMP.

<snip>
TCP: Hash tables configured (established 8192 bind 8192)
ip_conntrack(2048 buckets,16384 max)
_spin_lock(c02cc470) CPU# 1 NIP c0033404 holder: cpu 1 pc C002B384
_spin_lock(c02ce740) CPU# 0 NIP c0015890 holder: cpu 1 pc C0015890
quoted
  Can you look at your system.map for that kernel and tell me what is at
addresses:
quoted
This is getton  data from system.map
quoted
c00153b0 T schedule_tail
<C001589>
c0015a4c T __wake_up
<snip>
c002b28c T pte_alloc
<C002b384>
c002b3d8 T make_pages_present
<snip>
c02cc42c D init_mm
<c02cc470>
c02cc4d0 D init_task_union
<snip>
c02ce738 d null_pci_ops
<c02ce740>
c02ce750 D kernel_flag
--
Regards,

Tom

--------------------------------------------------------------
Linux Guy             "My heart is human, my blood is boiling,
gall@rochcivictheatre.org    my brain IBM" -- Mr Roboto, Styxx

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Success kernel-243pre8-SMP(patch)(Re: spin_lock problem in recent kernel

From: Tony Mantler <hidden>
Date: 2001-03-30 02:36:11

At 8:18 PM -0600 3/29/2001, Tom Gall wrote:
 So assuming that CONFIG_SMP is on, this patch shouldn't yeild anything
different what so ever from a codegen perspective with or without the
patch for an SMP kernel build. It doesn't make sense.

Kaoru Fukui wrote:
[...]
quoted
+#ifndef CONFIG_SMP
        spin_lock(&init_mm.page_table_lock);
+#endif
That's #if*n*def, not #ifdef. :)

And speaking of #ifndef, why are these spinlocks here in the first place
and/or why do they now need to be removed? Just suddenly removing locks
because of a new deadlock condition gets my spidey senses tingling.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Success kernel-243pre8-SMP(patch)(Re: spin_lock problem in recent kernel

From: Tom Gall <hidden>
Date: 2001-03-30 02:48:21

Takashi Oe wrote:
He is just commenting out those lines.  They are not "#ifdef CONFIG_SMP".
Sigh ... some days it just doesn't pay to get out of bed... I missed the
'n'....

*BONK *

Thanks!
Takashi Oe
--
Regards,

Tom

--------------------------------------------------------------
Linux Guy             "My heart is human, my blood is boiling,
gall@rochcivictheatre.org    my brain IBM" -- Mr Roboto, Styxx

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Success kernel-243pre8-SMP(patch)(Re: spin_lock problem inrecent kernel

From: Tom Gall <hidden>
Date: 2001-03-30 03:07:11

Tony Mantler wrote:
That's #if*n*def, not #ifdef. :)

And speaking of #ifndef, why are these spinlocks here in the first place
and/or why do they now need to be removed? Just suddenly removing locks
because of a new deadlock condition gets my spidey senses tingling.
It all stinks to high heaven, that's for sure. Removing the
page_table_lock from being locked in ioremap, saves us from stopping
cold during the first ioremap (at least on Power3). And as far as the
second, I'm in complete agreement...  warning warning danger will
robinson!

--
Regards,

Tom

--------------------------------------------------------------
Linux Guy             "My heart is human, my blood is boiling,
gall@rochcivictheatre.org    my brain IBM" -- Mr Roboto, Styxx

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Success kernel-243pre8-SMP(patch)(Re: spin_lock problem in recent k ernel

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2001-03-30 09:16:41

On Fri, 30 Mar 2001, Kaoru Fukui wrote:
+#ifndef CONFIG_SMP
 	spin_lock(&init_mm.page_table_lock);
+#endif
AFAIK spin_lock() is void when not compiling for SMP, so this is equal to just
removing the call.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help