Re: [Xen-devel] Crash in xen 4.7 adding nic during domu startup

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.06.16 at 13:23, <syllopsium@xxxxxxxxxxxxxxxx> wrote:
> A clue on doing this would be useful, I can't debug what is now release
> code all day.

Well, debugging (released code or not) is what's needed, I'm afraid.
A first step would be to find out how far the corruption extends:
Considering the non-zero code bytes that got dumped, I would
have expected the 0xE8 to be a function call opcode, but then
the exception couldn't have occurred on the 4th byte after. So I
assume corruption extends beyond the zeroed range, and you
could figure this out by comparing with the actual binary.

If the range of the corrupted area doesn't provide any clues how
or when the corruption occurs, I'd then add debugging code which,
at coarse intervals, would inspect the area in question. Of course
you need to be prepare for the corruption area to move relative to
symbols.

But in the end this is a pretty unusual situation, where I don't think
I can provide pre-cooked debugging instructions.

But of course there are other angles to look at this from: You say
you use GPU pass-through. What about the case when you don't?
And while you appear to try to make logging more verbose by
using a (non-existent) "verbose" command line option, using
"loglvl=all guest_loglvl=all iommu=debug" would yield better
results.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel