Re: CVS commit: src/sys/arch/m68k/m68k

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

On Sat, 16 Sep 2006 khym%azeotrope.org@localhost wrote:

> On Sat, Sep 16, 2006 at 05:31:13PM +0000, Michael L. Hitch wrote:
> > Uvm changes over 17 months ago resulted in the 68040/060 segment table
> > page being entered with pmap_kenter(), which does not record the mapping
> > in the pv table.  Attempting to inhibit caching of that page as required
> > by the 68060 hardware no longer changes the PTE and caused varying degrees
> > of multiple faulting, sometimes resulting in an unusable system.  Apparently
> > very few people attempted to run a 68060 based system since that change.
> > Fix to to change the caching bits directly rather than using 
> > pmap_changebit().
>
> Is this problem specific to the '060, or would it affect an '040 machine
> too?  I recently got this panic on a Mac Centris 660av (a 68040 machine);
> it doesn't sound related, but I thought I'd check :)

  It's specific to the '060.  The '040 will use the data in the cache,
but the '060 bypasses the cache and uses memory directly.

>
> panic: enter: out of address space

  This is a completely different problem - which I had started working
on earlier this year befor getting sidetracked.  It's a known problem when
attempting to map more memory than can be mapped using the single page for
the level 1 and level 2 segment tables on the '040 and '060.  A
work-around might be to reduce the virtual address space for user space.

--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA