headers
Michael L. Hitch | 8 Sep 2006 22:05

Re: NetBSD-current on Amiga?

> >  I'm looking at it, and will hopefully figure out what the problem is and
> > fix it for the 4.0 release.
>
> It's apparently some default in gcc which has changed. Perhaps -m68020
> needs to be explicitely set as the default so that 64 bit operations are
> not generated. The alternative of making -68060 sets isn't very tidy. But
> if anyone wants -m68060 built sets, please let me know.

  I doubt it's anything to do with 64 bit operations - I'm not seeing any
great number of unimplemented instruction traps.

> That was where I was stuck before. I guessed that that was the problem,
> but I didn't have the time to wait for the system to finish booting.
>
> What kind of faults are you seeing mostly?

  They are all pagefaults.

  A quick test during lunch shows this seems to happen after the fork()
when the shell is doing the exec().  It's almost like it's getting write
faults on a read-only page and the page is never getting set to writable
until later.  I think I'm going to add some instrumentation to trap.c
to capture the last N page faults and see what the PC and faulting VA
addresses are for them.

Michael
Permalink | Reply |
headers
Michael L. Hitch | 11 Sep 2006 20:07

Re: NetBSD-current on Amiga?


> > It's apparently some default in gcc which has changed. Perhaps -m68020
> > needs to be explicitely set as the default so that 64 bit operations are
> > not generated. The alternative of making -68060 sets isn't very tidy. But
> > if anyone wants -m68060 built sets, please let me know.
>
>   I doubt it's anything to do with 64 bit operations - I'm not seeing any
> great number of unimplemented instruction traps.

  It is not anything to do with the toolchain.

> > That was where I was stuck before. I guessed that that was the problem,
> > but I didn't have the time to wait for the system to finish booting.
> >
> > What kind of faults are you seeing mostly?
>
>   They are all pagefaults.
>
>   A quick test during lunch shows this seems to happen after the fork()
> when the shell is doing the exec().  It's almost like it's getting write
> faults on a read-only page and the page is never getting set to writable
> until later.  I think I'm going to add some instrumentation to trap.c
> to capture the last N page faults and see what the PC and faulting VA
> addresses are for them.

  Nobody must have running much on an m68060 amiga using -current for
over a year.  I started tracking this back to figure out when the problem
first appeared, and found the exact day.  Sources from 2005-04-01 do not
exhibit the problem, but sources from 2005-04-02 do.  I rather suspected
this change, since comparing the differences between 3.1_RC1 and 4.0_BETA
(Continue reading)

Permalink | Reply |
headers
Michael L. Hitch | 14 Sep 2006 03:37

Re: NetBSD-current on Amiga?


On Mon, 11 Sep 2006, Michael L. Hitch wrote:

>   I'm not all that familiar with the 68060 differences, but it's acting
> like the level 2 segment table entry is not getting updated.  It acts like
> the table entry is not getting written to memory - either the entry is
> never written or it's being written to a cache-enabled page.  I haven't
> yet been able to determine if that's what is happening;  the pmap code
> appears to be doing the correct thing.

  And it was indeed using a cached page for the segment tables.  The uvm
changes resulted in the page allocated for the segment tables to be
entered in a manner that the current method of makeing the page non-cached
no longer works.  I have fixed the amiga pmap to directly change the PTE
bits and my amiga now is quite happy, without excessive faulting.

Michael
Permalink | Reply |
headers
John Klos | 18 Sep 2006 19:35

Re: NetBSD-current on Amiga?

Hi,

>  And it was indeed using a cached page for the segment tables.  The uvm
> changes resulted in the page allocated for the segment tables to be
> entered in a manner that the current method of makeing the page non-cached
> no longer works.  I have fixed the amiga pmap to directly change the PTE
> bits and my amiga now is quite happy, without excessive faulting.

Followup: I was confused about the emulated instruction problem partly 
because a standard netbsd-4 kernel (such as one from NetBSD-daily/netbsd4) 
would basically be unusable, but a kernel compiled with -m68060 doesn't 
exhibit any of the problems you're seeing.

