[Crash-utility] [PATCH] GET_TIMESTAMP is pc->flags2 not kt->flags2

[Dave Anderson]

----- 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) 

Dave

> 
>    -Don Slutz
> 
> > Dave
> > 
> >  
> >  
> > 
>