The fix was just to remove PAE support from the i386 kernel (until the
bug is found). So, try copying the latest snapshot kernel to /bsd and
reboot. Just grab it from the snapshots/i386 directory on the ftp
server.
I copied a current i386 kernel from this week , and
it rebooted okay on the athlon64 platform.
Now I wait a week and see if it freezes/hangs....
Umm, it frooze/hung up again at 5:08 am. about
23 hours after rebooting with the current 4.1 kernel
on the i386 4.0 userland....
I was remote so I did not see the monitor for any
panics, but reset using the apc power switch.
I looked through the logs and the only thing
I saw queer was that it created a file
/var/log/mail with zero content just as it hung up.
Weird, I used the kernel from current on stable i386 userland
on a K8 cpu, which is something that I would normally not do,
but since it was an simple test, we tried.
Staying with i386 on a athlon64 K8 cpu
has caused hangups/freezes about every day or two
of note here is the log snips indicating when
logging stopped....
--- from daemon
Mar 3 05:05:38 mail dhcpd: DHCPDISCOVER from 00:18:39:f0:c8:be via rl0
Mar 3 05:05:38 mail dhcpd: DHCPOFFER on 172.16.254.224 to
00:18:39:f0:c8:be via rl0
Mar 3 08:08:56 mail named[14969]: starting BIND 9.3.2-P1
Mar 3 08:08:56 mail named[14969]: loading configuration from
'/etc/named.conf'
And here is a weird file that showed up in the
/var/log/ at the apparent time of the hang:
-rw-r--r-- 1 root wheel 0 Mar 3 05:06 mail
Yes it may be with enough effort we could find the culprit,
and it may be an port or something else, but with less
effort I could roll back to stable or upgrade to current
amd64 instead of trying to make i386 not hang.
... My personal experience is that going forward
I would strongly recommend to readers to use OpenBSD amd64
(not i386) on the AMD K8 platforms (athlon64).
