Since upgrading one of our servers to 1.5 a few weeks ago, we are now seeing
occasional kernel traps, apparently (and usually) triggered by a syslogd
restart:

Mar  3 01:40:06 omega /usr/local/sbin/named[5128]: lame server on
'52.33.32.209.
in-addr.arpa' (in '33.32.209.in-addr.arpa'?): 209.23.180.2#53
Mar  3 01:44:18 omega syslogd: restart
Mar  3 01:44:18 omega /netbsd:
Mar  3 01:44:18 omega /netbsd: fatal kernel trap:
Mar  3 01:44:18 omega /netbsd:
Mar  3 01:44:18 omega /netbsd:     trap entry = 0x2 (memory management
fault)
Mar  3 01:44:18 omega /netbsd:     a0         = 0x0
Mar  3 01:44:19 omega /netbsd:     a1         = 0x1
Mar  3 01:44:19 omega /netbsd:     a2         = 0xffffffffffffffff
Mar  3 01:44:19 omega /netbsd:     pc         = 0x0
Mar  3 01:44:19 omega /netbsd:     ra         = 0x0
Mar  3 01:44:19 omega /netbsd:     curproc    = 0xfffffc0001358020
Mar  3 01:44:19 omega /netbsd:         pid = 19307, comm = sh
Mar  3 01:44:19 omega /netbsd:
Mar  3 01:44:19 omega /netbsd: panic: trap
Mar  3 01:44:19 omega /netbsd: syncing disks... 12 11 10 9 8 7 7 6 6 5 5 4 4
2 2
 1 done
Mar  3 01:44:19 omega /netbsd:
Mar  3 01:44:19 omega /netbsd: dumping to dev 4,1 offset 263023
Mar  3 01:44:19 omega /netbsd: dump 128 127 126 125 124 123 122 121 120 119
118
117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99
98 97
 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72
71 7
0 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45
44
43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19
18 17
 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 succeeded
Mar  3 01:44:19 omega /netbsd:
Mar  3 01:44:19 omega /netbsd:
Mar  3 01:44:19 omega /netbsd: rebooting...
Mar  3 01:44:19 omega /netbsd:
Mar  3 01:44:19 omega /netbsd: consinit: not using prom console

This is on a 164SX system, running plain 1.5.  The system was rock-solid
with 1.4.1, but we were looking for some of the 1.5 enhancements, and hence
the upgrade.  But now we are lucky to keep the system running for a week
without a panic ...

Can anyone suggest where we should start looking to track this down?

Thanks ...

-----
Tom Haapanen -- Software Metrics -- Waterloo, Ontario, Canada
Advanced Printing Solutions -- http://www.metrics.com/