Re: Re(5): kernel dump server
Re: Re(5): kernel dump server
- Subject: Re: Re(5): kernel dump server
- From: Peter Lovell <email@hidden>
- Date: Wed, 1 Feb 2006 17:40:37 -0500
On Feb 1, 2006, at 9:29 AM, Derek Kumar wrote:
Hi Derek,
the ARP request routine will allow the control transfer, in the
same way that takes place during the dump itself. The
"flag_panic_dump_in_progress" flag is already set and the routine
kdp_arp_request (line 1277) calls kdp_poll which will cause the
transfer (test around line 678) if a packet is received.
Hello,
kdp_poll() doesn't actually perform a control transfer if a
debugger packet arrives in the course of a crashdump - it merely
clears some globals via abort_panic_transfer() and returns to the
caller, which would be your ARP request routine in this case. It is
the caller's responsibility to then cause an exit from
kdp_panic_dump(), which will then switch to the debugger, i.e.
kdp_connection_wait(), if certain conditions are met. In your
implementation, you'd address this by checking for a return of -2
from your arp request routine, and then branching to the
panic_dump_exit label. But it's a minor point. An issue with the
way this is done is that the original debugger packet is discarded,
so it will only be the next debugger connection retry that makes it
through.
My arp request routine was deliberately cloned from
kdp_send_panic_pkt and has the same breakout logic. But you're right
- it should check specifically for -2 and go to panic_dump_exit. Of
course, it doesn't try for very long so debugger will get there, just
be delayed a bit.
A port number for the crashdump server could certainly be a
separate boot-arg (or the parser could be changed to allow IP:port
notation, if that's what you meant); I'd have to check if the
server allows you to specify the port it would bind to, but if not,
that can be changed.
The IP:port notation was my original intent, to keep things simple.
The parse routine has a hard limit at 16 though, ignoring a limit
greater than that if so specified. I can appreciate that this is a
reasonable default, but it shouldn't override a specific limit
provided by the caller.
The port number value for the server can be changed readily - it's
specified in the xinetd config file.
... (since the lack of ARP resolution will be addressed in a future
update
This is actually the "biggie" for us, and I suspect other developers
too. If you have a full-blown network with routers then you can put
the dump server on another network and things "just work". But for
those of us with smaller networks (even large-ish companies with
fairly simple networks) this is a killer. It makes kernel-dump
entirely useless, so please can we have it in a "sooner" update.
If it helps, I'll revise the patch and add it to the radar.
Cheers.....Peter
_______________________________________________
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