Are your changes in current? I'd like to test them in netbsd-4, if you 
have a list of changed files.

BTW - I still have the time issue where programs which sleep don't wake up 
(top, systat, et cetera). The keyboard doesn't repeat, either. Not sure 
where that is yet. Are you seeing that?

Thanks,
John
Permalink | Reply |
headers
Michael L. Hitch | 24 Sep 2006 20:19

Re: NetBSD-current on Amiga?


On Mon, 18 Sep 2006, John Klos wrote:

> Followup: I was confused about the emulated instruction problem partly
> because a standard netbsd-4 kernel (such as one from NetBSD-daily/netbsd4)
> would basically be unusable, but a kernel compiled with -m68060 doesn't
> exhibit any of the problems you're seeing.

  I suspect that you are actually getting the problems, but with a
different cache footprint, it's not noticable.  In the case where the
cache line gets flushed quickly, you need to have some debug code in
trap.c to detect multiple faults.

> Are your changes in current? I'd like to test them in netbsd-4, if you
> have a list of changed files.

  The changes are in current and have been pulled up to 4.0.
Permalink | Reply |
headers
John Klos | 24 Sep 2006 21:03

Re: NetBSD-current on Amiga?

>> Are your changes in current? I'd like to test them in netbsd-4, if you
>> have a list of changed files.
>
>  The changes are in current and have been pulled up to 4.0.

I'll try a new build as soon as I can. Thanks!
Permalink | Reply |
headers
Ignatios Souvatzis | 18 Sep 2006 21:59
Picon

Re: NetBSD-current on Amiga?

On Mon, Sep 18, 2006 at 10:35:04AM -0700, John Klos wrote:
> Hi,
> 
> > And it was indeed using a cached page for the segment tables.  The uvm
> >changes resulted in the page allocated for the segment tables to be
> >entered in a manner that the current method of makeing the page non-cached
> >no longer works.  I have fixed the amiga pmap to directly change the PTE
> >bits and my amiga now is quite happy, without excessive faulting.
> 
> Followup: I was confused about the emulated instruction problem partly 
> because a standard netbsd-4 kernel (such as one from NetBSD-daily/netbsd4) 
> would basically be unusable, but a kernel compiled with -m68060 doesn't 
> exhibit any of the problems you're seeing.

Wait. A standard GENERIC kernel should be compiled with -m68060
-Wa,-m68020 -Wa,-m68851 (IIRC), unless somebody broke the kernel
Makefile. 

-m68060 is omitted if the 68060 CPU isn't supported.

	-is
--

-- 
seal your e-mail: http://www.gnupg.org/
Permalink | Reply |
headers
Ignatios Souvatzis | 19 Sep 2006 11:38
Picon

Re: NetBSD-current on Amiga?

On Mon, Sep 18, 2006 at 09:59:12PM +0200, Ignatios Souvatzis wrote:
> On Mon, Sep 18, 2006 at 10:35:04AM -0700, John Klos wrote:
> > Hi,
> > 
> > > And it was indeed using a cached page for the segment tables.  The uvm
> > >changes resulted in the page allocated for the segment tables to be
> > >entered in a manner that the current method of makeing the page non-cached
> > >no longer works.  I have fixed the amiga pmap to directly change the PTE
> > >bits and my amiga now is quite happy, without excessive faulting.
> > 
> > Followup: I was confused about the emulated instruction problem partly 
> > because a standard netbsd-4 kernel (such as one from NetBSD-daily/netbsd4) 
> > would basically be unusable, but a kernel compiled with -m68060 doesn't 
> > exhibit any of the problems you're seeing.
> 
> Wait. A standard GENERIC kernel should be compiled with -m68060
> -Wa,-m68020 -Wa,-m68851 (IIRC), unless somebody broke the kernel
> Makefile. 
> 
> -m68060 is omitted if the 68060 CPU isn't supported.

I checked a -current build out of the box, source date 20060907 (top
level Makefile).

Citing from the build window:

