[linux-lvm] Big trouble with 2.4.0 and lvm-0.9.1.*

[tim <tim4mail gmx de>]

Hi!
first at all i want to excuse my bad english...:-(

I decided today to upgrad from 2.4-test10 to 2.4.0. I was running lvm-8
final without any patches under the TEST 10 kernel (NOT the 2.4.1test10).
Now i downloaded both the new kernel (2.4.0) and the beta version of
lvm-0.9.1-beta2. i applied the kernel patch build the new tools and
rebooted. everything worked fine (exept of the wrong dir prefix so i had
to reinstall the tools and rebooted again).
so far so good....my volume group (name is cabinet) consists of 4 drives
2x60gig and 2x80gig (all from maxtor) and he whole space is used for one
lv named "a". e2fsck tooks nearly 30 mins so i wanted to move
the ext2 files to a reiserfs lv. i applied the patch and rebooted.
now i began to shrink my ext2 partion on /dev/cabinet/a about 30 gigs;
everything without a problem...i took those 30 gigs and created a new lv
named "jfs" (also the mkreiserfs ran without any problesm) .i
mounted both and started coping the files from the ext2 to the reiserfs
and my system crashed....i wasn't able to switch to another console nor
to use the magic sys keys. so i had to shut it off. after rebooting the
same problem occured. so i rebooted again. and since this time i'm unable
to access the "old" lv "/dev/cabinet/a" (bad
superblock..so i tried other superblocks without any luck with e2fsck).
so i tried to export and reimport the vg and vgimport stoped with and
segfault. i checked the mailing list and recognized a new version was out
(beta 3). i also installed it as written above, but i got the same
segfault. Any ideas how i can rescue any files?

Thanks 
      Tim

PS: Here is the part of the segfault from my message-logfile:

Jan 26 01:07:08 tux kernel: Trying to
vfree() bad address (0808aac8)
Jan 26 01:07:08 tux kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000006c
Jan 26 01:07:08 tux kernel:  printing eip:
Jan 26 01:07:08 tux kernel: c01286df
Jan 26 01:07:08 tux kernel: *pde = 00000000
Jan 26 01:07:08 tux kernel: Oops: 0000
Jan 26 01:07:08 tux kernel: CPU:    1
Jan 26 01:07:08 tux kernel: EIP:   
0010:[kfree+63/152]
Jan 26 01:07:08 tux kernel: EFLAGS: 00010002
Jan 26 01:07:08 tux kernel: eax: 00000004   ebx:
c50720c0   ecx: 00000000   edx: 0004805b
Jan 26 01:07:08 tux kernel: esi: 0805bdc0   edi:
00000206   ebp: c5072000   esp: c4c2bb84
Jan 26 01:07:08 tux kernel: ds: 0018   es: 0018   ss:
0018
Jan 26 01:07:08 tux kernel: Process vgimport (pid: 675,
stackpage=c4c2b000)
Jan 26 01:07:08 tux kernel: Stack: c50720c0 0805bdc0 00003bf0 0805bdc0
c01f3b30 0805bdc0 c5072000 0805bdc0 
Jan 26 01:07:08 tux kernel:       
00000001 c5072000 c4c2a000 00000000 c50724c4 00000004 000003c0 c01f2ff5
Jan 26 01:07:08 tux kernel:       
00000000 00000000 00000001 c4c2bc14 0805bd30 c5072000 00000000 00000000
Jan 26 01:07:08 tux kernel: Call Trace: [lvm_do_lv_remove+584/620]
[lvm_do_vg_remove+197/312] [lvm_do_vg_create+767/1052]
[ne:__insmod_ne_O/lib/modules/2.4.0/kernel/drivers/net/ne.o_M3A+-249856/96]
[lvm_chr_ioctl+665/1652] [ext2_getblk+101/212] [sock_recvmsg+61/172]
Jan 26 01:07:08 tux kernel:       
[ext2_bread+35/272] [dput+25/356] [permission+139/148]
[chrdev_open+100/172] [dentry_open+189/332] [filp_open+82/92]
[sys_ioctl+443/532] [system_call+51/56] 
Jan 26 01:07:08 tux kernel: 
Jan 26 01:07:08 tux kernel: Code: 8b 5c 08 68 85 db 74 39 8b 13 89 d0 3b
43 04 73 08 89 74 83