mpc880 linux-2.6.32 slow running processes

mpc880 linux-2.6.32 slow running processes

[Rafael Beims]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

Hello all,
I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
some work, I could get the kernel up and running, mounting a rootfs via
NFS.
The problem that I'm facing now is that when I try to run any process (may
be an ls, cat, or whatever), the response of the process is *very* slow
(something like 10 to 20 seconds for a ls).
Monitoring the network packets, I can see that the nfs protocol is exchanged
just fine, but at some time it simply stops, starting again with a request
from the board several seconds later.
I'm thinking that the processor is running (something, I don't know what)
for all this time before I can see requests coming from the board again. I
pinged the board from the PC and during all this I can see the packets being
answered.

My question to all is, did anyone see something like this already? Besides
that, what is the status of the linux kernel support for the 8xx platform?
Is it being actively tested / used today? I ask this because it seems that
all the information on the internet very aged (forum discussions from 2005
and below mostly).

Is there something that I can do to try to narrow the cause of the problem?

Anyway, any help would be truly appreciated. Please excuse me if this is not
the right place to ask this too.

Thanks and best regards,
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I
understand."
- Chinese Proverb

[-- Attachment #2: Type: text/html, Size: 1703 bytes --]

Re: mpc880 linux-2.6.32 slow running processes

[michael]

[-- Attachment #1.1: Type: text/plain, Size: 1758 bytes --]

Hi

On 01/05/2011 07:09 PM, Rafael Beims wrote:
> Hello all,
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.
> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).
> Monitoring the network packets, I can see that the nfs protocol is exchanged
> just fine, but at some time it simply stops, starting again with a request
> from the board several seconds later.
> I'm thinking that the processor is running (something, I don't know what)
> for all this time before I can see requests coming from the board again. I
> pinged the board from the PC and during all this I can see the packets being
> answered.
>
Can you try this patch?

> My question to all is, did anyone see something like this already? Besides
> that, what is the status of the linux kernel support for the 8xx platform?
> Is it being actively tested / used today? I ask this because it seems that
> all the information on the internet very aged (forum discussions from 2005
> and below mostly).
>
> Is there something that I can do to try to narrow the cause of the problem?
>
> Anyway, any help would be truly appreciated. Please excuse me if this is not
> the right place to ask this too.
>
> Thanks and best regards,
> Rafael Beims
> rbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


