Re: Regarding consistent_alloc

In message [off-list ref] you wrote:

They only reason that I considered the consistent() routines was
that the 8xx routines are unsuitable for use in modules.

This  is  trivial  to  fix  -  just  add  the  missing  EXPORT_SYMBOL
statements  to  arch/ppc/kernel/ppc_ksyms.c  ;  but be aware that the
current implementation will leak CPM resources upon module  unload  -
which  is probably the main reason that these symbols are not expoted
for use in modules.

I will prepare a patch that deals with the inefficiencies
of the 8xx routines.

Don't re-invent the wheel. There is an implementation  of  this  code
available  in  our  kernel  source tree (linux-2.4 module in our CVS)
which for example provides both m8xx_cpm_dpalloc / m8xx_cpm_dpfree

I sent the patches to Tom Rini. Several times. I don't know why  they
never  made  it into the official kernel source tree. [This is why we
have to maintain our own source tree.]


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The C-shell doesn't parse. It adhoculates.
    - Casper.Dik@Holland.Sun.COM in [off-list ref]

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

Wolfgang Denk wrote:

In message [off-list ref] you wrote:

quoted

They only reason that I considered the consistent() routines was
that the 8xx routines are unsuitable for use in modules.

This  is  trivial  to  fix  -  just  add  the  missing  EXPORT_SYMBOL
statements  to  arch/ppc/kernel/ppc_ksyms.c  ;  but be aware that the
current implementation will leak CPM resources upon module  unload  -
which  is probably the main reason that these symbols are not expoted
for use in modules.

Yes I know, that is one the main deficiencies I'm talking about...

quoted

I will prepare a patch that deals with the inefficiencies
of the 8xx routines.

Don't re-invent the wheel. There is an implementation  of  this  code
available  in  our  kernel  source tree (linux-2.4 module in our CVS)
which for example provides both m8xx_cpm_dpalloc / m8xx_cpm_dpfree

I sent the patches to Tom Rini. Several times. I don't know why  they
never  made  it into the official kernel source tree. [This is why we
have to maintain our own source tree.]


Best regards,

Wolfgang Denk

Could you please sent me these patches, since I'm behind a firewall?

But still there is the matter of the m8xx_cpm_hostalloc routines.

BTW Wolfgang have you seen my patch for the QMC? Any comments?
Please note that I had a few requests for the QMC patch directly
by people off the list, so it's not like no-one is using it...

Regards

--
Pantelis Antoniou
INTRACOM S.A. Greece


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

Hi all

I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?

So far it boots and runs fine but that's no proof.

    Jocke

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

On Thu, Dec 12, 2002 at 09:18:36AM +0100, Wolfgang Denk wrote:

I sent the patches to Tom Rini. Several times. I don't know why  they
never  made  it into the official kernel source tree. [This is why we
have to maintain our own source tree.]

I believe part of the reason is in the list archives somewhere.  If you
can't recall or find exactly why feel free to shoot me an email privately
and I'll remind you.

However, if you're willing to forget about it all and start over, and
will submit changes in the form of a patch which makes only one logical
change at a time, vs linuxppc_2_4 and linuxppc-2.5 trees, I will happily
review and comment or apply patches starting the week of 12/23 (since
I have finals up to and including 12/20).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

At 04:56 AM 12/12/2002, you wrote:

I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?

I haven't tested patch for 2.4.20 but patch for 2.4.19 contained some bugs.


  Eugene Surovegin <mailto:ebs@innocent.com>


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

Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?

According to the message Robert posted on lkm is the 2.4.20-1 patch only a
rediff of the latest 2.4.19 patch.

BTW, I am on the 2_4_devel branch.

   Jocke

At 04:56 AM 12/12/2002, you wrote:

quoted

I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?

I haven't tested patch for 2.4.20 but patch for 2.4.19 contained some bugs.


  Eugene Surovegin <mailto:ebs@innocent.com>

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

Can you be more specific about the "bugs". I just installed the patch. The
patch did not apply cleanly. Is this what you are referring to? It was
simple to fix the rejects.

THX

-----Original Message-----
From: owner-linuxppc-dev@lists.linuxppc.org
[mailto:owner-linuxppc-dev@lists.linuxppc.org]On Behalf Of Eugene
Surovegin
Sent: Thursday, December 12, 2002 10:28 AM
To: joakim.tjernlund@lumentis.se
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: Is the preemptive kernel patch unsafe for 8xx/PPC?



At 04:56 AM 12/12/2002, you wrote:

quoted

I am testing the latest(2.4.20-1) preemtive kernel patch from

Robert Love and

quoted

I wonder if anybody know if it's unsafe/not working for 8xx or

PPC in general?