/usr/local/sources/cur/src/../tools/bin/m68k--netbsdelf-gcc  -m68060
-Wa,-m68030 -Wa,-m68851 -msoft-float -ffreestanding
-fno-zero-initialized-in-bss   -O2 [...] vers.c
(Continue reading)

Permalink | Reply |
headers
John Klos | 19 Sep 2006 21:07

Re: NetBSD-current on Amiga?

> I checked a -current build out of the box, source date 20060907 (top
> level Makefile).
>
> Citing from the build window:
>
> /usr/local/sources/cur/src/../tools/bin/m68k--netbsdelf-gcc  -m68060
> -Wa,-m68030 -Wa,-m68851 -msoft-float -ffreestanding
> -fno-zero-initialized-in-bss   -O2 [...] vers.c
>
> How exactly did you manage to build a kernel with
> options M68060 but without -m68060?

I was wrong. The difference that seems to matter isn't the -m68060 option, 
but the fact that I'm using gcc 4. When I make a new kernel using  gcc 3 
toolchain, it fails.

I'll play with it some more and report back.

Thanks,
John
--

-- 
Today is the day that my destiny calls me!
   Meowth
Permalink | Reply |
headers
Michael van Elst | 14 Sep 2006 07:21
Picon

Re: NetBSD-current on Amiga?

mhitch <at> gemini.msu.montana.edu ("Michael L. Hitch") writes:

>  And it was indeed using a cached page for the segment tables.  The uvm
>changes resulted in the page allocated for the segment tables to be
>entered in a manner that the current method of makeing the page non-cached
>no longer works.  I have fixed the amiga pmap to directly change the PTE
>bits and my amiga now is quite happy, without excessive faulting.

Would setting NKPTADD=8 make the fault less likely?

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."
Permalink | Reply |
headers
Michael L. Hitch | 14 Sep 2006 07:50

Re: NetBSD-current on Amiga?


On Thu, 14 Sep 2006, Michael van Elst wrote:

> mhitch <at> gemini.msu.montana.edu ("Michael L. Hitch") writes:
>
> >  And it was indeed using a cached page for the segment tables.  The uvm
> >changes resulted in the page allocated for the segment tables to be
> >entered in a manner that the current method of makeing the page non-cached
> >no longer works.  I have fixed the amiga pmap to directly change the PTE
> >bits and my amiga now is quite happy, without excessive faulting.
>
> Would setting NKPTADD=8 make the fault less likely?

  I suspect that anything which changes the data cache usage pattern would
affect it.  If the cache line containing the level 2 segment pointer takes
a long time to get written back to memory, page faults will continue until
the cache line gets written.  If that cache line is indexed by many other
data accesses that occur frequently, it would get written much sooner.

  A real good example is when I added code to keep a history of faults to
the trap routine.  The kernel I ran before the change was taking several
minutes to just get to the single-user shell prompt.  After adding the
debug code, the page faulting was almost unnoticable - until I looked at
the fault history that I had added.

Michael
Permalink | Reply |
headers
John Klos | 14 Sep 2006 01:25

Re: NetBSD-current on Amiga?

>>   I doubt it's anything to do with 64 bit operations - I'm not seeing any
>> great number of unimplemented instruction traps.
>
>  It is not anything to do with the toolchain.

My booboo. I was getting the two problems confused. The toolchain / 
emulated instruction issue is still there, though.

Just curious - what would happen if unimplemented instruction traps 
happened during the handling of the page faults?

Thanks,
John
Permalink | Reply |
headers
Ignatios Souvatzis | 12 Sep 2006 13:36
Picon

Re: NetBSD-current on Amiga?

On Mon, Sep 11, 2006 at 12:07:05PM -0600, Michael L. Hitch wrote:
P
>   I had added code in the trap fault handler to save information about the
> last 256 page faults, and I can see where it gets many page faults that
> have the same program counter, fault address, and fault status longword.
> 
>   I'm not all that familiar with the 68060 differences, but it's acting
> like the level 2 segment table entry is not getting updated. 

ISTR that on 68060, page tables MUST be write-through or uncached, or 
something like that... maybe this condition was broken? I'll look it 
tonight to be sure.

	-is
Permalink | Reply |

Gmane