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

[khym%azeotrope.org@localhost]

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 :)

panic: enter: out of address space
Stopped inp id 20850.1 (sh) at  netbsd:cpu_Debugger+0x6: unlk a6
cpu_Debugger(ffffffff,88,247088,5c5dcd8,5c5dcfc) + 6
panic(1abd09,7e0200,17c8000,44020000,44020000) + 118
pmap_enter_ptepage(1e9a3c,44020000) + 3d0
pmap_enter(1e9a3c,44020000,17c8000,3,13) + 158
pmap_enter_ptpage(5a11220,80bb000) + de
pmap_enter(5a11220,80bb000,aa8000,5,20) + 158
uvm_fault_internal(5c9e4c,80be000,1,0) + b94
trap(8,5e2,80be220) + 546
faultstkadj() + 0
-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym%azeotrope.org@localhost |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 30 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++