6.0 random freezes

[Peter Jeremy]

On Mon, 2005-Dec-12 18:57:24 -0800, Atanas wrote:
>When I plug a keyboard, there's no response at all - no LEDs, no VTYs, 
>Ctrl-Alt-Esc, etc. You might think of "hint.atkbd.0.flags" not being set
>properly, but it's right (i.e. unchanged, it appears to default to that
>on i386 5.x+) and other machines with identical configuration do accept
>keyboard.

Note that PS/2 keyboards aren't hot-pluggable and attempts to do so
can have deleterious effects on your keyboard and/or motherboard.  In
any case, the probe/attach sequence relies on the kernel being in a
reasonably sane state (and I'm not sure if it will detect the keyboard
as a console device except at boot time).

If the keyboard has been plugged in since the system booted, do you
still get the same "no response"?  If so, the kernel has wedged at
a fairly low level and I'm not quite sure how to proceed other than
by enabling the sanity checks that other people have mentioned
(eg WITNESS, INVARIANTS) and hoping they catch something.

>the next crash. But if I have no keyboard response I won't be able to 
>save it, right?

True.  But DDB has been designed to rely on a fairly minimal subset of
kernel functionality and often works, even though the system appears frozen.

>I do not know what a serial console is and would need some time to get 
>along with it. Would I get something in addition to what I can get from 
>the standard console?

I only mentioned serial consoles on the off-chance that you had one.
Whilst it may not help here, serial consoles have a number of
advantages when managing remote equipment (ie equipment not sitting on
your desk) - you can access the console remotely and log all console
output on another computer (either cross-connect com1/com2 on pairs of
hosts or get a multi-port serial card to manage a number of systems).
If your BIOS can handle serial communications, you virtually never
need to physically visit your servers.  For details, check out:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html
I personally use ports/comms/conserver-com to manage about 50 assorted
Unix/FreeBSD servers and switches at work.

>The "dumpdev" variable seems to default to AUTO, i.e. trying to use the 
>first swap device if it's bigger than the RAM (in my case yes), so I 
>guess I don't need to touch it.

It seems that my suggestion has been obsoleted by changes to the startup
scripts since I checked last.

>After the downgrade we could eventually set a test bed and start 
>hammering it with requests. The problem would be how to trigger the 
>crash and whether we would be able to reproduce it at all.

Depending on your application and the interfaces to it, it might be
feasible to either tee live traffic into both systems and just junk
the responses from your test bed, or "record" live traffic and
replay it into your test bed.

-- 
Peter Jeremy