----- Original Message -----
> On 04/28/15 14:09, Dave Anderson wrote:
> >
> >
> > ----- Original Message -----
> >> On 04/28/15 11:27, Dave Anderson wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> Without this change REMOTE_DAEMON and GET_TIMESTAMP shared
> >>>> one bit.
> >>>> ---
> >>>> defs.h | 4 ++--
> >>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/defs.h b/defs.h
> >>>> index d2a8215..3f4b648 100644
> >>>> --- a/defs.h
> >>>> +++ b/defs.h
> >>>> @@ -518,6 +518,7 @@ struct program_context {
> >>>> #define INCOMPLETE_DUMP (0x8000ULL)
> >>>> #define is_incomplete_dump() (pc->flags2 & INCOMPLETE_DUMP)
> >>>> #define QEMU_MEM_DUMP_COMPRESSED (0x10000ULL)
> >>>> +#define GET_TIMESTAMP (0x20000ULL)
> >>>> char *cleanup;
> >>>> char *namelist_orig;
> >>>> char *namelist_debug_orig;
> >>>> @@ -617,11 +618,10 @@ struct new_utsname {
> >>>>
> >>>> #define GCC_VERSION_DEPRECATED
> >>>> (GCC_3_2|GCC_3_2_3|GCC_2_96|GCC_3_3_2|GCC_3_3_3)
> >>>>
> >>>> -/* flags2 */
> >>>> +/* kt flags2 */
> >>>> #define RELOC_AUTO (0x1ULL)
> >>>> #define KASLR (0x2ULL)
> >>>> #define KASLR_CHECK (0x4ULL)
> >>>> -#define GET_TIMESTAMP (0x8ULL)
> >>>>
> >>>> #define XEN() (kt->flags & ARCH_XEN)
> >>>> #define OPENVZ() (kt->flags & ARCH_OPENVZ)
> >>>> --
> >>>> 1.8.4
> >>>
> >>> Hi Don,
> >>>
> >>> Actually I'm going to fix it by keeping GET_TIMESTAMP in kt->flags2,
> >>> which is what was originally intended. The mistake was setting it in
> >>> the wrong place.
> >>>
> >>
> >> Ok, Let me know if you want me to send a patch.
> >
> > Nope, not necessary.
> >
> >>
> >>> The error scenario I see in normal usage is that when running
> >>> "crash -t" on a live system fails like so:
> >>>
> >>> crash: cannot open remote memory source: /dev/mem
> >>>
> >>> I'm guessing you see something different using your remote
> >>> capability?
> >>>
> >>
> >> That is correct. It acts like -t was supplied and so is not usable.
> >
> > So, let me get this straight -- this is the first time you're trying
> > to analyze a vmlinux kernel remotely? (i.e., instead of only a Xen
> > hypervisor)
> >
>
> Nope. This is the 1st time I was trying to analyze a vmlinux kernel
> remotely with crash-7.1.0. crash 7.0.9 worked fine.
>
> The change:
>
> commit f7e429764056d10e0ae87921e722e4e703cfb362
> Author: Dave Anderson <anderson@xxxxxxxxxx>
> Date: Thu Feb 5 14:40:44 2015 -0500
>
> Added support for VMware .vmss suspended state files as dumpfiles.
> Similar to all other supported dumpfile types, it is invoked as:
>
>
> is where it was broken...
>
> -Don Slutz
Ah OK, I see what happened. His patch moved GET_TIMESTAMP out of the pc->flags list
and into the kt->flags2 list in defs.h -- but the patch set the bit in pc->flags2.
Queued for crash-7.1.1:
https://github.com/crash-utility/crash/commit/7f3731aa09efa211f38203aa2d8f3f9784a294dc
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