[-- Attachment #1.2: Type: text/html, Size: 2624 bytes --]

[-- Attachment #2: slowdown.patch --]
[-- Type: text/x-diff, Size: 2703 bytes --]

diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index dd5ea95..cb67076 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -32,7 +32,7 @@
 #define _PAGE_FILE	0x0002	/* when !present: nonlinear file mapping */
 #define _PAGE_NO_CACHE	0x0002	/* I: cache inhibit */
 #define _PAGE_SHARED	0x0004	/* No ASID (context) compare */
-#define _PAGE_SPECIAL	0x0008	/* SW entry, forced to 0 by the TLB miss */
+#define _PAGE_SPECIAL	0x0000	/* SW entry, forced to 0 by the TLB miss */
 
 /* These five software bits must be masked out when the entry is loaded
  * into the TLB.
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index f2b3701..3b88376 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -176,5 +176,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
 #define HAVE_PAGE_AGP
 
 /* Advertise support for _PAGE_SPECIAL */
+#if _PAGE_SPECIAL != 0
 #define __HAVE_ARCH_PTE_SPECIAL
+#endif
 
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 5304093..1da03a8 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
 	pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
 	if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
 				       cpu_has_feature(CPU_FTR_NOEXECUTE))) {
-		struct page *pg = maybe_pte_to_page(pte);
-		if (!pg)
+		unsigned long pfn = pte_pfn(pte);
+		struct page *pg;
+
+		if (unlikely(!pfn_valid(pfn)))
 			return pte;
-		if (!test_bit(PG_arch_1, &pg->flags)) {
+
+		pg = pfn_to_page(pfn);
 #ifdef CONFIG_8xx
-			/* On 8xx, cache control instructions (particularly
-			 * "dcbst" from flush_dcache_icache) fault as write
-			 * operation if there is an unpopulated TLB entry
-			 * for the address in question. To workaround that,
-			 * we invalidate the TLB here, thus avoiding dcbst
-			 * misbehaviour.
-			 */
-			/* 8xx doesn't care about PID, size or ind args */
-			_tlbil_va(addr, 0, 0, 0);
+		/* On 8xx, cache control instructions (particularly
+		 * "dcbst" from flush_dcache_icache) fault as write
+		 * operation if there is an unpopulated TLB entry
+		 * for the address in question. To workaround that,
+		 * we invalidate the TLB here, thus avoiding dcbst
+		 * misbehaviour.
+		 */
+		/* 8xx doesn't care about PID, size or ind args */
+		_tlbil_va(addr, 0, 0, 0);
 #endif /* CONFIG_8xx */
+
+		if (!pg)
+			return pte;
+
+		if (!PageReserved(pg) && !test_bit(PG_arch_1, &pg->flags)) {
 			flush_dcache_icache_page(pg);
 			set_bit(PG_arch_1, &pg->flags);
 		}

Fwd: mpc880 linux-2.6.32 slow running processes

[Rafael Beims]

[-- Attachment #1: Type: text/plain, Size: 2494 bytes --]

I forgot to copy the list, sorry...

---------- Forwarded message ----------
From: Rafael Beims <rbeims@gmail.com>
Date: Wed, Jan 5, 2011 at 4:43 PM
Subject: Re: mpc880 linux-2.6.32 slow running processes
To: michael <michael@evidence.eu.com>


Wow! That was fast!
I applied the patch and it worked very well. Now I can use the commands
normally.
I will be doing more tests in the next days, but it seems that my problem is
solved.

Is this patch already mainstream in newer kernel versions?

Thanks again,

Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I
understand."
- Chinese Proverb


On Wed, Jan 5, 2011 at 4:23 PM, michael <michael@evidence.eu.com> wrote:

>  Hi
>
> On 01/05/2011 07:09 PM, Rafael Beims wrote:
>
> Hello all,
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.
> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).
> Monitoring the network packets, I can see that the nfs protocol is exchanged
> just fine, but at some time it simply stops, starting again with a request
> from the board several seconds later.
> I'm thinking that the processor is running (something, I don't know what)
> for all this time before I can see requests coming from the board again. I
> pinged the board from the PC and during all this I can see the packets being
> answered.
>
>
>  Can you try this patch?
>
>  My question to all is, did anyone see something like this already? Besides
> that, what is the status of the linux kernel support for the 8xx platform?
> Is it being actively tested / used today? I ask this because it seems that
> all the information on the internet very aged (forum discussions from 2005
> and below mostly).
>
> Is there something that I can do to try to narrow the cause of the problem?
>
> Anyway, any help would be truly appreciated. Please excuse me if this is not
> the right place to ask this too.
>
> Thanks and best regards,
> Rafael Beimsrbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
>
> _______________________________________________
> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>

[-- Attachment #2: Type: text/html, Size: 3732 bytes --]

Re: mpc880 linux-2.6.32 slow running processes

[michael]

Hi

On 01/05/2011 07:43 PM, Rafael Beims wrote:
> Wow! That was fast!
> I applied the patch and it worked very well. Now I can use the commands
> normally.
> I will be doing more tests in the next days, but it seems that my problem is
> solved.
>
> Is this patch already mainstream in newer kernel versions?
>
Not yet, because I was moved to another project

Michael Trimarchi
> Thanks again,
> Rafael Beims
> rbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
> On Wed, Jan 5, 2011 at 4:23 PM, michael<michael@evidence.eu.com>  wrote:
>
>>   Hi
>>
>> On 01/05/2011 07:09 PM, Rafael Beims wrote:
>>
>> Hello all,
>> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
>> some work, I could get the kernel up and running, mounting a rootfs via
>> NFS.
>> The problem that I'm facing now is that when I try to run any process (may
>> be an ls, cat, or whatever), the response of the process is *very* slow
>> (something like 10 to 20 seconds for a ls).
>> Monitoring the network packets, I can see that the nfs protocol is exchanged
>> just fine, but at some time it simply stops, starting again with a request
>> from the board several seconds later.
>> I'm thinking that the processor is running (something, I don't know what)
>> for all this time before I can see requests coming from the board again. I
>> pinged the board from the PC and during all this I can see the packets being
>> answered.
>>
>>
>>   Can you try this patch?
>>
>>   My question to all is, did anyone see something like this already? Besides
>> that, what is the status of the linux kernel support for the 8xx platform?
>> Is it being actively tested / used today? I ask this because it seems that
>> all the information on the internet very aged (forum discussions from 2005
>> and below mostly).
>>
>> Is there something that I can do to try to narrow the cause of the problem?
>>
>> Anyway, any help would be truly appreciated. Please excuse me if this is not
>> the right place to ask this too.
>>
>> Thanks and best regards,
>> Rafael Beimsrbeims@gmail.com
>> (41) 8873-7565
>> "What I hear, I forget. What I see, I remember. And what I do, I
>> understand."
>> - Chinese Proverb
>>
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>

Re: mpc880 linux-2.6.32 slow running processes

[Scott Wood]

On Wed, 5 Jan 2011 19:23:33 +0100
michael <michael@evidence.eu.com> wrote:

> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
> index dd5ea95..cb67076 100644
> --- a/arch/powerpc/include/asm/pte-8xx.h
> +++ b/arch/powerpc/include/asm/pte-8xx.h
> @@ -32,7 +32,7 @@
>  #define _PAGE_FILE	0x0002	/* when !present: nonlinear file mapping */
>  #define _PAGE_NO_CACHE	0x0002	/* I: cache inhibit */
>  #define _PAGE_SHARED	0x0004	/* No ASID (context) compare */
> -#define _PAGE_SPECIAL	0x0008	/* SW entry, forced to 0 by the TLB miss */
> +#define _PAGE_SPECIAL	0x0000	/* SW entry, forced to 0 by the TLB miss */

What do you think is going wrong with the special bit on 8xx?

Or might the change to set_pte_filter() alone be what fixed the problem?

> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index 5304093..1da03a8 100644
> --- a/arch/powerpc/mm/pgtable.c
> +++ b/arch/powerpc/mm/pgtable.c
> @@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
>  	pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
>  	if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
>  				       cpu_has_feature(CPU_FTR_NOEXECUTE))) {
> -		struct page *pg = maybe_pte_to_page(pte);
> -		if (!pg)
> +		unsigned long pfn = pte_pfn(pte);
> +		struct page *pg;
> +
> +		if (unlikely(!pfn_valid(pfn)))
>  			return pte;
> -		if (!test_bit(PG_arch_1, &pg->flags)) {
> +
> +		pg = pfn_to_page(pfn);
>  #ifdef CONFIG_8xx
> -			/* On 8xx, cache control instructions (particularly
> -			 * "dcbst" from flush_dcache_icache) fault as write
> -			 * operation if there is an unpopulated TLB entry
> -			 * for the address in question. To workaround that,
> -			 * we invalidate the TLB here, thus avoiding dcbst
> -			 * misbehaviour.
> -			 */
> -			/* 8xx doesn't care about PID, size or ind args */
> -			_tlbil_va(addr, 0, 0, 0);
> +		/* On 8xx, cache control instructions (particularly
> +		 * "dcbst" from flush_dcache_icache) fault as write
> +		 * operation if there is an unpopulated TLB entry
> +		 * for the address in question. To workaround that,
> +		 * we invalidate the TLB here, thus avoiding dcbst
> +		 * misbehaviour.
> +		 */
> +		/* 8xx doesn't care about PID, size or ind args */
> +		_tlbil_va(addr, 0, 0, 0);
>  #endif /* CONFIG_8xx */
> +
> +		if (!pg)
> +			return pte;
> +
> +		if (!PageReserved(pg) && !test_bit(PG_arch_1, &pg->flags)) {
>  			flush_dcache_icache_page(pg);
>  			set_bit(PG_arch_1, &pg->flags);
>  		}

Rex, do you recall under what specific circumstances the _tlbil_va is
needed?  Is it possible that it will be caused by a dcbst in other
contexts that are not dependent on the state of PG_arch_1?

-Scott

Re: mpc880 linux-2.6.32 slow running processes

[michael]

Hi

On 01/06/2011 12:42 AM, Scott Wood wrote:
> On Wed, 5 Jan 2011 19:23:33 +0100
> michael<michael@evidence.eu.com>  wrote:
>
>> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
>> index dd5ea95..cb67076 100644
>> --- a/arch/powerpc/include/asm/pte-8xx.h
>> +++ b/arch/powerpc/include/asm/pte-8xx.h
>> @@ -32,7 +32,7 @@
>>   #define _PAGE_FILE	0x0002	/* when !present: nonlinear file mapping */
>>   #define _PAGE_NO_CACHE	0x0002	/* I: cache inhibit */
>>   #define _PAGE_SHARED	0x0004	/* No ASID (context) compare */
>> -#define _PAGE_SPECIAL	0x0008	/* SW entry, forced to 0 by the TLB miss */
>> +#define _PAGE_SPECIAL	0x0000	/* SW entry, forced to 0 by the TLB miss */
> What do you think is going wrong with the special bit on 8xx?
>
> Or might the change to set_pte_filter() alone be what fixed the problem?
>
Only the set_pte_filter doesn't fix the problem. The slow-down depends on
the __HAVE_ARCH_PTE_SPECIAL related code, but 2 months ago I didn't find the reason
and now I don't have the architecture. I will do some tests when I will came back in Italy.
>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>> index 5304093..1da03a8 100644
>> --- a/arch/powerpc/mm/pgtable.c
>> +++ b/arch/powerpc/mm/pgtable.c
>> @@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
>>   	pte = __pte(pte_val(pte)&  ~_PAGE_HPTEFLAGS);
>>   	if (pte_looks_normal(pte)&&  !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
>>   				       cpu_has_feature(CPU_FTR_NOEXECUTE))) {
>> -		struct page *pg = maybe_pte_to_page(pte);
>> -		if (!pg)
>> +		unsigned long pfn = pte_pfn(pte);
>> +		struct page *pg;
>> +
>> +		if (unlikely(!pfn_valid(pfn)))
>>   			return pte;
>> -		if (!test_bit(PG_arch_1,&pg->flags)) {
>> +
>> +		pg = pfn_to_page(pfn);
>>   #ifdef CONFIG_8xx
>> -			/* On 8xx, cache control instructions (particularly
>> -			 * "dcbst" from flush_dcache_icache) fault as write
>> -			 * operation if there is an unpopulated TLB entry
>> -			 * for the address in question. To workaround that,
>> -			 * we invalidate the TLB here, thus avoiding dcbst
>> -			 * misbehaviour.
>> -			 */
>> -			/* 8xx doesn't care about PID, size or ind args */
>> -			_tlbil_va(addr, 0, 0, 0);
>> +		/* On 8xx, cache control instructions (particularly
>> +		 * "dcbst" from flush_dcache_icache) fault as write
>> +		 * operation if there is an unpopulated TLB entry
>> +		 * for the address in question. To workaround that,
>> +		 * we invalidate the TLB here, thus avoiding dcbst
>> +		 * misbehaviour.
>> +		 */
>> +		/* 8xx doesn't care about PID, size or ind args */
>> +		_tlbil_va(addr, 0, 0, 0);
>>   #endif /* CONFIG_8xx */
>> +
>> +		if (!pg)
>> +			return pte;
>> +
>> +		if (!PageReserved(pg)&&  !test_bit(PG_arch_1,&pg->flags)) {
>>   			flush_dcache_icache_page(pg);
>>   			set_bit(PG_arch_1,&pg->flags);
>>   		}
> Rex, do you recall under what specific circumstances the _tlbil_va is
> needed?  Is it possible that it will be caused by a dcbst in other
> contexts that are not dependent on the state of PG_arch_1?
>
> -Scott
>
Michael

Re: mpc880 linux-2.6.32 slow running processes

[Joakim Tjernlund]

>>> +  /* On 8xx, cache control instructions (particularly
>>> +   * "dcbst" from flush=5Fdcache=5Ficache) fault as write
>>> +   * operation if there is an unpopulated TLB entry
>>> +   * for the address in question. To workaround that,
>>> +   * we invalidate the TLB here, thus avoiding dcbst
>>> +   * misbehaviour.
>>> +   */
>>> +  /* 8xx doesn't care about PID, size or ind args */
>>> +  =5Ftlbil=5Fva(addr, 0, 0, 0);
>>>   #endif /* CONFIG=5F8xx */
>>> +
>>> +  if (!pg)
>>> +   return pte;
>>> +
>>> +  if (!PageReserved(pg)&&  !test=5Fbit(PG=5Farch=5F1,&pg->flags)) {
>>>      flush=5Fdcache=5Ficache=5Fpage(pg);
>>>      set=5Fbit(PG=5Farch=5F1,&pg->flags);
>>>     }
>> Rex, do you recall under what specific circumstances the =5Ftlbil=5Fva is
>> needed?  Is it possible that it will be caused by a dcbst in other
>> contexts that are not dependent on the state of PG=5Farch=5F1?

The 8xx tlbil=5Fva should not be needed in recent 2.6 after I fixed the 8xx=
 TLB code
to workaround the dcbst bug there instead. See=20
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcomm=
itdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98c3=
7d03a4a7c5a3f8b1e3b8e5

Not sure what release it went into though.

 Jocke=
=

Re: mpc880 linux-2.6.32 slow running processes

[Rafael Beims]

On Thu, Jan 6, 2011 at 2:52 PM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:

>
> The 8xx tlbil_va should not be needed in recent 2.6 after I fixed the 8xx=
 TLB code
> to workaround the dcbst bug there instead. See
> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dco=
mmitdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98=
c37d03a4a7c5a3f8b1e3b8e5
>
> Not sure what release it went into though.
>
> =A0Jocke

I saw that the commit you mention did make it in the 2.6.33 version. I
will try to boot it here and see if the problem is also solved in this
version.

Rafael

Re: mpc880 linux-2.6.32 slow running processes

[Joakim Tjernlund]

Rafael Beims <rbeims@gmail.com> wrote on 2011/01/07 11:00:56:
>
> On Thu, Jan 6, 2011 at 2:52 PM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
>
> >
> > The 8xx tlbil_va should not be needed in recent 2.6 after I fixed t=
he 8xx TLB code
> > to workaround the dcbst bug there instead. See
> > http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;=
a=3Dcommitdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071=
fee994ff98c37d03a4a7c5a3f8b1e3b8e5
> >
> > Not sure what release it went into though.
> >
> > =A0Jocke
>
> I saw that the commit you mention did make it in the 2.6.33 version. =
I
> will try to boot it here and see if the problem is also solved in thi=
s
> version.

Once you have tested it and it works, please send a patch to remove the=
 8xx workaround.
Make sure Scott is cc:ed=

Re: mpc880 linux-2.6.32 slow running processes

[Rafael Beims]

>
> Once you have tested it and it works, please send a patch to remove the 8xx workaround.
> Make sure Scott is cc:ed
>
>

I tested linux-2.6.33 on my ppc880 board today, and even without the
slowdown.patch applied, the board runs processes with good
performance.
It really seems that the problem is solved from linux-2.6.33 on.

I'm not sure what you mean by sending a patch to remove the
workaround. The only thing that I did in the 2.6.32 version was to
apply the slowdown.patch attached in the message from Michael.

Could you clarify please?

Thanks for all the help so far,
Rafael

Re: mpc880 linux-2.6.32 slow running processes

[Joakim Tjernlund]

Rafael Beims <rbeims@gmail.com> wrote on 2011/01/10 17:35:38:
> >
> > Once you have tested it and it works, please send a patch to remove the 8xx workaround.
> > Make sure Scott is cc:ed
> >
> >
>
> I tested linux-2.6.33 on my ppc880 board today, and even without the
> slowdown.patch applied, the board runs processes with good
> performance.
> It really seems that the problem is solved from linux-2.6.33 on.
>
> I'm not sure what you mean by sending a patch to remove the
> workaround. The only thing that I did in the 2.6.32 version was to
> apply the slowdown.patch attached in the message from Michael.
>
> Could you clarify please?

Yes, this part in arch/powerpc/mm/pgtable.c:
#ifdef CONFIG_8xx
			/* On 8xx, cache control instructions (particularly
			 * "dcbst" from flush_dcache_icache) fault as write
			 * operation if there is an unpopulated TLB entry
			 * for the address in question. To workaround that,
			 * we invalidate the TLB here, thus avoiding dcbst
			 * misbehaviour.
			 */
			/* 8xx doesn't care about PID, size or ind args */
			_tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */

Should be removed in >= 2.6.33 kernels.
My 8xx TLB work fixes this problem more efficiently.

    Jocke

Re: mpc880 linux-2.6.32 slow running processes

[Joakim Tjernlund]

> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
>
> Rafael Beims <rbeims@gmail.com> wrote on 2011/01/10 17:35:38:
> > >
> > > Once you have tested it and it works, please send a patch to remove the 8xx workaround.
> > > Make sure Scott is cc:ed
> > >
> > >
> >
> > I tested linux-2.6.33 on my ppc880 board today, and even without the
> > slowdown.patch applied, the board runs processes with good
> > performance.
> > It really seems that the problem is solved from linux-2.6.33 on.
> >
> > I'm not sure what you mean by sending a patch to remove the
> > workaround. The only thing that I did in the 2.6.32 version was to
> > apply the slowdown.patch attached in the message from Michael.
> >
> > Could you clarify please?
>
> Yes, this part in arch/powerpc/mm/pgtable.c:
> #ifdef CONFIG_8xx
>          /* On 8xx, cache control instructions (particularly
>           * "dcbst" from flush_dcache_icache) fault as write
>           * operation if there is an unpopulated TLB entry
>           * for the address in question. To workaround that,
>           * we invalidate the TLB here, thus avoiding dcbst
>           * misbehaviour.
>           */
>          /* 8xx doesn't care about PID, size or ind args */
>          _tlbil_va(addr, 0, 0, 0);
> #endif /* CONFIG_8xx */
>
> Should be removed in >= 2.6.33 kernels.
> My 8xx TLB work fixes this problem more efficiently.

Can you test these 2 patches on recent 2.6 linux:
>From 9024200169bf86b4f34cb3b1ebf68e0056237bc0 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 11 Jan 2011 13:43:42 +0100
Subject: [PATCH 1/2] powerpc: Move 8xx invalidation of non present TLBs

8xx does not invalidate ~PRESENT TLBs, move the workaround
in mm/fault.c here to keep 8xx quirks localized and expedite
the invalidation faster.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/powerpc/kernel/head_8xx.S |   12 ++++++++++--
 arch/powerpc/mm/fault.c        |    6 ------
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 1f1a04b..6cd99e2 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -221,7 +221,11 @@ DataAccess:
 	stw	r10,_DSISR(r11)
 	mr	r5,r10
 	mfspr	r4,SPRN_DAR
-	li	r10,0x00f0
+	/* invalidate ~PRESENT TLBs, 8xx MMU don't do this */
+	andis.	r10,r5,0x4000
+	beq+	1f
+	tlbie	r4
+1:	li	r10,0x00f0
 	mtspr	SPRN_DAR,r10	/* Tag DAR, to be used in DTLB Error */
 	EXC_XFER_EE_LITE(0x300, handle_page_fault)

@@ -234,7 +238,11 @@ InstructionAccess:
 	EXCEPTION_PROLOG
 	mr	r4,r12
 	mr	r5,r9
-	EXC_XFER_EE_LITE(0x400, handle_page_fault)
+	/* invalidate ~PRESENT TLBs, 8xx MMU don't do this */
+	andis.	r10,r5,0x4000
+	beq+	1f
+	tlbie	r4
+1:	EXC_XFER_EE_LITE(0x400, handle_page_fault)

 /* External interrupt */
 	EXCEPTION(0x500, HardwareInterrupt, do_IRQ, EXC_XFER_LITE)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 1bd712c..31226c8 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -247,12 +247,6 @@ good_area:
 		goto bad_area;
 #endif /* CONFIG_6xx */
 #if defined(CONFIG_8xx)
-	/* 8xx sometimes need to load a invalid/non-present TLBs.
-	 * These must be invalidated separately as linux mm don't.
-	 */
-	if (error_code & 0x40000000) /* no translation? */
-		_tlbil_va(address, 0, 0, 0);
-
         /* The MPC8xx seems to always set 0x80000000, which is
          * "undefined".  Of those that can be set, this is the only
          * one which seems bad.
--
1.7.3.4


and

>From 0ef93601290a75b087495dddeee6062a870f1dc6 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 11 Jan 2011 13:55:22 +0100
Subject: [PATCH 2/2] powerpc: Remove 8xx redundant dcbst workaround.

On 8xx dcbst fault as write operation if there is an unpopulated TLB entry
for the address in question. There is as of commit
0a2ab51ffb8dfdf51402dcfb446629648c96bc78,
powerpc/8xx: Fixup DAR from buggy dcbX instructions
a better workaround in the TLB error handler so this bad
one can be removed.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/powerpc/mm/pgtable.c |   11 -----------
 1 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index ebc2f38..d3f47a6 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -185,17 +185,6 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
 		if (!pg)
 			return pte;
 		if (!test_bit(PG_arch_1, &pg->flags)) {
-#ifdef CONFIG_8xx
-			/* On 8xx, cache control instructions (particularly
-			 * "dcbst" from flush_dcache_icache) fault as write
-			 * operation if there is an unpopulated TLB entry
-			 * for the address in question. To workaround that,
-			 * we invalidate the TLB here, thus avoiding dcbst
-			 * misbehaviour.
-			 */
-			/* 8xx doesn't care about PID, size or ind args */
-			_tlbil_va(addr, 0, 0, 0);
-#endif /* CONFIG_8xx */
 			flush_dcache_icache_page(pg);
 			set_bit(PG_arch_1, &pg->flags);
 		}
--
1.7.3.4

Re: mpc880 linux-2.6.32 slow running processes

[Heiko Schocher]

Hello Joakim,

Joakim Tjernlund wrote:
>> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
>>
>> Rafael Beims <rbeims@gmail.com> wrote on 2011/01/10 17:35:38:
>>>> Once you have tested it and it works, please send a patch to remove the 8xx workaround.
>>>> Make sure Scott is cc:ed
>>>>
>>>>
>>> I tested linux-2.6.33 on my ppc880 board today, and even without the
>>> slowdown.patch applied, the board runs processes with good
>>> performance.
>>> It really seems that the problem is solved from linux-2.6.33 on.
>>>
>>> I'm not sure what you mean by sending a patch to remove the
>>> workaround. The only thing that I did in the 2.6.32 version was to
>>> apply the slowdown.patch attached in the message from Michael.
>>>
>>> Could you clarify please?
>> Yes, this part in arch/powerpc/mm/pgtable.c:
>> #ifdef CONFIG_8xx
>>          /* On 8xx, cache control instructions (particularly
>>           * "dcbst" from flush_dcache_icache) fault as write
>>           * operation if there is an unpopulated TLB entry
>>           * for the address in question. To workaround that,
>>           * we invalidate the TLB here, thus avoiding dcbst
>>           * misbehaviour.
>>           */
>>          /* 8xx doesn't care about PID, size or ind args */
>>          _tlbil_va(addr, 0, 0, 0);
>> #endif /* CONFIG_8xx */
>>
>> Should be removed in >= 2.6.33 kernels.
>> My 8xx TLB work fixes this problem more efficiently.
> 
> Can you test these 2 patches on recent 2.6 linux:
>>From 9024200169bf86b4f34cb3b1ebf68e0056237bc0 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Tue, 11 Jan 2011 13:43:42 +0100
> Subject: [PATCH 1/2] powerpc: Move 8xx invalidation of non present TLBs
[...]
> and
> 
>>From 0ef93601290a75b087495dddeee6062a870f1dc6 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Tue, 11 Jan 2011 13:55:22 +0100
> Subject: [PATCH 2/2] powerpc: Remove 8xx redundant dcbst workaround.

Tested this on a board similliar to the mainline tqm8xx board with
lmbench:

-bash-3.2# cat /proc/cpuinfo
processor       : 0
cpu             : 8xx
clock           : 80.000000MHz
revision        : 0.0 (pvr 0050 0000)
bogomips        : 10.00
timebase        : 5000000
platform        : KUP4K
model           : KUP4K
Memory          : 96 MB
-bash-3.2#

-bash-3.2# cat /proc/version
Linux version 2.6.34-00064-g3e81b6b (hs@pollux.denx.de) (gcc version 4.2.2) #89 Thu Jan 20 08:39:52 CET 2011
-bash-3.2#

(First run of lmbench without your 2 patches, the two other runs with it)

-bash-3.2# make see
cd results && make summary >summary.out 2>summary.errs
cd results && make percent >percent.out 2>percent.errs
-bash-3.2# cat results/summary.out
make[1]: Entering directory `/home/hs/lmbench-3.0-a9/results'

                 L M B E N C H  3 . 0   S U M M A R Y
                 ------------------------------------
                 (Alpha software, do not distribute)

Basic system parameters
------------------------------------------------------------------------------
Host                 OS Description              Mhz  tlb  cache  mem   scal
                                                     pages line   par   load
                                                           bytes
--------- ------------- ----------------------- ---- ----- ----- ------ ----
kup4k     Linux 2.6.34-       powerpc-linux-gnu   79    28    16 1.1400    1
kup4k     Linux 2.6.34-       powerpc-linux-gnu   79    28    16 1.0200    1
kup4k     Linux 2.6.34-       powerpc-linux-gnu   79    28    16 1.1000    1

Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
kup4k     Linux 2.6.34-   79 2.58 12.3 126. 1285 353. 22.8 149. 8418 34.K 101K
kup4k     Linux 2.6.34-   79 2.59 13.1 127. 1273 320. 23.4 127. 8251 33.K 100K
kup4k     Linux 2.6.34-   79 2.47 13.1 127. 1288 315. 23.6 128. 8413 34.K 101K

Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr
                          bit   add    mul    div    mod
--------- ------------- ------ ------ ------ ------ ------
kup4k     Linux 2.6.34-   12.6   14.4 1.3500  103.9  170.6
kup4k     Linux 2.6.34-   13.2   15.0 1.3100  100.0  170.5
kup4k     Linux 2.6.34-   13.2   14.4 1.2900  104.1  162.1

Basic uint64 operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS int64  int64  int64  int64  int64
                         bit    add    mul    div    mod
--------- ------------- ------ ------ ------ ------ ------
kup4k     Linux 2.6.34-    12.          11.1 1637.9 1602.4
kup4k     Linux 2.6.34-    13.          11.1 1643.6 1604.2
kup4k     Linux 2.6.34-    13.          11.1 1639.7 1600.8

Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------
kup4k     Linux 2.6.34-  840.5 1304.3 4593.3 8703.0
kup4k     Linux 2.6.34-  843.5 1366.6 4601.7 8814.0
kup4k     Linux 2.6.34-  807.8 1377.5 4610.0 8710.0

Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------
kup4k     Linux 2.6.34- 1309.2 2235.2 3132.2  13.9K
kup4k     Linux 2.6.34- 1252.0 2339.0 2993.8  13.9K
kup4k     Linux 2.6.34- 1311.2 2335.2 2997.2  13.9K

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
kup4k     Linux 2.6.34-  131.8  144.7  130.8  168.4  207.8   190.7   248.1
kup4k     Linux 2.6.34-  129.4  142.4  140.8  186.4  211.1   187.0   257.9
kup4k     Linux 2.6.34-  121.3  155.6  131.0  196.8  201.5   198.5   240.7

*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
kup4k     Linux 2.6.34- 131.8 444.2 771. 1024.       1432.       3876
kup4k     Linux 2.6.34- 129.4 455.2 722. 1021.       1434.       3831
kup4k     Linux 2.6.34- 121.3 458.8 761. 1004.       1435.       3866

*Remote* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS   UDP  RPC/  TCP   RPC/ TCP
                               UDP         TCP  conn
--------- ------------- ----- ----- ----- ----- ----
kup4k     Linux 2.6.34-
kup4k     Linux 2.6.34-
kup4k     Linux 2.6.34-

File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
kup4k     Linux 2.6.34-  16.7K  10.3K  90.9K  13.7K   22.6K  27.1    43.4 117.9
kup4k     Linux 2.6.34-  16.9K  15.6K 100.0K  16.1K   22.7K 9.590    39.8 119.2
kup4k     Linux 2.6.34-  16.7K  13.5K 100.0K  15.9K   22.8K 9.306    39.8 119.6

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
kup4k     Linux 2.6.34- 13.3 13.3 11.0   18.3   49.5   23.7   23.3 49.5  35.5
kup4k     Linux 2.6.34- 13.2 13.4 10.8   18.4   49.5   23.4   23.2 49.5  35.4
kup4k     Linux 2.6.34- 13.1 13.2 11.0   18.3   49.5   23.7   23.4 49.5  35.5

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
kup4k     Linux 2.6.34-    79   26.4  278.6       277.0      1145.6    No L2 cache?
kup4k     Linux 2.6.34-    79   26.4  278.7       277.1      1147.1    No L2 cache?
kup4k     Linux 2.6.34-    79   26.4  278.8       276.6      1146.9    No L2 cache?
make[1]: Leaving directory `/home/hs/lmbench-3.0-a9/results'
-bash-3.2#

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: mpc880 linux-2.6.32 slow running processes

[Joakim Tjernlund]

Heiko Schocher <hs@denx.de> wrote on 2011/01/21 07:53:02:
> Hello Joakim,
>
> Joakim Tjernlund wrote:
> >> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
> >>
> >> Rafael Beims <rbeims@gmail.com> wrote on 2011/01/10 17:35:38:
> >>>> Once you have tested it and it works, please send a patch to remove the 8xx workaround.
> >>>> Make sure Scott is cc:ed
> >>>>
> >>>>
> >>> I tested linux-2.6.33 on my ppc880 board today, and even without the
> >>> slowdown.patch applied, the board runs processes with good
> >>> performance.
> >>> It really seems that the problem is solved from linux-2.6.33 on.
> >>>
> >>> I'm not sure what you mean by sending a patch to remove the
> >>> workaround. The only thing that I did in the 2.6.32 version was to
> >>> apply the slowdown.patch attached in the message from Michael.
> >>>
> >>> Could you clarify please?
> >> Yes, this part in arch/powerpc/mm/pgtable.c:
> >> #ifdef CONFIG_8xx
> >>          /* On 8xx, cache control instructions (particularly
> >>           * "dcbst" from flush_dcache_icache) fault as write
> >>           * operation if there is an unpopulated TLB entry
> >>           * for the address in question. To workaround that,
> >>           * we invalidate the TLB here, thus avoiding dcbst
> >>           * misbehaviour.
> >>           */
> >>          /* 8xx doesn't care about PID, size or ind args */
> >>          _tlbil_va(addr, 0, 0, 0);
> >> #endif /* CONFIG_8xx */
> >>
> >> Should be removed in >= 2.6.33 kernels.
> >> My 8xx TLB work fixes this problem more efficiently.
> >
> > Can you test these 2 patches on recent 2.6 linux:
> >>From 9024200169bf86b4f34cb3b1ebf68e0056237bc0 Mon Sep 17 00:00:00 2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Tue, 11 Jan 2011 13:43:42 +0100
> > Subject: [PATCH 1/2] powerpc: Move 8xx invalidation of non present TLBs
> [...]
> > and
> >
> >>From 0ef93601290a75b087495dddeee6062a870f1dc6 Mon Sep 17 00:00:00 2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Tue, 11 Jan 2011 13:55:22 +0100
> > Subject: [PATCH 2/2] powerpc: Remove 8xx redundant dcbst workaround.
>
> Tested this on a board similliar to the mainline tqm8xx board with
> lmbench:
>
> -bash-3.2# cat /proc/cpuinfo
> processor       : 0
> cpu             : 8xx
> clock           : 80.000000MHz
> revision        : 0.0 (pvr 0050 0000)
> bogomips        : 10.00
> timebase        : 5000000
> platform        : KUP4K
> model           : KUP4K
> Memory          : 96 MB
> -bash-3.2#
>
> -bash-3.2# cat /proc/version
> Linux version 2.6.34-00064-g3e81b6b (hs@pollux.denx.de) (gcc version 4.2.2) #89 Thu Jan 20 08:39:52 CET 2011
> -bash-3.2#
>
> (First run of lmbench without your 2 patches, the two other runs with it)

Thanks,

>From a quick look, the only thing that really stands out is Prot Fault below:

> File & VM system latencies in microseconds - smaller is better
> -------------------------------------------------------------------------------
> Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
>                         Create Delete Create Delete Latency Fault  Fault  selct
> --------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
> kup4k     Linux 2.6.34-  16.7K  10.3K  90.9K  13.7K   22.6K  27.1    43.4 117.9
> kup4k     Linux 2.6.34-  16.9K  15.6K 100.0K  16.1K   22.7K 9.590    39.8 119.2
> kup4k     Linux 2.6.34-  16.7K  13.5K 100.0K  15.9K   22.8K 9.306    39.8 119.6

Anyhow, nothing broke so I am happy with the results.

On top of those 2 patches I came up with this cleanup patch too:

>From 920c236b290ee00d84506369e3898126c78215e8 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 18 Jan 2011 09:50:09 +0100
Subject: [PATCH 3/3] powerpc: Use symbolic constants in 8xx TLB asm

Use the PTE #defines where possible instead of
hardcoded constants.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/powerpc/kernel/head_8xx.S |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 6cd99e2..31ed813 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -451,11 +451,11 @@ DataStoreTLBMiss:
 	 * this into the Linux pgd/pmd and load it in the operation
 	 * above.
 	 */
-	rlwimi	r11, r10, 0, 27, 27
+	rlwimi	r11, r10, 0, _PAGE_GUARDED
 	/* Insert the WriteThru flag into the TWC from the Linux PTE.
 	 * It is bit 25 in the Linux PTE and bit 30 in the TWC
 	 */
-	rlwimi	r11, r10, 32-5, 30, 30
+	rlwimi	r11, r10, 32-5, _PAGE_WRITETHRU>>5
 	DO_8xx_CPU6(0x3b80, r3)
 	mtspr	SPRN_MD_TWC, r11

@@ -474,10 +474,10 @@ DataStoreTLBMiss:
 	rlwimi	r10, r11, 0, _PAGE_PRESENT
 #endif
 	/* Honour kernel RO, User NA */
-	/* 0x200 == Extended encoding, bit 22 */
-	rlwimi	r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */
+	/* 0x200 == Encoding, bit 22 */
+	rlwimi	r10, r10, 32-2, _PAGE_USER>>2  /* Copy USER to Encoding */
 	/* r11 =  (r10 & _PAGE_RW) >> 1 */
-	rlwinm	r11, r10, 32-1, 0x200
+	rlwinm	r11, r10, 32-1, _PAGE_RW>>1
 	or	r10, r11, r10
 	/* invert RW and 0x200 bits */
 	xori	r10, r10, _PAGE_RW | 0x200
--
1.7.3.4

Re: mpc880 linux-2.6.32 slow running processes

[Wolfgang Denk]

Dear Rafael Beims,

In message <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com> you wrote:
>
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.

2.6.32 is pretty old.  Is there any specific reason for not using a
recent kernel version?

> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).

This sounds as if only the output to the (serial ?) console port was
slow - typically this happens when there is a problem with interrupt
assignment, and you receive charatcers only after each of these times
out.

> My question to all is, did anyone see something like this already? Besides

We have seen this many times in the past, when interrupts were not
working correctly.  I recommend to check youyr device tree settings
for these.

[It would have helped if you had included a log of your kernel's boot
messages.]

> that, what is the status of the linux kernel support for the 8xx platform?

It is working and actively maintained, but 8xx is a platform that is
more or less hopelessly obsoleted - nobody uses it in new designs any
more, so there is little work going on with it in recent kernel
versions (at least compared with other architectures).

> Is it being actively tested / used today? I ask this because it seems that

Yes, it is.

> all the information on the internet very aged (forum discussions from 2005
> and below mostly).

> Is there something that I can do to try to narrow the cause of the problem?

Check your interrupts.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.

Re: mpc880 linux-2.6.32 slow running processes

[Rafael Beims]

Hello Mr. Denk

As I already posted, the patch that was posted before seems to have
solved the problem. Anyway, some answers follow:

On Wed, Jan 5, 2011 at 4:35 PM, Wolfgang Denk <wd@denx.de> wrote:
>
> Dear Rafael Beims,
>
> In message <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com>=
 you wrote:
> >
> > I'm working with an MPC880 board that is supposed to run linux-2.6.32. =
After
> > some work, I could get the kernel up and running, mounting a rootfs via
> > NFS.
>
> 2.6.32 is pretty old. =A0Is there any specific reason for not using a
> recent kernel version?
>

The company that I work for uses some kernel versions in favor of
others... Maybe with time we can change that, but for now I need to
use this version.

> > The problem that I'm facing now is that when I try to run any process (=
may
> > be an ls, cat, or whatever), the response of the process is *very* slow
> > (something like 10 to 20 seconds for a ls).
>
> This sounds as if only the output to the (serial ?) console port was
> slow - typically this happens when there is a problem with interrupt
> assignment, and you receive charatcers only after each of these times
> out.
>
> > My question to all is, did anyone see something like this already? Besi=
des
>
> We have seen this many times in the past, when interrupts were not
> working correctly. =A0I recommend to check youyr device tree settings
> for these.
>
> [It would have helped if you had included a log of your kernel's boot
> messages.]
>
> > that, what is the status of the linux kernel support for the 8xx platfo=
rm?
>
> It is working and actively maintained, but 8xx is a platform that is
> more or less hopelessly obsoleted - nobody uses it in new designs any
> more, so there is little work going on with it in recent kernel
> versions (at least compared with other architectures).
>
> > Is it being actively tested / used today? I ask this because it seems t=
hat
>
> Yes, it is.

