Re: Re: panic.log on Intel?
Re: Re: panic.log on Intel?
- Subject: Re: Re: panic.log on Intel?
- From: "Brian Bechtel" <email@hidden>
- Date: Fri, 13 Oct 2006 14:26:55 -0700
On 10/13/06, Andrew Gallatin <email@hidden> wrote:
Derek Kumar writes:
> As to why the backtrace doesn't show any more, it's because the
> framepointer linkage was terminated prematurely (zeroed)...could be
> stack corruption. If you can connect to the machine or examine a
> crashdump, you can try trawling the stack for traces. I'd also
> suggest verifying that you were, in fact, on the appropriate thread
> stack at the time of the panic.
Thank you. That was quite helpful. I imagine we're
doing something to induce random memory corruption,
which is not a good sign. Unfortunately, this customer
is pretty clueless, and cannot setup dumps.
Here's a simple thing. Set up a kernel coredump server on one of your
machines. It doesn't have to be fast, but it helps to have enough
hard disk space. On the client (i.e. panic-prone machine)
sudo nvram boot-args="debug=0xd44 _panicd_ip=10.0.40.2"
{and reboot for this to take effect.}
where you replace 10.0.40.2 with the IP address of your coredump
server. You must restart to enable this setting. Next time that
machine panics, you'll get a core dump.
To setup your coredump server (from
<http://developer.apple.com/technotes/tn2004/tn2118.html>) do the
following:
mkdir /PanicDumps
chmod ugo+wx /PanicDumps
cat > /tmp/macosxkdump <<EOF
service macosxkdump
{
disable = no
type = UNLISTED
socket_type = dgram
protocol = udp
port = 1069
user = nobody
groups = yes
server = /usr/libexec/kdumpd
server_args = /PanicDumps
wait = yes
}
EOF
sudo cp /tmp/macosxkdump /etc/xinetd.d
sudo kill -HUP `cat /var/run/xinetd.pid`
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden