>>From ccsanady@bob.scl.ameslab.gov  Sat Nov  8 18:31:08 1997
>>Thanks to all who responded..  Now I can show you a backtrace of what
>>happened when my system went down. :)
>>
>>(gdb) target kcore netbsd.0.core
>>panic: machine check
>>#0  0xfffffc0000412da0 in dumpsys ()
>>(gdb) bt
>>#0  0xfffffc0000412da0 in dumpsys ()
>>#1  0xfffffc0000412b38 in cpu_reboot ()
>>#2  0xfffffc0000323034 in panic ()
>>#3  0xfffffc0000411840 in machine_check ()
>>#4  0xfffffc0000411548 in interrupt ()
>>#5  0xfffffc00003003f8 in XentInt ()
>>#6  0xfffffc0000300c70 in copyout ()
>>
>>What usually causes machine checks anyways?
>>
>>Chris
>

mjacob@ns.feral.com:

>...
>
>Also- it looks wierd that there's a machine check on a copyout.
>
>-matt

Matt is quite right to suspect the report of a mchk in copyout, it
probably didn't really happen there. The test release (and earlier)
kernels don't support traceback over vector frames; I'm a bit surprised
it even made it past interrupt() to XentInt(). (You do have
/sys/arch/alpha/alpha/locore.s rev 1.37, right? What's the first
line of that file?)

It might be a good idea for us to pullup the new traceback code into
the release, after all, it's there for just this sort of bug report.
There are another 5 or 10 frames that we just aren't seeing.

Can you put this core and kernel up for ftp somewhere? Be sure to
.Z or .gz it. Also, I would much rather have the originally linked
netbsd.gdb.

What were the panic messages?!  (See /var/log/messages.)

Is it repeatable?  Is this the box with the IDE drive?

ross@teraflop.com