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 07:33:57 -0500
On Jan 31, 2006, at 12:35 PM, Derek Kumar wrote:
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.
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