Re: [Crash-utility] [PATCH v2] Add read diagnostics to crash
----- Original Message -----
> But there is still no need to redundantly display the virtual
and physical
> addresses. And the displays of the calculated file offsets, zero-fill, etc.
> will still end up showing the complete function sequence by putting the
> function name in the output. For example, the updated readmem() output would
> show a call to read_kdump(), but the file offset display would show that it
> has transitioned to read_netdump(), so there's no need for any debug output
> at all in read_kdump().
Well, read_kdump() in the case of a non-hyper-mode XEN dump has code
that has the appearance of a route of change for paddr, i.e. the
following doesn't result in no change or in P2M_FAILURE:
paddr = xen_kdump_p2m(paddr)
The code I posted can show two unique paths through read_kdump() but if
as you say, you log calling it with the physical address known and log
in read_netdump() with the physical address included then you get the
same result.
No, you're right -- that particular "switch" of the paddr value
should probably have its own debug statement.
Also, are there any cases of overlapped/threaded execution of reads?
If not then removal of redundant output is wise but the virt/phys addr
would identify which thread of execution each line refers to among
overlapped output in most cases.
Well, at least in the Xen case, yes it is possible. But they would be
encapsulated by the debug statements that indicate the "temporary" change
from read_kdump() to read_netdump() in x86.c, x86_64.c (and ia64.c).
Dave