This is very nice, because this way we can be more confident that
everything will work as it should.

>
> > all the information on the internet very aged (forum discussions from 2=
005
> > and below mostly).
>
> > Is there something that I can do to try to narrow the cause of the prob=
lem?
>
> Check your interrupts.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Never underestimate the power of human stupidity =A0when =A0it =A0comes =
=A0to
> using technology they don't understand.

Thank you very much for the answers!

Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I understand=
."
- Chinese Proverb

Re: mpc880 linux-2.6.32 slow running processes

[michael]

Hi

On 01/05/2011 07:35 PM, Wolfgang Denk wrote:
> Dear Rafael Beims,
>
> In message<AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com>  you wrote:
>> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
>> some work, I could get the kernel up and running, mounting a rootfs via
>> NFS.
> 2.6.32 is pretty old.  Is there any specific reason for not using a
> recent kernel version?
>

I think that all the kernel version has the same problem

>> The problem that I'm facing now is that when I try to run any process (may
>> be an ls, cat, or whatever), the response of the process is *very* slow
>> (something like 10 to 20 seconds for a ls).
> This sounds as if only the output to the (serial ?) console port was
> slow - typically this happens when there is a problem with interrupt
> assignment, and you receive charatcers only after each of these times
> out.
>

It is not a serial/console/interrupt problem

>> My question to all is, did anyone see something like this already? Besides
> We have seen this many times in the past, when interrupts were not
> working correctly.  I recommend to check youyr device tree settings
> for these.
>
> [It would have helped if you had included a log of your kernel's boot
> messages.]
>
>> that, what is the status of the linux kernel support for the 8xx platform?
> It is working and actively maintained, but 8xx is a platform that is
> more or less hopelessly obsoleted - nobody uses it in new designs any
> more, so there is little work going on with it in recent kernel
> versions (at least compared with other architectures).
>

agree, this architecture is basically dead

>> Is it being actively tested / used today? I ask this because it seems that
> Yes, it is.
>
>> all the information on the internet very aged (forum discussions from 2005
>> and below mostly).
>> Is there something that I can do to try to narrow the cause of the problem?
> Check your interrupts.
>
> Best regards,
>
> Wolfgang Denk
>

Michael Trimarchi