I haven't tested patch for 2.4.20 but patch for 2.4.19 contained
some bugs.


  Eugene Surovegin <mailto:ebs@innocent.com>

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

The patch did not apply cleanly for me using linuxppc_2_4_devel, BK label
2.4.19 final.
The following files got rejected:
	include/asm-ppc/dma.h
	include/asm-ppc/pgtable.h

It was very straight forward to apply the patches by hand. The line numbers
were a bit off.

Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?

According to the message Robert posted on lkm is the 2.4.20-1 patch only a
rediff of the latest 2.4.19 patch.

BTW, I am on the 2_4_devel branch.

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

Joakim,

At 12:35 PM 12/12/2002, you wrote:

Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?

I had the following issues with 2.4.19-2 (2.4.20-1 is identical in this
regard):

1) arch/ppc/kernel.entry.S

diff -urN linux-2.4.20/arch/ppc/kernel/entry.S linux/arch/ppc/kernel/entry.S

--- linux-2.4.20/arch/ppc/kernel/entry.S        2002-11-28

18:53:11.000000000 -0500

+++ linux/arch/ppc/kernel/entry.S       2002-12-11 02:34:47.000000000 -0500

@@ -278,6 +278,41 @@
          */
         cmpi    0,r3,0
         beq     restore
+#ifdef CONFIG_PREEMPT
+       lwz     r3,PREEMPT_COUNT(r2)
+       cmpi    0,r3,1
+       bge     ret_from_except
+       lwz     r5,_MSR(r1)
+       andi.   r5,r5,MSR_PR
+       bne     do_signal_ret

     <rest of the diff is skipped>

I had to change the last command to "bne ret_from_except".
I checked MontaVista tree, and they have "ret_from_except" there also.

Without this change trivial code:

   while (true) ;

locked the box completely.

2) include/asm-ppc/pgalloc.h  There are curly brackets missing in
get_pgd_fast()

3) to support 440GP you have to modify arc/ppc/kernel/irc.c:preempt_intercept:

#if !defined(CONFIG_4xx) || defined(CONFIG_440)
         case 0x900:
#else
         case 0x1000:
#endif

With these changes (an maybe some others I forgot to mention here :),
I have pretty stable preemptable kernel (2.4.19, PPC440GP & 405GP, also
with rtsched patch by George Anzinger)

Thanks,


  Eugene Surovegin <mailto:ebs@innocent.com>


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

Hi Eugene

This I can not comment on, but my 8xx runs fine with it.

Without this change trivial code:

   while (true) ;

locked the box completely.

2) include/asm-ppc/pgalloc.h  There are curly brackets missing in
get_pgd_fast()

Yes, they are missing in the else part.

3) to support 440GP you have to modify arc/ppc/kernel/irc.c:preempt_intercept:

#if !defined(CONFIG_4xx) || defined(CONFIG_440)
         case 0x900:
#else
         case 0x1000:
#endif

OK, this does not affect 8xx so this I can not test.

With these changes (an maybe some others I forgot to mention here :),
I have pretty stable preemptable kernel (2.4.19, PPC440GP & 405GP, also
with rtsched patch by George Anzinger)

Can you run the above changes by Robert Love so he can comment/update the patch?

 Jocke

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

I ran this patch on 2.4.19 and here were my results.

quoted

1) arch/ppc/kernel.entry.S

diff -urN linux-2.4.20/arch/ppc/kernel/entry.S

linux/arch/ppc/kernel/entry.S

quoted

--- linux-2.4.20/arch/ppc/kernel/entry.S        2002-11-28

18:53:11.000000000 -0500

+++ linux/arch/ppc/kernel/entry.S       2002-12-11

02:34:47.000000000 -0500

quoted

@@ -278,6 +278,41 @@
          */
         cmpi    0,r3,0
         beq     restore
+#ifdef CONFIG_PREEMPT
+       lwz     r3,PREEMPT_COUNT(r2)
+       cmpi    0,r3,1
+       bge     ret_from_except
+       lwz     r5,_MSR(r1)
+       andi.   r5,r5,MSR_PR
+       bne     do_signal_ret

     <rest of the diff is skipped>

I had to change the last command to "bne ret_from_except".
I checked MontaVista tree, and they have "ret_from_except" there also.

This I can not comment on, but my 8xx runs fine with it.

I did not make the above code change and it appears to run. Any comments?

quoted

2) include/asm-ppc/pgalloc.h  There are curly brackets missing in
get_pgd_fast()

Yes, they are missing in the else part.

I had to fix this too.

quoted

3) to support 440GP you have to modify

arc/ppc/kernel/irc.c:preempt_intercept:

quoted

#if !defined(CONFIG_4xx) || defined(CONFIG_440)
         case 0x900:
#else
         case 0x1000:
#endif

I could not test these changes either. Any feedback from Robert Love?

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