My understanding of this trace:

pmap_enter(e58f984, 202a000, 548000, 1, 0)
pv_link(e58f984, 548000, 202a000, 0)
pmap: set_pte pmap=e58f984 va=202a000 old=0 new=800002a4 (eu)
Breakpoint at   _trapsignal:    linkw   a6,#0
db> 

  Is that this is a request to map va 0x202a000 to physical address
0x548000. Now, this is with prot=1, or VM_PROT_READ. This is
presumably the first time that the page has taken a trap, and the page
has now been filled from disk. Several context switches have happened
since the page was mapped. 
  Now, if the data on physical address 0x548000, or 
	01010100,10000000,00000000 
  or >> 13 bits (8k pages)
  new_pte=010,1010,0100 = 2a4, with the "valid" bit set, but not the 
write bit set had bad data to *begin* with, then things will
definitely crash...

  This suggests to me that the problem may actually be in filling the
page properly. Do we perhaps really have SCSI DMA problems? That would
explain why systems with less memory (that swap more) would suffer
more than other systems. Is 0x0000 a valid 68k instruction?

  [Michael wanders around house trying to locate dogeared 68k book. I
bought that when I read about the Mac in Feb.1994 Byte.... no luck.
www.mot.com? Hmm. 68020 is on their search engine's "stop list" :-)]
 
  Now, from what I can see, from the trace I have, this is the second
item to be mapped into memory (after text, data, bss and stack). The
first is presumably ld.so, so the second is either termcap or libc.
  The first one is 0xc000 in size, and:

% size /usr/libexec/ld.so
text    data    bss     dec     hex
40960   8192    0       49152   c000

  Based on the size being 0x2000, and 

amaterasu-[/users/mcr] 1 >size /usr/lib/libtermcap.so.0.0
text    data    bss     dec     hex
8192    8192    0       16384   4000

  (where is the "data" section of a shared library mapped? )

  it is dying while mapping termcap. What are the odds that termcap is
resident already? If it were libc, I'd say pretty high, but libc
hasn't been mapped yet.

  Does anyone agree or disagree?

  I have si_obio_options = 3....

  okay, I just did the three rxvt trick to cause core dumps to
start... playing with si_obio_options does nothing to help.
  I just did a trace on /bin/id. No confusion about what libraries are
being loaded....

   :!mcr!:            |  Cow#1: Are you worried about getting Mad Cow Disease?
   Michael Richardson |  Cow#2: No. I'm a duck.
 Home: mcr@sandelman.ocunix.on.ca. PGP key available.