Low memory problems in 8xx Linux

Low memory problems in 8xx Linux

[Marcus Sundberg]

Hi,

is anybody else experiencing severe problems when free memory gets low
in Linux? And I'm not talking about _out of memory_, just simply low
on RAM...

Even with 96 MB swap on ATA flash, and 26MB of memory in the cache
(ie not really in use), as soon as free pages hit the minimum limit
the system will lock solid. This happens before any swap is starting
to get used, and afterwards the system wont even answer to ping.

At some occasions all processes (including init) will simply crash
with an illegal instruction or segfault, and the kernel seems to
live on.

This happens with kernels 2.2.5, 2.2.10, 2.2.12, 2.2.13, 2.2.14 and
2.2.15pre5 + Rik's boobytrap2 patch, on MBX, ADS, FADS, RPX Lite and
custom boards. (2.2.12 and earlier based on Dan Malek's 2.2.5, 2.2.13
and later based on his 2.2.13).

So, has anyone else experienced problems like this?

//Marcus
--
Signature under construction, please come back later.

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

Re: Low memory problems in 8xx Linux

[Peter Allworth]

Marcus Sundberg wrote:
>
> Hi,
>
> is anybody else experiencing severe problems when free memory gets low
> in Linux? And I'm not talking about _out of memory_, just simply low
> on RAM...

Marcus,

The answer is yes. I first noticed this problem on a proprietary
MPC860T board I've designed (and assumed the fault lay there) but
since then have been able to reproduce it on a Motorola TFADS.
(I've been working with Dan Malek's cllf-2.2.13.)

The good news is I'm pretty sure I have a fix. You've caught me in
the process of learning how to make an official contribution to the
Linux kernel.

Enough of that, on with the problem...

> Even with 96 MB swap on ATA flash, and 26MB of memory in the cache
> (ie not really in use), as soon as free pages hit the minimum limit
> the system will lock solid. This happens before any swap is starting
> to get used, and afterwards the system wont even answer to ping.
>
> At some occasions all processes (including init) will simply crash
> with an illegal instruction or segfault, and the kernel seems to
> live on.

Basically, there are a couple of bugs in the MMU code of the 8xx port.

First, the code assumes that the "write-protected" and "dirty"
attributes of a page can be folded into a single flag. Unfortunately,
when a process forks, the data pages are set up for copy-on-write in
both the parent and child processes so that they can be shared.
This is done by marking those pages "write-protected" which, in the
code as it stands, results in any "dirty" pages being set back to "clean".
Later, when the kernel is trying to free up memory, it wrongly assumes
these pages are unmodified and discards them!

My solution to this problem is as follows. In include/asm-ppc/pgtable.h,
rename 0x0100 (the page changed bit) as _PAGE_HWWRITE and 0x0020 (currently
the write-through cache bit) as _PAGE_DIRTY.
Unfortunately this means the write-through function is lost since there
are no more bits left so, for now, redefine _PAGE_WRITETHRU to be the
same as _PAGE_NO_CACHE. (This is a bit inefficient so the fix is only
temporary.)

The second thing I noticed which doesn't appear to be causing a problem
for now but that probably should be corrected anyway is that the
SET_PAGE_DIR macro should only update the M_TWB register when the destination
task (tsk) is the current one. The i386 implementation includes this check
since, I believe, not having it could result in the current task ending
up with the page directory of another task that is under construction.

I'll send you a patch for the file as soon as I've checked that there
aren't any other files that you need. (I've played around with a few
changes to the TLBMiss code but this is still experimental and doesn't
affect whether the kernel works or not.)

> This happens with kernels 2.2.5, 2.2.10, 2.2.12, 2.2.13, 2.2.14 and
> 2.2.15pre5 + Rik's boobytrap2 patch, on MBX, ADS, FADS, RPX Lite and
> custom boards. (2.2.12 and earlier based on Dan Malek's 2.2.5, 2.2.13
> and later based on his 2.2.13).

You've been busy. I can tell!

Patch file to follow (once I've built it).

Cheers,

PeterA.

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

Re: Low memory problems in 8xx Linux

[Marcus Sundberg]

Peter Allworth <linsol@zeta.org.au> writes:

> Marcus Sundberg wrote:
> > is anybody else experiencing severe problems when free memory gets low
> > in Linux? And I'm not talking about _out of memory_, just simply low
> > on RAM...
>
> Marcus,
>
> The answer is yes. I first noticed this problem on a proprietary
> MPC860T board I've designed (and assumed the fault lay there) but
> since then have been able to reproduce it on a Motorola TFADS.
> (I've been working with Dan Malek's cllf-2.2.13.)
>
> The good news is I'm pretty sure I have a fix. You've caught me in
> the process of learning how to make an official contribution to the
> Linux kernel.

Indeed your fix works just beautifully, thanks a lot!

> My solution to this problem is as follows. In include/asm-ppc/pgtable.h,
> rename 0x0100 (the page changed bit) as _PAGE_HWWRITE and 0x0020 (currently
> the write-through cache bit) as _PAGE_DIRTY.
> Unfortunately this means the write-through function is lost since there
> are no more bits left so, for now, redefine _PAGE_WRITETHRU to be the
> same as _PAGE_NO_CACHE. (This is a bit inefficient so the fix is only
> temporary.)

It's not a real problem as _PAGE_WRITETHRU is not used by any PPC
code, except possibly in some fbcon drivers.

> > This happens with kernels 2.2.5, 2.2.10, 2.2.12, 2.2.13, 2.2.14 and
> > 2.2.15pre5 + Rik's boobytrap2 patch, on MBX, ADS, FADS, RPX Lite and
> > custom boards. (2.2.12 and earlier based on Dan Malek's 2.2.5, 2.2.13
> > and later based on his 2.2.13).
>
> You've been busy. I can tell!

We've had this problem for a long time...
First we thought it was our hardware. Then once things started working
reliably when not low on memory we thought it was just the regular oom
problem discussed on Linux kernel, and we simply fixed it by never
going oom. It was just recently that we discovered that the problem
occured even when there was plenty of RAM that could be freed up.

> My own kernel currently contains modifications that would have made
> the patches confusing so I generated these patches by diffing the originals
> against hand-modified copies of the originals.
> As such, the patches are untested in their current form. :(
> If you have any problems, please let me know.

This hunk won't work in 2.2 kernels:

@@ -1025,8 +1031,22 @@
 	tophys(r21, r21, 0)
 	ori	r21, r21, 1	/* Set valid bit in physical L2 page */
 	mtspr	MD_TWC, r21	/* Load pte table base address */
-	mfspr	r20, MD_TWC	/* ....and get the pte address */
-	lwz	r20, 0(r20)	/* Get the pte */
+	stw	r21, 8(r0)		/* Save a copy of pte base address */
+	mfspr	r21, MD_TWC		/* ....and get the pte address */
+	lwz	r20, 0(r21)			/* Get the pte */
+	andi.	r20, r20, _PAGE_PRESENT		/* Set cr0 if it's invalid */
+	beq	4f				/* Skip update if invalid */
+	mfspr	r20, DSISR			/* Check for store op */
+	andis.	r20, r20, 0x0200		/* If set, indicates store */
+	lwz	r20, 0(r21)			/* Get the pte again */
+	beq	3f
+	ori	r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
+3:
+	ori	r20, r20, _PAGE_ACCESSED	/* Set the accessed flag */
+	stw	r20, 0(r21)			/* Update the pte */
+4:
+	lwz	r20, 0(r21)			/* Get the pte again */
+	lwz	r21, 8(r0)			/* Restore pte base address */

 	/* 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

The code after the "Insert the Guarded flag..." comment is not in
normal kernels so r21 will hold an incorrect value.

Now, we have a quite modified kernel here too, so the code I put
there won't be of use for anyone else (it uses r3), but if I'm not
completely blind this diff should be good against Dan's 2.2.13:

@@ -1025,6 +1031,16 @@
 	tophys(r21, r21, 0)
 	ori	r21, r21, 1	/* Set valid bit in physical L2 page */
 	mtspr	MD_TWC, r21	/* Load pte table base address */
 	mfspr	r21, MD_TWC	/* ....and get the pte address */
-	lwz	r21, 0(r21)	/* Get the pte */
+	lwz	r20, 0(r21)			/* Get the pte */
+	andi.	r20, r20, _PAGE_PRESENT		/* Set cr0 if it's invalid */
+	beq	4f				/* Skip update if invalid */
+	mfspr	r20, DSISR			/* Check for store op */
+	andis.	r20, r20, 0x0200		/* If set, indicates store */
+	lwz	r20, 0(r21)			/* Get the pte again */
+	beq	3f
+	ori	r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
+3:
+	ori	r20, r20, _PAGE_ACCESSED	/* Set the accessed flag */
+	stw	r20, 0(r21)			/* Update the pte */
+4:


//Marcus
--
Signature under construction, please come back later.

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

Re: Low memory problems in 8xx Linux

[Dan Malek]

> Peter Allworth <linsol@zeta.org.au> writes:

> > The good news is I'm pretty sure I have a fix. You've caught me in
> > the process of learning how to make an official contribution to the
> > Linux kernel.

I have already incorporated most of these into 2.3.xx
kernel, and a 2.2.13 version that I will update as a tar file
on a server.

Now, who is the real author of these modifications????  I have
received e-mail from three different people in the past week
providing similar patches against different versions of the kernel.



	-- Dan

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

Re: Low memory problems in 8xx Linux

[Peter Allworth]

Dan Malek wrote:
>
> > Peter Allworth <linsol@zeta.org.au> writes:
>
> > > The good news is I'm pretty sure I have a fix. You've caught me in
> > > the process of learning how to make an official contribution to the
> > > Linux kernel.
>
> I have already incorporated most of these into 2.3.xx
> kernel, and a 2.2.13 version that I will update as a tar file
> on a server.
>
> Now, who is the real author of these modifications????  I have
> received e-mail from three different people in the past week
> providing similar patches against different versions of the kernel.
>
>         -- Dan

Dan,

I can only speak as the author of the patches which I've put on

http://www.zeta.org.au/~linsol

So far I've only forwarded these to Marcus Sundberg for alpha testing and
that was yesterday. I haven't yet had time away from my other work to do a
proper diff against your original cllf-2.2.13 distribution so I just threw
something together for Marcus to allow him to move forward.

Cheers,

PeterA.

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

Re: Low memory problems in 8xx Linux

[duncanp]

Dan,

On  1 Feb, Dan Malek wrote:
> I have already incorporated most of these into 2.3.xx
> kernel, and a 2.2.13 version that I will update as a tar file
> on a server.

would you mind posting a diff against the current 2.2.13 kernel on the
ftp server when you do this as well? we've got a kernel in CVS here (i
imagine plently of others are doing this too), and it would be easier
for us if we can patch it.

Dunk.


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

Re: Low memory problems in 8xx Linux

[Dan Malek]

Peter Allworth wrote:


> So far I've only forwarded these to Marcus Sundberg for alpha testing


I have collected all of the patches, and I am heading off to
Linux World with my PowerBook and an RPX-CLLF 860P.  I'll have
them integrated before I return later this week.  I will also
take the time to regression test the changes.....

There are a couple of other changes that need to be made as
well, and I will add some of the "easier" TLB performance
enhancements.


	-- Dan

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

Re: Low memory problems in 8xx Linux

[Peter Allworth]

duncanp@research.canon.com.au wrote:
>
> Dan,
>
> On  1 Feb, Dan Malek wrote:
> > I have already incorporated most of these into 2.3.xx
> > kernel, and a 2.2.13 version that I will update as a tar file
> > on a server.
>
> would you mind posting a diff against the current 2.2.13 kernel on the
> ftp server when you do this as well? we've got a kernel in CVS here (i
> imagine plently of others are doing this too), and it would be easier
> for us if we can patch it.
>
> Dunk.

