> I've read how several people are having problems with recent releases
> on these machines. I have tested the amd64 and i386 ports, 4.1,
> 4.2-stable, and -current.

> i386 seems stable.

I have been looking on this for a long time already, and I can say that
it is stable on i386 and on AMD64, single kernel now.

> amd64, any version, eventually reboots itself. Sometimes right after
> fsck (hello reboot-loop), sometimes if you just ssh to the box, or
> start a kernel compile, etc. It usually only takes a few seconds of
> interaction with the box.

AMD64.mp only so far. The problem is always when it needs to write to
the drive with speed. What I mean by that is if you write to drives not
so heavy, then it will continue to work, but as soon as you push it a
bit, it will crash, but no debug, or anything, just reboot.

One way to extend this, or make it more solid is to disable the USB
virtual cd-rom in bios. Then you will get more out of the box, but still
you sure can crash it anytime if you push it.

> - HOWEVER -

> These boxes appear to be rock-solid if you avoid the disks. I have a
> few that run diskless -- and they do not fall over, no matter what I
> throw at them. 4.2-stable and -current work fine there; the reboots
> disappear if my / is on nfs.

Only because you do not write to the disk and it really have nothing to
do with / mount on nfs. Proof, if you have any partition locally mounted
to your drive, like '/var' for example, or what ever you have, just do

dd if=/dev/zero of=/var/test bs=1m count=100

And then watch got south in just a few seconds, or if you didn't disable
the USB virtual CD-ROM, it will be right away.

With that disable, you can copy files locally better as it will be
slower then the dd version and ytou may get more out of it, but at time,
just trying to add an other ssh session to the box will crash it as soon
as it try to write to the /var/log folder. Your are toast.

> If I mount an internal disk and try to use it, the machine reboots.

Yes it does if you push it all the time. But if you copy files from
outside the box from a very slow computer, meaning the transfer is slow,
you will most likely be successful. It's always when you reach a
transfer writing speed that crash it.

An other example to illustrate the point.

If you mount a local partition RO, like '/var/tmp' for testing only and
then do

cp /var/tmp/test /dev/null

You will be OK. It's always writing that crash the box, readying is
fine, however, if you push the reading, it will not crash it, but the
second you do a very small write to the drive, it will crash. Just:

echo 'test' >/tmp/test

Will do it.

And again all this is only with amd64 bsd.mp

> I'd like to provide more info to the developers for debugging this but
> need a bit of guidance... how do you troubleshoot something that
> generates no panic and no log entries and the machine resets?

I did so many tests of all kinds and I am narrowing it, but still not
the finger exactly on the problem.

There is a lots of feedback int he archive already and a few things are
better for sure. But the problem still there big time even on kernel
snapshot of November 20.

The only thing I can suggest that will give you more is to have the BIOS
and ILOM at the 1.1.8 and 39 for the BIOS and then disable the virtual
CDROM in the USB section of the BIOS, it will give you a much more
stable box, but not crash free however. Not yet anyway.

Best,

Daniel