[linux-lvm] Sorry, dm:1.02, lvm2:2.02 did not work for me

[James G. Sack (jim)]

On Tue, 2005-11-15 at 08:54 -0800, James G. Sack (jim) wrote: 
> On Sat, 2005-11-12 at 22:49 +0000, Alasdair G Kergon wrote: 
> > On Sat, Nov 12, 2005 at 10:03:21PM +0000, Alasdair G Kergon wrote:
> > > I've reproduced this if the LV is activated with an old release but
> > > the snapshot is created with the new code.  Should be easy to fix.
> >  
> > Try the current CVS versions.
... 
> Ok, I've grabbed the cvs images, done the configure/make/make install on
> dm and then lvm, and I now see:
> 
> lvm version
>   LVM version:     2.02.01-cvs (2005-11-10)
>   Library version: 1.02.01-cvs (2005-11-10)
>   Driver version:  4.4.0
> 
> I rebooted and reran my test procedure which 
> 1) loops on {lvcreate, sleep 10, lvremove, sleep 2}
> and simultaneously
> 2) loops on {cp abcd wxyz;cp wxyz abcd) 
> operating on a 1GB file on the origin filesystem
> 
> 
> The kcopyd.c BUG at line 145 is triggered by the first lvremove
> following start of the i/o (copy loop).
.. 
> ==> I will go rerun my test scenario on a new origin volume, to see if
> there's any differences.

Result with origin volume on new pv/vg/lv was same, namely: kcopyd.c BUG
at line 145 & oops.

Is there something else I can provide to assist in diagnostics?

hmmm- I thought I might simplify my test environment by removing all
older lvm devices, so I pulled disks containing 3 other pv's. Then I was
getting another scsi read error so I pulled that disk (<heh> I have a 9-
disk NAS I'm playing on, in case anyone's wondering)

Then after reboot, and rerun of my test procedure, I still get the same
behavior --except that it now seems to lockup hard -- no ssh, no ping,
no console scrollback, no keyboard (although sysrq works), no
dmesg/syslog output. There *is* console screen output, ending with what
looks like the trailing part of the oops calltrace. Is it worth
configuring a serial console in order to capture this? (Or can someone
tell me how to capture it otherwise?)

Regards.
..jim