Dunk,

If you need the MMU patches straight-away, I've put them on

http://www.zeta.org.au/~linsol

They only work against cllf-2.2.13 for now. Marcus Sundberg has sent
me a revised patch which should work for other 2.2 kernels (caveat emptor).
I'll try to add that asap.

Cheers,

PeterA.

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

Re: Low memory problems in 8xx Linux

[Jesper Skov]

>>>>> "Peter" == Peter Allworth <linsol@zeta.org.au> writes:

Peter> duncanp@research.canon.com.au wrote:
>>  Dan,
>>
>> On 1 Feb, Dan Malek wrote: > I have already incorporated most of
>> these into 2.3.xx > kernel, and a 2.2.13 version that I will update
>> as a tar file > on a server.
>>
>> would you mind posting a diff against the current 2.2.13 kernel on
>> the ftp server when you do this as well? we've got a kernel in CVS
>> here (i imagine plently of others are doing this too), and it would
>> be easier for us if we can patch it.
>>
>> Dunk.

Peter> Dunk,

Peter> If you need the MMU patches straight-away, I've put them on

Peter> http://www.zeta.org.au/~linsol

Peter> They only work against cllf-2.2.13 for now. Marcus Sundberg has
Peter> sent me a revised patch which should work for other 2.2 kernels
Peter> (caveat emptor).  I'll try to add that asap.

