site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Feb 1, 2006, at 9:29 AM, Derek Kumar wrote: 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. This email sent to site_archiver@lists.apple.com