kdump cp /proc/vmcore exiting with "Invalid Argument" Error

[Sujit V]

Wanted to point out that /proc/vmcore existed...

kdump command >ls -l /proc/vmcore
-r--------    1 0        0        4153763584 Feb 10 18:50 /proc/vmcore


On Wed, Feb 10, 2010 at 10:46 AM, Sujit V <sujit.linux at gmail.com> wrote:
> Tried readelf on the /proc/vmcore but gave the below error. The
> readelf worked correctly on another binary.
>
> kdump shell>/sbin/readelf -l /proc/vmcore
> readelf: Error: Cannot stat input file /proc/vmcore.
>
>
> Anything else I could try.?
>
>
> On Sat, Feb 6, 2010 at 1:41 AM, Bernhard Walle <bernhard at bwalle.de> wrote:
>>
>>
>>
>> Am 06.02.2010 03:45, schrieb Sujit V:
>>> I have integrated the kdump in our linux 2.6.23 based kernel. If I do
>>> echo c > /proc/sysrq-trigger then it boots the kdump kernel & I use
>>> the cp /proc/vmcore /local/crash/vmcore-incomplete
>>>
>>> On a new x86 based hardware (32 bit PAE kernel)  the "cp /proc/vmcore
>>> " command exits prematurely.
>>>
>>> cp -v /proc/vmcore /local/crash/vmcore-incomplete
>>>       cp: reading `/proc/vmcore': Invalid argument  >>> Error >>
>>>
>>> ls -l /local/crash/
>>> total 115588
>>> -r--------    1 0        0        2526724096 Feb  5 03:09 vmcore-incomplete
>>>
>>> ls -l /proc/vmcore
>>> -r--------    1 0        0        4153763584 Feb  5 03:16 /proc/vmcore
>>>
>>>
>>> Every time I trigger kdump the cp command exits after copying
>>> 2526724096 bytes. So I thought it might be a file size issue.
>>> Googling pointed out a patch in include/linux/proc_fs.h
>>
>> I would compare 'readelf -l /proc/vmcore' (ELF program headers) and map
>> the file offset 2526724096 to the physical memory that belongs to that
>> file offset. Maybe accessing that physical memory fails for some reason.
>>
>>> struct vmcore {
>>> struct list_head list;
>>> unsigned long long paddr;
>>> - unsigned long size;
>>> + unsigned long long size;
>>> loff_t offset;
>>>
>>> I checked my kernel & it already has this patch.
>>
>> I don't think that this is the problem because 2526724096 is between 2G
>> and 4G, so it doesn't point to some "magic border".
>>
>>
>> Regards,
>> Bernhard
>>
>>
>>
>