----- "Simon Kagstrom" <simon.kagstrom@xxxxxxxxxxxxxx> wrote: > On Thu, 17 Dec 2009 11:17:56 -0500 (EST) > Dave Anderson <anderson@xxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