Peter and Duncan,

The 2.2.13 patch you posted was slightly (but critically) wrong, if
I'm not mistaken. The value updated in memory was not reloaded into
r21 which is where the code below this snipped expects to find the
value.

This patch should do the trick. At least my kernel seems to work.


--- head.S.orig	Sat Oct 23 00:18:03 1999
+++ head.S	Tue Feb  8 10:34:02 2000
@@ -1024,6 +1024,18 @@
 	ori	r21, r21, 1	/* Set valid bit in physical L2 page */
 	mtspr	MD_TWC, r21	/* Load pte table base address */
 	mfspr	r21, MD_TWC	/* ....and get the pte address */
+	lwz	r20, 0(r21)			/* Get the pte */
+	andi.	r20, r20, _PAGE_PRESENT		/* Set cr0 if it's invalid */
+	beq	4f				/* Skip update if invalid */
+	mfspr	r20, DSISR			/* Check for store op */
+	andis.	r20, r20, 0x0200		/* If set, indicates store */
+	lwz	r20, 0(r21)			/* Get the pte again */
+	beq	3f
+	ori	r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
+3:
+	ori	r20, r20, _PAGE_ACCESSED	/* Set the accessed flag */
+	stw	r20, 0(r21)			/* Update the pte */
+4:
 	lwz	r21, 0(r21)	/* Get the pte */

 	/* Set four subpage valid bits (24, 25, 26, and 27).


An alternative and slighly faster implementation might be to skip the
_PAGE_PRESENT check. Any reason something like this wouldn't work?


 	ori	r21, r21, 1	/* Set valid bit in physical L2 page */
 	mtspr	MD_TWC, r21	/* Load pte table base address */
 	mfspr	r21, MD_TWC	/* ....and get the pte address */
	mfspr	r20, DSISR			/* Check for store op */
	andis.	r20, r20, 0x0200		/* If set, indicates store */
	lwz	r20, 0(r21)			/* Get the pte again */
	beq	3f
	ori	r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
3:
	ori	r20, r20, _PAGE_ACCESSED	/* Set the accessed flag */
	stw	r20, 0(r21)			/* Update the pte */
 	mr	r21, r20	/* Get the pte */


Cheers,
Jesper

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

Re: Low memory problems in 8xx Linux

[Peter Allworth]

Jesper Skov wrote:
>
> >>>>> "Peter" == Peter Allworth <linsol@zeta.org.au> writes:

<snip>

> Peter> If you need the MMU patches straight-away, I've put them on
>
> Peter> http://www.zeta.org.au/~linsol
>
> Peter> They only work against cllf-2.2.13 for now. Marcus Sundberg has
> Peter> sent me a revised patch which should work for other 2.2 kernels
> Peter> (caveat emptor).  I'll try to add that asap.
>
> Peter and Duncan,
>
> The 2.2.13 patch you posted was slightly (but critically) wrong, if
> I'm not mistaken. The value updated in memory was not reloaded into
> r21 which is where the code below this snipped expects to find the
> value.
>
> This patch should do the trick. At least my kernel seems to work.

Jesper,

Which kernel are you using and which patch file?
(Please double-check the readme.txt file.)

My http://www.zeta.org.au/~linsol directory contains two versions of the
patch to head.S. If you are using cllf-2.2.13 which includes the use of
r21 as you've described, then use "head.S-patch".

Marcus Sundberg provided the other file "head.S.non-cllf" which is
for older kernels that used r20 for the pte and didn't do the update
of the GUARDED bit. (I need to change the names in the diff headers
to make this clearer.)

