----- "Simon Kagstrom" <simon.kagstrom(a)netinsight.net> wrote:
 On Thu, 17 Dec 2009 11:17:56 -0500 (EST)
 Dave Anderson <anderson(a)redhat.com> wrote:
 
 > > > So I started looking into the code and found something which looks like
 > > > a typo in relocate() (patch below). Changing this makes crash work for
me.
 > > 
 > > Actually it's not a typo -- your patch would presumably break with all
kernels
 > > that have a CONFIG_PHYSICAL_START is greater than CONFIG_PHYSICAL_ALIGN, which
 > > is what the patch was written to handle.
 > > 
 > > What are your kernel's CONFIG_PHYSICAL_START and CONFIG_PHYSICAL_ALIGN
 > > values?  Does crash work with your kernel on the live system?  
 
 You are right. I had problems with getting things working, so I've
 played around with various settings. I had CONFIG_PHYSICAL_START set to
 0 and CONFIG_PHYSICAL_ALIGN set to 0x100000. Setting these to e.g.,
 0x100000 and 0x100000 unbreaks things again.
 
 I don't need to supply --reloc either then, not sure what I did wrong
 before. I'm sticking with sane settings from now on.
 
 > > Anyway, I believe that the fix would require support for supplying a 
 > > negative --reloc value.
 > 
 > On the other hand, if the config values were the other way around, the 
 > problem didn't use to show up -- at least according to list item "1)"
 > below in the changelog:
 > 
 >             1) Configure the kernel with CONFIG_PHYSICAL_START less than
 >                or equal to CONFIG_PHYSICAL_ALIGN.  Having done that, there
 >                is no problem; the resultant vmlinux file will be loaded at
 >                the address for which it was compiled, which has always
 >                been the case.
 
 > I wonder if you can use the unpatched crash, but supply a --reloc value that
 > will cause a wrap-around to the correct value?
 
 Well, I suppose that would work if it was possible to supply a negative
 --reloc value, but I'm not sure it's really worth it. What would be
 nice would be to get a more descriptive error message. 
Yeah, the problem is that the "do not match" errors can result from
a multitude of error scenarios.  Usually by entering a "-d <number>"
on the command line (the higher the debug number the more verbose),
the issue generating the failure typically is evident.
 
 Thanks for the help, please ignore the patch. 
OK for now -- and thanks for posting.  It's only a matter of time before
somebody else runs into the same thing.
Thanks,
  Dave
 
 // Simon