The mac68k port has implemented MACHINE_NONCONTIG. Is someone working on an
implementation of this for the sun3 port? I cannot do it myself because I'am
not intimate with the low level code of the sun3 port. I need this option
to be implemented before starting the development of a driver for my sun3/50
black and white memory frame buffer(bwtwo).

The frame buffer divides the physical memory of the SUN 3/50 in two
parts. The following applies:

     device bwtwo0 at obmem 2 csr 0x100000 priority 4

---

Yesterday, using my own compiled kernel, I noticed the following problem:

hilton# ps
panic: pmap_enter_kernel: found unknown pmeg      
Stopped at  _Debugger+0x6:  unlk    a6
db> trace
_Debugger(e013970,e05ff42,ffe5be0,6,ffe5c08) + 6
_panic(e05ff42,e05ff1d,0) + 34
_pmap_enter_kernel(e0c8000,10c000,7,0,c0000086,0) + 102
_pmap_enter(e08cac8,e0c8000,10c000,7,0) + b4
_vm_fault(e0e2000,e0c8000,1,0) + 888
_trap(8,145,e0c9a04) + 360
sun3_mmu_specific(?)
_uiomove(e0c9a04,4,ffe5f20) + 3c
_mmrw(301,ffe5f20,0) + 1f8
_spec_read(ffe5ec8,4,ffe5ee4,e028ac6,ffe5ec8) + b4
_nfsspec_read(ffe5ec8,0,4,dc,0) + 3e
_vn_read(e51f600,ffe5f20,e522c00) + 96
_read(e4fc200,ffe5f80,ffe5f78) + a2
_syscall(3) + 148
_trap0() + e

In this case the value of pmeg_owner is listed as 0.

Both ps and kvm_mkdb cause this specific panic. Gordon's kernel has no
problem whatsoever running these programs! What's wrong?

---

The sun3-port is still plagued by this damned SIGSEGV problem.

I used both my "own" kernel and "netbsd-le0", that has been put on
"sun-lamp" by Gordon.

My kernel is much smaller and therefore the problem doesn't show up
as frequently as with the kernel produced by GWR. My kernel
is small for the following reasons:

    - used gcc-2.6.0 with -O2 option

    - No SCSI stuff

    - SUN 3/50 only

The following output is produced by the size program for
the respective kernels.

netbsd:
text    data    bss dec hex
400528  106960  62800   570288  8b3b0

netbsd-le0:
text    data    bss dec hex
691768  117896  63128   872792  d5158

This is what I did to produce the error:

mount -u /
mount /usr

Note: At this point I'am still running single-user mode!

This is the moment I start a make of zsh. The following is not specific
to building the zsh binary or the compiler that is being used. After
rebooting one can continue the 'make' and finally after some SIGSEGV,
one gets a ready to run zsh binary!

After the succesful compilation of several files, the segmentation violation
error suddenly pops up.

trap: SIGSEGV pid=12, code=141, v=4, pc=12938, sr=14
Stopped at  _Debugger+0x6:  unlk    a6
db> ps/w
  pid  proc    addr      uid    ppid  pgrp    flag stat comm         wchan
   12 e4fd000  ebf0000   0     3    12  004006  2 make
    3 e4fd200  ebea000   0     1     3  004086  3 sh   wait e4fd200
    2 e4fd400  ebe4000   0     0     0  000204  3 pagedaemon  thrd_sleep 
e08acb4
    1 e4fd600  ebde000   0     0     1  004084  3 init   wait e4fd600
    0 e081570  ffe6000   0     0     0  000204  3 swapper  scheduler e081570
db> 

This is another one!!!
======================
trap: SIGSEGV pid=14, code=151, v=0, pc=206cce2, sr=15
Stopped at  _Debugger+0x6:  unlk    a6
db> trace
_Debugger(e06247b,e062473,e,151,0,206cce2,15) + 6
_trap(8,151,0) + 42c
sun3_mmu_specific() + 3c
db> ps/w
  pid  proc    addr      uid    ppid  pgrp    flag stat comm         wchan
   14 e4fd000  ebf0000   0     3    14  004006  2 make
    3 e4fd200  ebea000   0     1     3  004086  3 sh   wait e4fd200
    2 e4fd400  ebe4000   0     0     0  000204  3 pagedaemon  thrd_sleep 
e08acb4
    1 e4fd600  ebde000   0     0     1  004084  3 init   wait e4fd600
    0 e081570  ffe6000   0     0     0  000204  3 swapper  scheduler e081570
db> 

And another
===========
trap: SIGSEGV pid=11, code=141, v=ef024cbc, pc=207206a, sr=18
Stopped at  _Debugger+0x6:  unlk    a6
db> trace
_Debugger(e06247b,e062473,b,141,ef024cbc,207206a,18) + 6
_trap(8,141,ef024cbc) + 42c
sun3_mmu_specific() + 3c
db> ps/w
  pid  proc    addr      uid    ppid  pgrp    flag stat comm         wchan
   11 e4fd000  ebf0000   0     3    11  004006  2 make
    3 e4fd200  ebea000   0     1     3  004086  3 sh   wait e4fd200
    2 e4fd400  ebe4000   0     0     0  000204  3 pagedaemon  thrd_sleep 
e08acb4
    1 e4fd600  ebde000   0     0     1  004084  3 init   wait e4fd600
    0 e081570  ffe6000   0     0     0  000204  3 swapper
db>  show map
e04c31fvm_fault(e0e2000, 64350000, 1, 0) at 20000e04 -> 1
  type 8, code [mmu,,ssw]: 145
trap type 8, code = 145, v = 64350070
pid = 11, pc= 0E04C468, ps = 2000, sfc = 0003, dfc = 0003
Registers:

dreg: ...
areg: ....

Kernel stack (0FFE5BB0):
FE5BB0: ...
...
FE5D90: ...
panic: MMU fault


And another one
===============
trap: SIGSEGV pid=22, code=141, v=10, pc=897a, sr=9
Stopped at  _Debugger+0x6:  unlk    a6
db> trace
_Debugger(e06247b,e062473,16,141,10,897a,9) + 6
_trap(8,141,10) + 42c
sun3_mmu_specific() + 3c
db>
 
And still another one
=====================
trap: SIGSEGV pid=24, code=101, v=7725622e, pc=202cfde, sr=10
Stopped at  _Debugger+0x6:  unlk    a6
db> trace
_Debugger(e06247b,e062473,18,101,7725622e,202cfde,10) + 6
_trap(8,101,7725622e) + 42c
sun3_mmu_specific() + 3c
db>cont

Besides this, several core files are lying around in the directory I was in. 

To be honest, I don't have an idea what's wrong. Until now, the 
only thing I did was putting an extra printf into trap.c followed
by a call into the debugger.
 
Question:

Do you have things for me to look at, while being in the debugger?

Regards,

Harry Schreurs

------------------------------------------------------------------------------
H.L Schreurs                                            Email: hls@oce.nl
Business Unit Printing Systems                          Phone: +31 77 593775
Oce Nederland B.V.                                      Fax:   +31 77 595434
The Netherlands
------------------------------------------------------------------------------

------------------------------------------------------------------------------