You are wise to be cautious, however.
Neither Marcus (as far as I know) nor I have tested "head.S-non-cllf".
(Also, having just taken a second look at the file, I notice it doesn't
include all of the changes so I'd regard it as informational only.)

As for optimising away the _PAGE_PRESENT test, I haven't thought through
whether that can be done or not. It's a couple of weeks since I made the
change and the whole think is definitely a quick-and-dirty fix
(no pun intended). What I was trying to avoid was making a reference
to a second level page table through an invalid entry in the first level
table. You've prompted me to take another look at this code!

Cheers,

PeterA.

> --- head.S.orig Sat Oct 23 00:18:03 1999
> +++ head.S      Tue Feb  8 10:34:02 2000
> @@ -1024,6 +1024,18 @@
>         ori     r21, r21, 1     /* Set valid bit in physical L2 page */
>         mtspr   MD_TWC, r21     /* Load pte table base address */
>         mfspr   r21, MD_TWC     /* ....and get the pte address */
> +       lwz     r20, 0(r21)                     /* Get the pte */
> +       andi.   r20, r20, _PAGE_PRESENT         /* Set cr0 if it's invalid */
> +       beq     4f                              /* Skip update if invalid */
> +       mfspr   r20, DSISR                      /* Check for store op */
> +       andis.  r20, r20, 0x0200                /* If set, indicates store */
> +       lwz     r20, 0(r21)                     /* Get the pte again */
> +       beq     3f
> +       ori     r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
> +3:
> +       ori     r20, r20, _PAGE_ACCESSED        /* Set the accessed flag */
> +       stw     r20, 0(r21)                     /* Update the pte */
> +4:
>         lwz     r21, 0(r21)     /* Get the pte */
>
>         /* Set four subpage valid bits (24, 25, 26, and 27).
>
> An alternative and slighly faster implementation might be to skip the
> _PAGE_PRESENT check. Any reason something like this wouldn't work?
>
>         ori     r21, r21, 1     /* Set valid bit in physical L2 page */
>         mtspr   MD_TWC, r21     /* Load pte table base address */
>         mfspr   r21, MD_TWC     /* ....and get the pte address */
>         mfspr   r20, DSISR                      /* Check for store op */
>         andis.  r20, r20, 0x0200                /* If set, indicates store */
>         lwz     r20, 0(r21)                     /* Get the pte again */
>         beq     3f
>         ori     r20, r20, _PAGE_DIRTY|_PAGE_HWWRITE /* Set the dirty flags */
> 3:
>         ori     r20, r20, _PAGE_ACCESSED        /* Set the accessed flag */
>         stw     r20, 0(r21)                     /* Update the pte */
>         mr      r21, r20        /* Get the pte */
>
> Cheers,
> Jesper

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

more Re: Low memory problems in 8xx Linux

[Peter Allworth]

Jesper Skov wrote:

<snip>

> An alternative and slighly faster implementation might be to skip the
> _PAGE_PRESENT check. Any reason something like this wouldn't work?

<snip>

I had another look at the code and I now remember my rationale for
the _PAGE_PRESENT test. It wasn't to do with level 1 table entries,
Dan's code already takes care of that. It was so that a zeroed pte
couldn't get changed to a non-zero value, since that would make the
pte_none() function return the wrong result. (Moreover, it just seemed
wrong to mess with something that's marked "invalid".)

Admittedly I'm being a bit paranoid since the next thing the exception
handler is likely to do is set the page table entry to something valid.
But, can you be sure? What about a segmentation fault? ;)

Cheers,

PeterA.

"I've always considered a paranoid as a man with all the facts."
	-- Tales of Ordinary Madness

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

Re: more Re: Low memory problems in 8xx Linux

[Dan Malek]

Just a note to let you guys know you are getting just a little
carried away here.....

You are placing things in the TLB specific handler that are
supposed to be handled generically in places like arch/ppc/mm/fault.c.

Yes, it may be a little bit of a speed improvement, but you
are placing code in the TLB miss handler that logically should
be executed as part of the TLB Error handler.  In some cases,
it is appropriate to store something in the TLB that will cause
a subsequent fault into the TLB Error handler (i.e. a pte that
doesn't look valid).  If you continue down this path, you will
end up exceeding the space allocated for the trap handler, and
simply re-implement code found elsewhere.

While some of the updates are genuine bugs that should be corrected,
some of the other stuff isn't proper, so don't be surprised when
it doesn't show up in the real kernel sources.



	-- Dan

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

Re: more Re: Low memory problems in 8xx Linux

[Jesper Skov]

>>>>> "Peter" == Peter Allworth <linsol@zeta.org.au> writes:

Peter> Jesper Skov wrote: <snip>

>> An alternative and slighly faster implementation might be to skip
>> the _PAGE_PRESENT check. Any reason something like this wouldn't
>> work?

Peter> <snip>

Peter> I had another look at the code and I now remember my rationale
Peter> for the _PAGE_PRESENT test. It wasn't to do with level 1 table
Peter> entries, Dan's code already takes care of that. It was so that
Peter> a zeroed pte couldn't get changed to a non-zero value, since
Peter> that would make the pte_none() function return the wrong
Peter> result. (Moreover, it just seemed wrong to mess with something
Peter> that's marked "invalid".)

Peter> Admittedly I'm being a bit paranoid since the next thing the
Peter> exception handler is likely to do is set the page table entry
Peter> to something valid.  But, can you be sure? What about a
Peter> segmentation fault? ;)

No, sounds sensible.

Jesper

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

Re: Low memory problems in 8xx Linux

[Jesper Skov]

>>>>> "Peter" == Peter Allworth <linsol@zeta.org.au> writes:

Peter> Jesper Skov wrote:
>>  >>>>> "Peter" == Peter Allworth <linsol@zeta.org.au> writes:

Peter> <snip>

Peter> If you need the MMU patches straight-away, I've put them on
>>
Peter> http://www.zeta.org.au/~linsol
>>
Peter> They only work against cllf-2.2.13 for now. Marcus Sundberg has
Peter> sent me a revised patch which should work for other 2.2 kernels
Peter> (caveat emptor).  I'll try to add that asap.
>>  Peter and Duncan,
>>
>> The 2.2.13 patch you posted was slightly (but critically) wrong, if
>> I'm not mistaken. The value updated in memory was not reloaded into
>> r21 which is where the code below this snipped expects to find the
>> value.
>>
>> This patch should do the trick. At least my kernel seems to work.

Peter> Jesper,

Peter> Which kernel are you using and which patch file?  (Please
Peter> double-check the readme.txt file.)

I was assuming one of the patches was for
ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/mpc8xx-2.2.13.tgz, but
I don't think either matches very well.

Peter> My http://www.zeta.org.au/~linsol directory contains two
Peter> versions of the patch to head.S. If you are using cllf-2.2.13
Peter> which includes the use of r21 as you've described, then use
Peter> "head.S-patch".

Peter> Marcus Sundberg provided the other file "head.S.non-cllf" which
Peter> is for older kernels that used r20 for the pte and didn't do
Peter> the update of the GUARDED bit. (I need to change the names in
Peter> the diff headers to make this clearer.)

I read the patch and think I understand what's going on, but I don't
see where the GUARDED bits comes in. Maybe I'm missing some subtlety
from other patches (cllf?) and should not use the code at all. I'd
better back it out.

Jesper

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

Re: Low memory problems in 8xx Linux

[Peter Allworth]

Jesper Skov wrote:

<snip>

> I read the patch and think I understand what's going on, but I don't
> see where the GUARDED bits comes in. Maybe I'm missing some subtlety
> from other patches (cllf?) and should not use the code at all. I'd
> better back it out.
>
> Jesper
>

Apologies for being vague. I have a head-cold and my brain seems to be
on vacation. :(

The guarded flag doesn't appear in the patch but in

cllf-2.2.13/arch/ppc/kernel/head.S
(from Dan's distribution for the Classic Lite Low Fat board)

near where the head.S-patch is applied.

Somewhere in the DataStoreTLBMiss routine, I think, you'll see the comment:

/* Insert the Guarded flag into the TWC from the Linux PTE.
<snip>
*/

This is one of the areas where cllf-2.2.13 differs from mpc8xx-2.2.13.

HTH,

PeterA.

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

Residual data

[Claude Robitaille]

hi,


anyone knows where to find a complete reference for the "residual data
standard"?

Thanks

Claude


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

Re: Residual data

[Gabriel Paubert]

On Wed, 22 Mar 2000, Claude Robitaille wrote:

>
> hi,
>
>
> anyone knows where to find a complete reference for the "residual data
> standard"?

Yes, they are somewhere on an IBM site (ftp.austin.ibm.com ?). But dno't
believe what you find in the residual data,  it's often wrong and needs
to be "interpreted".

	Gabriel.


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