site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jan 31, 2006, at 12:35 PM, Derek Kumar wrote: 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, I submitted rdar://4422761 a couple of days ago, and included an updated kdp_udp.c which solves this problem. Main issue was that there was no ARP request code there at all, and now there is. This also ARPs for the router_ip if that is defined in boot-args (this capability was mentioned in the code as a future enhancement). Thanks for filing a radar, I'll take a look. (It's likely that equivalent changes are awaiting release in this particular case, but contributions to the kernel are always welcome). Since it was in the same file, I also updated the code for creating the dump file name so that it now includes the xnu minor version. Notes in the code suggest that rdar://3735061 requested this capability. Great - as I recall, it was intended that we fix this by changing an internal submission script to stamp the kernel with the version number, rather than parsing the existing version string (which is created from OBJROOT (by config/newvers.pl), which includes the version number in an internal build environment). However, having the minor version numbers in crashdump filenames is definitely convenient. N.B.: You can also use the "showversion" kgmacro, which examines the magic address 0x501C - that holds a pointer to the version string (or "strings -" on the crashdump and grep that for the version pattern as a crude work-around if you don't have gdb handy). You can use that macro on live connections as well, to determine the version of the kernel you're connected to so you can find the right symbols. (An "implementation detail" - that macro is fine on PPC and live x86 connections, however it doesn't yet work on x86 crashdumps - the currently released x86 kernel doesn't have crashdump support, so it's not immediately relevant, but it will be eventually :-) Derek P.S.: From a quick look, if you're using this internally, your ARP request routine would have to change to allow control transfer to the debugger if a debugger packet arrives; also, the code to check for the crashdump protocol packets is probably unnecessary in your arp request routine. And apropos the comment about size checking, kdp_vm_read() is a debugger routine that checks for a valid translation for both source and destination pages in the currently active debugger pmap (virtual address space), and then does a physical mode copy, so it's a "safe read". We can get away with assuming the translation remains valid since the debugger runs with interrupts off on the active cpu, and the rest of the processors are signaled to spin on the debugger lock on entry. 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. The other testing etc I deliberately left alone as much as possible - my thought way to make the minimal set of changes necessary, rather than do a more extensive change which would be harder to integrate (or even accept). Also, some changes might have ramifications elsewhere and I wanted that risk to be as small as possible. For example, I considered and then rejected the temptation to allow a port-number specification as part of the _panicd_ip address, the reason being that it would require a change to the parser for boot- args (16 character limit, this arg could be 22). So, even though there are some redundancies, they were deliberate in order to make the changes easier to review and evaluate. This email sent to site_archiver@lists.apple.com