On recent kernels, the current stable LVM2 on ARM causes such as: ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: munlock failed: Cannot allocate memory The fix is a very simple one-liner that will be included into 2.02.99, but for any older versions the patch should be applied. Apparently, lvm2 tries to mlock/munlock all readable maps it finds in "proc/self/maps", i.e also the "[vectors]" page. Between 3.0 and 3.4 there has been the change f9d4861f "ARM: 7294/1: vectors: use gate_vma for vectors user mapping", which might have changed the behaviour when mlocking vectors. Bug described on: https://www.redhat.com/archives/linux-lvm/2012-June/msg00019.html A one-liner patch on (will be included in sys-fs/lvm2-2.02.99): https://www.redhat.com/archives/lvm-devel/2012-November/msg00039.html
I tried the patch manually and it works fine. Changing back to critical, as upstream says without it, LVM2 is unusable on some ARM arches.
Please don't re-assign the severity of the bugs. It's the maintainer who needs to decide that.
(In reply to comment #2) > Please don't re-assign the severity of the bugs. It's the maintainer who > needs to decide that. I was not aware of that. Sorry, will not do it again.
I created an ebuild with mentioned one-liner fix and now I'm getting this: vgchange -a y device-mapper: resume ioctl on failed: Invalid argument Unable to resume data--vg-data (254:0) 1 logical volume(s) in volume group "data-vg" now active lvm version LVM version: 2.02.98(2) (2012-10-15) Library version: 1.02.77 (2012-10-15) Driver version: 4.23.0 Could you please post more info about how did you manage it to work? Thanks
(In reply to comment #4) > I created an ebuild with mentioned one-liner fix and now I'm getting this: > > vgchange -a y > device-mapper: resume ioctl on failed: Invalid argument > Unable to resume data--vg-data (254:0) > 1 logical volume(s) in volume group "data-vg" now active > > lvm version > LVM version: 2.02.98(2) (2012-10-15) > Library version: 1.02.77 (2012-10-15) > Driver version: 4.23.0 > > Could you please post more info about how did you manage it to work? > Thanks I vaguely recall there was something with the `vgchange -a y`, but I think ultimately it was just that it worked even if it complained at start.
As per $subject with <2.02.99 it implies 2.02.99 is fixed. Also, 2.02.100 is now in Portage. No need to keep this bug open, next stabilization will take care of this.
