On Tue, May 20, 2003 at 05:22:14PM +0800, Feng, Fleming wrote:
> Hi, Bharata
> Please refer to the following.
This fix is working for me. I have commited this to cvs.
> b rgds
> > -----Original Message-----
> > From: Feng, Fleming
> > Sent: Tuesday, May 20, 2003 4:06 PM
> > To: bharata@...
> > Cc: Matt D. Robinson; lkcd-devel@...
> > Subject: RE: [lkcd-devel] LKCD 4.2 Updates/Test Images
> > Hi, Bharata
> > Please refer to my comments following.
> > b rgds
> > Fleming
> > > -----Original Message-----
> > > From: Bharata B Rao [mailto:bharata@...]
> > > Sent: Tuesday, May 20, 2003 1:12 PM
> > > To: Feng, Fleming
> > > Cc: Matt D. Robinson; lkcd-devel@...
> > > Subject: Re: [lkcd-devel] LKCD 4.2 Updates/Test Images
> > >
> > >
> > > On Tue, May 20, 2003 at 02:07:05AM +0800, Feng, Fleming wrote:
> > > > Lkcdutils-netdump.patch: There is a bug in the
> > > netdump-server that make it impossible to rewind to the dump
> > > file header (When we update dump header, we need to rewind) I
> > > have reported this bug to the mailing list. This patch file
> > > fixes this bug.
> > >
> > > I used this patch against the current netdump-server present in cvs
> > > and still I can't get useful dumps.
> > >
> > > When I run 'lcrash -s /var/log/dump -d vmcore', I always
> > get a dump.N
> > > file with zero size.
> > >
> > > A while back, when I was debugging this, I found that lcrash
> > > was expecting
> > > to find the dump header at offset KL_DUMP_HEADER_OFFSET.
> > This is true
> > > for block device but for network dump, the dump starts from
> > > the beginning
> > > of vmcore file, hence the header is at offset 0.
> > >
> > Yes, I get the same result with you. Sorry for not testing
> > this. But that's not the problem of this patch.
> > Even without this patch, the netdump still starts from file
> > offset 0 instead of KL_DUMP_HEADER_OFFSET.
> > I believe the issue is located in the netdump device of lkcd
> > kernel patch.
> > I will started to look at it.
> About this issue, we can see:
> In file dump_blockdev.c, function dump_block_seek(), there is a line of code like following:
> offset = off + dump_bdev->start_offset;
> while dump_bdev->start_offset is initialized as
> DUMP_HEADER_OFFSET == KL_DUMP_HEADER_OFFSET.
> While in file dump_netdev.c, function dump_net_seek, the code is like following:
> net_dev->curr_offset = off;
> the file offset DUMP_HEADER_OFFSET is not added to the net_dev->curr_offset;
> If we change this line of code to:
> net_dev->curr_offset= off + DUMP_HEADER_OFFSET;
> then everying thing is fine.
> The patch for this is like following:
> diff -X /home/xfeng/dontdiff -urN linux-2.5.59_arm_lkcd_orig/drivers/dump/dump_netdev.c linux-2.5.59_arm_lkcd/drivers/dump/dump_netdev.c
> --- linux-2.5.59_arm_lkcd_orig/drivers/dump/dump_netdev.c 2003-04-16 14:00:27.000000000 +0800
> +++ linux-2.5.59_arm_lkcd/drivers/dump/dump_netdev.c 2003-05-20 17:12:15.000000000 +0800
> @@ -747,7 +747,7 @@
> static int
> dump_net_seek(struct dump_dev *net_dev, loff_t off)
> - net_dev->curr_offset = off;
> + net_dev->curr_offset = off + DUMP_HEADER_OFFSET;
> return 0;
> > > Even if this is fixed there is an other problem. While dumping, lkcd
> > > updates the header many times with latest information.
> > > I don't know if netdump server has logic to understand this.
> > > (I suspect
> > > netdump server just takes the pages and appends to the file)
> > > I have seen
> > > that the header in vmcore file will always have the information that
> > > was written for the 1st time and without any subsequent updates.
> > >
> > > I wonder if you haven't seen these problems.
> > >
> > In fact, this patch is intend to solve the issue you
> > described above. For netdump the current netdump device tries
> > to seek set the file pointer at specified header location
> > each time when it dump pages. But if the specified file offset
> > in the vmcore is 0, it always failed. If we reserved the
> > first 4KB and written dump header at
> > KL_DUMP_HEADER_OFFSET, there should be no problem. becasue we
> > do not need to seek set the file pointer at
> > 0.
> > With this patch, even you specifed the file offset at 0, it
> > still can succeed.
> > > Regards,
> > > Bharata.
> > >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > lkcd-devel mailing list
> > lkcd-devel@...
> > https://lists.sourceforge.net/lists/listinfo/lkcd-devel
Bharata B Rao,
IBM Linux Technology Center, IBM Software Lab, Bangalore, India.
Ph: 91-80-5044962, Mail: bharata@....