* 8xx v2.6 TLB problems and suggested workaround
@ 2005-04-04 19:17 Marcelo Tosatti
2005-04-04 20:09 ` Marcelo Tosatti
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Marcelo Tosatti @ 2005-04-04 19:17 UTC (permalink / raw)
To: linux-ppc-embedded, Dan Malek, Pantelis Antoniou; +Cc: Paul Mackerras
(need volunteers to test the patch below on 8xx)
Hi,
I've been investigating the 8xx update_mmu_cache() oops for the last weeks, and
here is what I have gathered.
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C00049E8 LR: C000A5D0 SP: C4F53E10 REGS: c4f53d60 TRAP: 0300 Not taintedMSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 100113A0, DSISR: C2000000
TASK = c53f17e0[1224] 'a' THREAD: c4f52000
Last syscall: 47
GPR00: C783D2A0 C4F53E10 C53F17E0 10050000 00000100 0009F0A0 10050000 00000000
GPR08: 00075925 C783D2A0 C53F17E0 00000000 00076924 10077178 00000000 100B4338
GPR16: 100BBDE8 0ED792CE 7FFFF670 00000000 00000000 00000000 00000000 C4F41100
GPR24: 00000000 C4F3CAD4 C783D2A0 1005078C C4EB9140 C53861D0 04F85889 C034A0A0
NIP [c00049e8] __flush_dcache_icache+0x14/0x40
LR [c000a5d0] update_mmu_cache+0x64/0x98
Call trace:
[c003fa7c] do_no_page+0x2f8/0x370
[c003fc44] handle_mm_fault+0x88/0x160
[c0009b58] do_page_fault+0x168/0x394
[c0002c28] handle_page_fault+0xc/0x80
What is happening here is that update_mmu_cache() calls __flush_dcache_icache()
to sync the d-cache with memory and invalidate any stale i-cache entries for
the address being faulted in.
Problem is that the "dcbst" instruction will, _sometimes_ (the failure/success rate is about 1/4
with my test application) fault as a _write_ operation on the data.
The address in question is always at the very beginning of the read-only data section,
thus the write fault (as can be verified in DSISR: 0x02000000) is rejected
because the vma structure is marked as read-only (vma->flags = ~VM_WRITE).
8xx machines running v2.6 are operating at the moment with a "tlbie()" call at
update_mmu_cache() just before __flush_dcache_icache(), which worksaround the problem.
I've been able to watch the "problematic" TLB entry just before update_mmu_cache().
Here it is:
SPR 824 : 0x10011f0b 268508939
BDI>rds 825
SPR 825 : 0x000001e0 480
BDI>rds 826
SPR 826 : 0x00001f00 7936
As you can see by bit 18 of the D-TLB debugging register MD_RAM1 (SPR 826), this entry
is marked as invalid, which will invocate DataTLBError in case of an access at this point
and handle the fault properly in most cases.
This is expected, and is how the sequence "DataTLBMiss" (no effective address in TLB entry) ->
"DataTLBError" (existant EA but valid bit not set) works on 8xx.
Kumar Gala suggested inspection of memory which holds __flush_dcache_icache().
With the BDI I could verify that the instruction sequence is there, intact.
I'm unable to determine why a "dcbst" fault is incorrectly being treated as a WRITE operation.
That seems to be the real problem. Likely to be Yet Another CPU bug?
I've came up with a workaround which looks acceptable (unlike the tlbie one).
Solution is to jump directly from the data tlb miss exception to DataAccess, which
in turn calls do_page_fault() and friends.
This avoids the dcbst's from being called to sync an address with an "invalid" TLB entry.
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
--- a/arch/ppc/kernel/head_8xx.S.orig 2005-04-04 19:43:23.000000000 -0300
+++ b/arch/ppc/kernel/head_8xx.S 2005-04-04 19:47:40.000000000 -0300
@@ -359,9 +359,7 @@
. = 0x1200
DataStoreTLBMiss:
-#ifdef CONFIG_8xx_CPU6
stw r3, 8(r0)
-#endif
DO_8xx_CPU6(0x3f80, r3)
mtspr M_TW, r10 /* Save a couple of working registers */
mfcr r10
@@ -390,6 +388,16 @@
mfspr r10, MD_TWC /* ....and get the pte address */
lwz r10, 0(r10) /* Get the pte */
+ li r3, 0
+ cmpw r10, r3 /* does the pte contain a valid address? */
+ bne 4f
+ mfspr r10, M_TW /* Restore registers */
+ lwz r11, 0(r0)
+ mtcr r11
+ lwz r11, 4(r0)
+ lwz r3, 8(r0)
+ b DataAccess
+4:
/* Insert the Guarded flag into the TWC from the Linux PTE.
* It is bit 27 of both the Linux PTE and the TWC (at least
* I got that right :-). It will be better when we can put
@@ -419,9 +427,7 @@
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is an instruction TLB error on the MPC8xx. This could be due
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: 8xx v2.6 TLB problems and suggested workaround
2005-04-04 19:17 8xx v2.6 TLB problems and suggested workaround Marcelo Tosatti
@ 2005-04-04 20:09 ` Marcelo Tosatti
2005-04-05 7:08 ` Pantelis Antoniou
2005-04-05 1:11 ` Kumar Gala
2005-04-05 15:58 ` 8xx v2.6 TLB problems and suggested workaround Dan Malek
2 siblings, 1 reply; 9+ messages in thread
From: Marcelo Tosatti @ 2005-04-04 20:09 UTC (permalink / raw)
To: linux-ppc-embedded, Dan Malek, Pantelis Antoniou; +Cc: Paul Mackerras
Hum,
The machine seems to be acting strange, but it boots normally
and applications run (more importantly there is no TLB entry
which could cause dcbst fault strangeness).
Some "dd" hangs till I press "ctrl+c", others just work. Really strange.
G'night, I'll look at it tomorrow.
[root@(none) /]# time dd if=/dev/zero of=file bs=16k count=400
400+0 records in
400+0 records out
real 0m4.261s
user 0m0.040s
sys 0m1.240s
[root@(none) /]# time dd if=/dev/zero of=file bs=32k count=400
real 0m50.369s
user 0m0.040s
sys 0m1.680s (ctrl+c)
[root@(none) /]#
> --- a/arch/ppc/kernel/head_8xx.S.orig 2005-04-04 19:43:23.000000000 -0300
> +++ b/arch/ppc/kernel/head_8xx.S 2005-04-04 19:47:40.000000000 -0300
> @@ -359,9 +359,7 @@
>
> . = 0x1200
> DataStoreTLBMiss:
> -#ifdef CONFIG_8xx_CPU6
> stw r3, 8(r0)
> -#endif
> DO_8xx_CPU6(0x3f80, r3)
> mtspr M_TW, r10 /* Save a couple of working registers */
> mfcr r10
> @@ -390,6 +388,16 @@
> mfspr r10, MD_TWC /* ....and get the pte address */
> lwz r10, 0(r10) /* Get the pte */
>
> + li r3, 0
> + cmpw r10, r3 /* does the pte contain a valid address? */
> + bne 4f
> + mfspr r10, M_TW /* Restore registers */
> + lwz r11, 0(r0)
> + mtcr r11
> + lwz r11, 4(r0)
> + lwz r3, 8(r0)
> + b DataAccess
> +4:
> /* Insert the Guarded flag into the TWC from the Linux PTE.
> * It is bit 27 of both the Linux PTE and the TWC (at least
> * I got that right :-). It will be better when we can put
> @@ -419,9 +427,7 @@
> lwz r11, 0(r0)
> mtcr r11
> lwz r11, 4(r0)
> -#ifdef CONFIG_8xx_CPU6
> lwz r3, 8(r0)
> -#endif
> rfi
>
> /* This is an instruction TLB error on the MPC8xx. This could be due
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: 8xx v2.6 TLB problems and suggested workaround
2005-04-04 20:09 ` Marcelo Tosatti
@ 2005-04-05 7:08 ` Pantelis Antoniou
0 siblings, 0 replies; 9+ messages in thread
From: Pantelis Antoniou @ 2005-04-05 7:08 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
Marcelo Tosatti wrote:
> Hum,
>
> The machine seems to be acting strange, but it boots normally
> and applications run (more importantly there is no TLB entry
> which could cause dcbst fault strangeness).
>
> Some "dd" hangs till I press "ctrl+c", others just work. Really strange.
>
> G'night, I'll look at it tomorrow.
>
> [root@(none) /]# time dd if=/dev/zero of=file bs=16k count=400
> 400+0 records in
> 400+0 records out
>
> real 0m4.261s
> user 0m0.040s
> sys 0m1.240s
> [root@(none) /]# time dd if=/dev/zero of=file bs=32k count=400
>
>
> real 0m50.369s
> user 0m0.040s
> sys 0m1.680s (ctrl+c)
> [root@(none) /]#
>
>
I can confirm that the patch works.
I no longer need the tlbie in update_mmu_cache.
/tmp # time dd if=/dev/zero of=file bs=16k count=400
400+0 records in
400+0 records out
real 0m 0.55s
user 0m 0.01s
sys 0m 0.52s
/tmp is tmpfs
Well done Marcelo!
Regards
Pantelis
P.S. CPU errata perhaps?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 8xx v2.6 TLB problems and suggested workaround
2005-04-04 19:17 8xx v2.6 TLB problems and suggested workaround Marcelo Tosatti
2005-04-04 20:09 ` Marcelo Tosatti
@ 2005-04-05 1:11 ` Kumar Gala
2005-04-05 3:14 ` PPC linux v2.6.11 network configuration hangs Pari Subramaniam
2005-04-05 15:58 ` 8xx v2.6 TLB problems and suggested workaround Dan Malek
2 siblings, 1 reply; 9+ messages in thread
From: Kumar Gala @ 2005-04-05 1:11 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
Marcelo,
One thing would be useful to comment why we are doing this so if it=20
ends up being a CPU errata we at least know why we are doing this.
- kumar
On Apr 4, 2005, at 2:17 PM, Marcelo Tosatti wrote:
> (need volunteers to test the patch below on 8xx)
>
> Hi,
>
> I've been investigating the 8xx update_mmu_cache() oops for the last=20=
> weeks, and
> here is what I have gathered.
>
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C00049E8 LR: C000A5D0 SP: C4F53E10 REGS: c4f53d60 TRAP: 0300=A0=A0=
=A0=20
> Not taintedMSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
>
> DAR: 100113A0, DSISR: C2000000
> TASK =3D c53f17e0[1224] 'a' THREAD: c4f52000
> Last syscall: 47
> GPR00: C783D2A0 C4F53E10 C53F17E0 10050000 00000100 0009F0A0 10050000=20=
> 00000000
> GPR08: 00075925 C783D2A0 C53F17E0 00000000 00076924 10077178 00000000=20=
> 100B4338
> GPR16: 100BBDE8 0ED792CE 7FFFF670 00000000 00000000 00000000 00000000=20=
> C4F41100
> GPR24: 00000000 C4F3CAD4 C783D2A0 1005078C C4EB9140 C53861D0 04F85889=20=
> C034A0A0
> NIP [c00049e8] __flush_dcache_icache+0x14/0x40
> LR [c000a5d0] update_mmu_cache+0x64/0x98
> Call trace:
> =A0[c003fa7c] do_no_page+0x2f8/0x370
> =A0[c003fc44] handle_mm_fault+0x88/0x160
> =A0[c0009b58] do_page_fault+0x168/0x394
> =A0[c0002c28] handle_page_fault+0xc/0x80
>
> What is happening here is that update_mmu_cache() calls=20
> __flush_dcache_icache()
> to sync the d-cache with memory and invalidate any stale i-cache=20
> entries for
> the address being faulted in.
>
> Problem is that the "dcbst" instruction will, _sometimes_ (the=20
> failure/success rate is about 1/4
> with my test application) fault as a _write_ operation on the data.
>
> The address in question is always at the very beginning of the=20
> read-only data section,
> thus the write fault (as can be verified in DSISR: 0x02000000) is=20
> rejected
> because the vma structure is marked as read-only (vma->flags =3D=20
> ~VM_WRITE).
>
> 8xx machines running v2.6 are operating at the moment with a "tlbie()"=20=
> call at
> update_mmu_cache() just before __flush_dcache_icache(), which=20
> worksaround the problem.
>
> I've been able to watch the "problematic" TLB entry just before=20
> update_mmu_cache().
> Here it is:
>
> SPR=A0 824 : 0x10011f0b=A0=A0=A0 268508939
> BDI>rds 825
> SPR=A0 825 : 0x000001e0=A0=A0=A0=A0=A0=A0=A0=A0=A0 480
> BDI>rds 826
> SPR=A0 826 : 0x00001f00=A0=A0=A0=A0=A0=A0=A0=A0 7936
>
> As you can see by bit 18 of the D-TLB debugging register MD_RAM1 (SPR=20=
> 826), this entry
> is marked as invalid, which will invocate DataTLBError in case of an=20=
> access at this point
> and handle the fault properly in most cases.
>
> This is expected, and is how the sequence "DataTLBMiss" (no effective=20=
> address in TLB entry) ->
> "DataTLBError" (existant EA but valid bit not set) works on 8xx.
>
> Kumar Gala suggested inspection of memory which holds=20
> __flush_dcache_icache().
> With the BDI I could verify that the instruction sequence is there,=20
> intact.
>
> I'm unable to determine why a "dcbst" fault is incorrectly being=20
> treated as a WRITE operation.
>
> That seems to be the real problem. Likely to be Yet Another CPU bug?
>
> I've came up with a workaround which looks acceptable (unlike the=20
> tlbie one).
>
> Solution is to jump directly from the data tlb miss exception to=20
> DataAccess, which
> in turn calls do_page_fault() and friends.
>
> This avoids the dcbst's from being called to sync an address with an=20=
> "invalid" TLB entry.
>
> Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>
> --- a/arch/ppc/kernel/head_8xx.S.orig=A0=A0 2005-04-04 =
19:43:23.000000000=20
> -0300
> +++ b/arch/ppc/kernel/head_8xx.S=A0=A0=A0=A0=A0=A0=A0 2005-04-04 =
19:47:40.000000000=20
> -0300
> @@ -359,9 +359,7 @@
> =A0
> =A0=A0=A0=A0=A0=A0=A0 . =3D 0x1200
> =A0DataStoreTLBMiss:
> -#ifdef CONFIG_8xx_CPU6
> =A0=A0=A0=A0=A0=A0=A0 stw=A0=A0=A0=A0 r3, 8(r0)
> -#endif
> =A0=A0=A0=A0=A0=A0=A0 DO_8xx_CPU6(0x3f80, r3)
> =A0=A0=A0=A0=A0=A0=A0 mtspr=A0=A0 M_TW, r10=A0=A0=A0=A0=A0=A0 /* Save =
a couple of working registers=20
> */
> =A0=A0=A0=A0=A0=A0=A0 mfcr=A0=A0=A0 r10
> @@ -390,6 +388,16 @@
> =A0=A0=A0=A0=A0=A0=A0 mfspr=A0=A0 r10, MD_TWC=A0=A0=A0=A0 /* ....and =
get the pte address */
> =A0=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r10, 0(r10)=A0=A0=A0=A0 /* Get =
the pte */
> =A0
> +=A0=A0=A0=A0=A0=A0 li=A0=A0=A0=A0=A0 r3, 0
> +=A0=A0=A0=A0=A0=A0 cmpw=A0=A0=A0 r10, r3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
/* does the pte contain a valid=20
> address? */
> +=A0=A0=A0=A0=A0=A0 bne=A0=A0=A0=A0 4f
> +=A0=A0=A0=A0=A0=A0 mfspr=A0=A0 r10, M_TW=A0=A0=A0=A0=A0=A0 /* Restore =
registers */
> +=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r11, 0(r0)
> +=A0=A0=A0=A0=A0=A0 mtcr=A0=A0=A0 r11
> +=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r11, 4(r0)
> +=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r3, 8(r0)
> +=A0=A0=A0=A0=A0=A0 b DataAccess
> +4:
> =A0=A0=A0=A0=A0=A0=A0 /* Insert the Guarded flag into the TWC from =
the Linux PTE.
> =A0=A0=A0=A0=A0=A0=A0=A0 * It is bit 27 of both the Linux PTE and the =
TWC (at least
> =A0=A0=A0=A0=A0=A0=A0=A0 * I got that right :-).=A0 It will be better =
when we can put
> @@ -419,9 +427,7 @@
> =A0=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r11, 0(r0)
> =A0=A0=A0=A0=A0=A0=A0 mtcr=A0=A0=A0 r11
> =A0=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r11, 4(r0)
> -#ifdef CONFIG_8xx_CPU6
> =A0=A0=A0=A0=A0=A0=A0 lwz=A0=A0=A0=A0 r3, 8(r0)
> -#endif
> =A0=A0=A0=A0=A0=A0=A0 rfi
> =A0
> =A0/* This is an instruction TLB error on the MPC8xx.=A0 This could =
be due
>
>
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply [flat|nested] 9+ messages in thread
* PPC linux v2.6.11 network configuration hangs
2005-04-05 1:11 ` Kumar Gala
@ 2005-04-05 3:14 ` Pari Subramaniam
0 siblings, 0 replies; 9+ messages in thread
From: Pari Subramaniam @ 2005-04-05 3:14 UTC (permalink / raw)
To: 'linux-ppc-embedded'
Hi,
We have 8540 based board running PPC port ver-2.4.30-pre1. when I tried =
to
upgrade to ver-2.6.11, the network interface loops (enabled TSEC alone)
indefinitely in the gfar_probe() at the following while loop:
/* Stop the DMA engine now, in case it was running before */
/* (The firmware could have used it, and left it running). */
/* To do this, we write Graceful Receive Stop and Graceful */
/* Transmit Stop, and then wait until the corresponding bits */
/* in IEVENT indicate the stops have completed. */
tempval =3D gfar_read(&priv->regs->dmactrl);
tempval &=3D ~(DMACTRL_GRS | DMACTRL_GTS);
gfar_write(&priv->regs->dmactrl, tempval);
tempval =3D gfar_read(&priv->regs->dmactrl);
tempval |=3D (DMACTRL_GRS | DMACTRL_GTS);
gfar_write(&priv->regs->dmactrl, tempval);
/*---------------------------------stays in this loop for
ever--------------------------------*/
while (!(gfar_read(&priv->regs->ievent) & (IEVENT_GRSC | =
IEVENT_GTSC)))
cpu_relax();
/*-----------------------------------------------------------------------=
-------
--------------*/
MPC8540 based system running boot loader U-Boot version-1.1.2. The TSEC =
port is
tested from the boot loader. The same behavior observed in all the =
boards.
I appreciate any help in this regard.
Thanks in advance
regards
-pari =20
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 8xx v2.6 TLB problems and suggested workaround
2005-04-04 19:17 8xx v2.6 TLB problems and suggested workaround Marcelo Tosatti
2005-04-04 20:09 ` Marcelo Tosatti
2005-04-05 1:11 ` Kumar Gala
@ 2005-04-05 15:58 ` Dan Malek
2005-04-05 11:41 ` Marcelo Tosatti
2005-04-06 6:00 ` Pantelis Antoniou
2 siblings, 2 replies; 9+ messages in thread
From: Dan Malek @ 2005-04-05 15:58 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
> Problem is that the "dcbst" instruction will, _sometimes_ (the
> failure/success rate is about 1/4
> with my test application) fault as a _write_ operation on the data.
Oh, geeze .... It's all coming back to me now ....
The 8xx cache operations don't always operate as defined in the PEM.
There are likely to be some archive discussions within the Freescale
knowledge data base that describe the different behaviors I've seen
with the chip variants and revisions. I can't find any of those e-mail
discussions, so I'll try to recall from memory.
The PEM cache instructions are all implemented in a microcode that
uses the 8xx unique cache control SPRs. Depending upon the state
of the cache and MMU, it seems in some cases the EA translation is
subject to a "normal" protection match instead of a load operation
match.
The behavior of these operations isn't consistent across all of the 8xx
processor revisions, especially with early silicon if people are still
using those. During conversations with Freescale engineers, it seems
the only guaranteed operation was to use the 8xx unique SPRs, but
I think I only did that in 8xx specific functions.
We have way too much code in the TLB exception handlers already,
so let's just try a tlbia of the EA in the update_mmu_cache, with an
#ifdef
for the 8xx. It seems if the dcbst causes a TLB miss during execution,
it does the right thing. We may want to make the dcbxxx instructions
some
kind of macro, so on 8xx we can include such operations in otherwise
"standard" software.
Thanks for the great work!
-- Dan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 8xx v2.6 TLB problems and suggested workaround
2005-04-05 15:58 ` 8xx v2.6 TLB problems and suggested workaround Dan Malek
@ 2005-04-05 11:41 ` Marcelo Tosatti
2005-04-05 20:26 ` Marcelo Tosatti
2005-04-06 6:00 ` Pantelis Antoniou
1 sibling, 1 reply; 9+ messages in thread
From: Marcelo Tosatti @ 2005-04-05 11:41 UTC (permalink / raw)
To: Dan Malek; +Cc: Paul Mackerras, linux-ppc-embedded
On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote:
>
> On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
>
> >Problem is that the "dcbst" instruction will, _sometimes_ (the
> >failure/success rate is about 1/4
> >with my test application) fault as a _write_ operation on the data.
>
> Oh, geeze .... It's all coming back to me now ....
>
> The 8xx cache operations don't always operate as defined in the PEM.
> There are likely to be some archive discussions within the Freescale
> knowledge data base that describe the different behaviors I've seen
> with the chip variants and revisions. I can't find any of those e-mail
> discussions, so I'll try to recall from memory.
>
> The PEM cache instructions are all implemented in a microcode that
> uses the 8xx unique cache control SPRs. Depending upon the state
> of the cache and MMU, it seems in some cases the EA translation is
> subject to a "normal" protection match instead of a load operation
> match.
>
> The behavior of these operations isn't consistent across all of the 8xx
> processor revisions, especially with early silicon if people are still
> using those. During conversations with Freescale engineers, it seems
> the only guaranteed operation was to use the 8xx unique SPRs, but
> I think I only did that in 8xx specific functions.
How sweet. :)
> We have way too much code in the TLB exception handlers already,
> so let's just try a tlbia of the EA in the update_mmu_cache, with an
> #ifdef
> for the 8xx.
Are you sure this is the best solution ?
Problem is that update_mmu_cache() is called from other context's where
the tlb invalidate is not necessary (because it has already been invalidated).
For example all ptep_set_access_flags() (which does the tlb invalidate) ->
update_mmu_cache() sequences.
Moreover jumping directly from DataTLBMiss to the page fault handler
shortcuts the process: there is no need to jump back to execution if we
know in advance that DataTLBError exception is going to happen.
But hey, you are the boss. Even with the above facts you prefer
to leave the DataTLBMiss untouched?
About size: I think it is the smaller expection handler present.
> It seems if the dcbst causes a TLB miss during execution,
> it does the right thing.
It should always cause a miss because the TLB entry is marked as invalid
(DataTLBMiss just created the invalid TLB entry).
So even when a miss happens, it can do the wrong thing.
Right?
> We may want to make the dcbxxx instructions
> some
> kind of macro, so on 8xx we can include such operations in otherwise
> "standard" software.
I'm a bit lost here: you're talking about the kernel side of things only
or userspace also?
The latter would require "GNU as" dcbxxx macro? Hum...
> Thanks for the great work!
Your help has been invaluable!
I feel very good after many days of debugging pain. :)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 8xx v2.6 TLB problems and suggested workaround
2005-04-05 11:41 ` Marcelo Tosatti
@ 2005-04-05 20:26 ` Marcelo Tosatti
0 siblings, 0 replies; 9+ messages in thread
From: Marcelo Tosatti @ 2005-04-05 20:26 UTC (permalink / raw)
To: Dan Malek; +Cc: Paul Mackerras, linux-ppc-embedded
On Tue, Apr 05, 2005 at 08:41:09AM -0300, Marcelo Tosatti wrote:
> On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote:
> >
> > On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
> >
> > >Problem is that the "dcbst" instruction will, _sometimes_ (the
> > >failure/success rate is about 1/4
> > >with my test application) fault as a _write_ operation on the data.
> >
> > Oh, geeze .... It's all coming back to me now ....
> >
> > The 8xx cache operations don't always operate as defined in the PEM.
> > There are likely to be some archive discussions within the Freescale
> > knowledge data base that describe the different behaviors I've seen
> > with the chip variants and revisions. I can't find any of those e-mail
> > discussions, so I'll try to recall from memory.
> >
> > The PEM cache instructions are all implemented in a microcode that
> > uses the 8xx unique cache control SPRs. Depending upon the state
> > of the cache and MMU, it seems in some cases the EA translation is
> > subject to a "normal" protection match instead of a load operation
> > match.
> >
> > The behavior of these operations isn't consistent across all of the 8xx
> > processor revisions, especially with early silicon if people are still
> > using those. During conversations with Freescale engineers, it seems
> > the only guaranteed operation was to use the 8xx unique SPRs, but
> > I think I only did that in 8xx specific functions.
>
> How sweet. :)
>
> > We have way too much code in the TLB exception handlers already,
> > so let's just try a tlbia of the EA in the update_mmu_cache, with an
> > #ifdef
> > for the 8xx.
>
> Are you sure this is the best solution ?
>
> Problem is that update_mmu_cache() is called from other context's where
> the tlb invalidate is not necessary (because it has already been invalidated).
>
> For example all ptep_set_access_flags() (which does the tlb invalidate) ->
> update_mmu_cache() sequences.
>
> Moreover jumping directly from DataTLBMiss to the page fault handler
> shortcuts the process: there is no need to jump back to execution if we
> know in advance that DataTLBError exception is going to happen.
>
> But hey, you are the boss. Even with the above facts you prefer
> to leave the DataTLBMiss untouched?
>
> About size: I think it is the smaller expection handler present.
Well, you know what you're talking about. Whatever you prefer.
Can we just ask someone to send the _tlbie patch around #ifdef CONFIG_M8XX?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: 8xx v2.6 TLB problems and suggested workaround
2005-04-05 15:58 ` 8xx v2.6 TLB problems and suggested workaround Dan Malek
2005-04-05 11:41 ` Marcelo Tosatti
@ 2005-04-06 6:00 ` Pantelis Antoniou
1 sibling, 0 replies; 9+ messages in thread
From: Pantelis Antoniou @ 2005-04-06 6:00 UTC (permalink / raw)
To: Dan Malek; +Cc: Paul Mackerras, linux-ppc-embedded
Dan Malek wrote:
>
> On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
>
>> Problem is that the "dcbst" instruction will, _sometimes_ (the
>> failure/success rate is about 1/4
>> with my test application) fault as a _write_ operation on the data.
>
>
> Oh, geeze .... It's all coming back to me now ....
>
> The 8xx cache operations don't always operate as defined in the PEM.
> There are likely to be some archive discussions within the Freescale
> knowledge data base that describe the different behaviors I've seen
> with the chip variants and revisions. I can't find any of those e-mail
> discussions, so I'll try to recall from memory.
>
> The PEM cache instructions are all implemented in a microcode that
> uses the 8xx unique cache control SPRs. Depending upon the state
> of the cache and MMU, it seems in some cases the EA translation is
> subject to a "normal" protection match instead of a load operation match.
>
OK, maybe we should make 8xx specifics cache flushing functions, that
use the SPR, and forget about this mess.
However is this problem also triggered by user space? If it is we should
try to maintain compatibility...
> The behavior of these operations isn't consistent across all of the 8xx
> processor revisions, especially with early silicon if people are still
> using those. During conversations with Freescale engineers, it seems
> the only guaranteed operation was to use the 8xx unique SPRs, but
> I think I only did that in 8xx specific functions.
>
> We have way too much code in the TLB exception handlers already,
> so let's just try a tlbia of the EA in the update_mmu_cache, with an #ifdef
> for the 8xx. It seems if the dcbst causes a TLB miss during execution,
> it does the right thing. We may want to make the dcbxxx instructions some
> kind of macro, so on 8xx we can include such operations in otherwise
> "standard" software.
>
> Thanks for the great work!
>
>
> -- Dan
>
>
>
Regards
Pantelis
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-04-06 6:12 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-04 19:17 8xx v2.6 TLB problems and suggested workaround Marcelo Tosatti
2005-04-04 20:09 ` Marcelo Tosatti
2005-04-05 7:08 ` Pantelis Antoniou
2005-04-05 1:11 ` Kumar Gala
2005-04-05 3:14 ` PPC linux v2.6.11 network configuration hangs Pari Subramaniam
2005-04-05 15:58 ` 8xx v2.6 TLB problems and suggested workaround Dan Malek
2005-04-05 11:41 ` Marcelo Tosatti
2005-04-05 20:26 ` Marcelo Tosatti
2005-04-06 6:00 ` Pantelis Antoniou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).