On Wed, 2012-05-30 at 20:51 -0400, Jason Cooper wrote:
On Wed, May 30, 2012 at 03:06:23PM -0300, Thiago Jung Bauermann wrote:
quoted
Hello,
I have just upgraded my Dreamplug to the 3.4 kernel, and when creating
an LVM snapshot volume, I see errors for which I didn't find any report
yet:
# lvcreate -s -L 80M -n root-fsck-snapshot marv2-vg/root
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
Logical volume "root-fsck-snapshot" created
# lvremove -f marv2-vg/root-fsck-snapshot
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
Logical volume "root-fsck-snapshot" successfully removed
This is on the following kernel:
Linux marv 3.4.0-1bauer2-kirkwood #1 Wed May 30 01:31:47 BRT 2012 armv5tel GNU/Linux
Is this a vanilla v3.4 kernel? Is this a repeatable error, even after
hard reboot?
Yes, the error happens every time even after rebooting or powering off
the machine and then on again after a minute.
The kernel is almost vanilla... I'm using the patches here on top of the
vanilla kernel:
https://github.com/bauermann/dreamplug/tree/master/with-linux-3.4
There's not much really. One patch (dreamplug-3.4.0.patch) adapts the
kernel to use the Guruplug machine id and adapts the kernel to boot
without a flattened device tree (I'm using Marvell's original u-boot,
with the old id and no device tree support), three of them (mvsdio-*)
add magic delays to the SD card driver and three others add the
libertas_uap wireless driver (which I'm not using and the modules aren't
even loaded).
The phys-virt.diff one may be of interest. It sets PHYS_OFFSET to 0x0.
Also, I have CONFIG_EMBEDDED=y but I disabled
CONFIG_ARM_PATCH_PHYS_VIRT. This is because of some forum posts saying
that ARM_PATCH_PHYS_VIRT yelds an unbootable kernel. I didn't test if
that was indeed the case though.
--
[]'s
Thiago Jung Bauermann
From: Jason Cooper <hidden> Date: 2012-05-31 03:09:31
On Wed, May 30, 2012 at 11:24:07PM -0300, Thiago Jung Bauermann wrote:
On Wed, 2012-05-30 at 20:51 -0400, Jason Cooper wrote:
quoted
On Wed, May 30, 2012 at 03:06:23PM -0300, Thiago Jung Bauermann wrote:
quoted
Hello,
I have just upgraded my Dreamplug to the 3.4 kernel, and when creating
an LVM snapshot volume, I see errors for which I didn't find any report
yet:
# lvcreate -s -L 80M -n root-fsck-snapshot marv2-vg/root
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
Logical volume "root-fsck-snapshot" created
# lvremove -f marv2-vg/root-fsck-snapshot
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
Logical volume "root-fsck-snapshot" successfully removed
This is on the following kernel:
Linux marv 3.4.0-1bauer2-kirkwood #1 Wed May 30 01:31:47 BRT 2012 armv5tel GNU/Linux
Is this a vanilla v3.4 kernel? Is this a repeatable error, even after
hard reboot?
Yes, the error happens every time even after rebooting or powering off
the machine and then on again after a minute.
Ok, that rules out one error I've seen in the past.
The kernel is almost vanilla... I'm using the patches here on top of the
vanilla kernel:
https://github.com/bauermann/dreamplug/tree/master/with-linux-3.4
There's not much really. One patch (dreamplug-3.4.0.patch) adapts the
kernel to use the Guruplug machine id and adapts the kernel to boot
without a flattened device tree (I'm using Marvell's original u-boot,
with the old id and no device tree support), three of them (mvsdio-*)
add magic delays to the SD card driver and three others add the
libertas_uap wireless driver (which I'm not using and the modules aren't
even loaded).
The phys-virt.diff one may be of interest. It sets PHYS_OFFSET to 0x0.
Also, I have CONFIG_EMBEDDED=y but I disabled
CONFIG_ARM_PATCH_PHYS_VIRT. This is because of some forum posts saying
that ARM_PATCH_PHYS_VIRT yelds an unbootable kernel. I didn't test if
that was indeed the case though.
Please try a vanilla v3.4 kernel with CONFIG_ARM_APPENDED_DTB.
thx,
Jason.
On Wed, 2012-05-30 at 23:09 -0400, Jason Cooper wrote:
Please try a vanilla v3.4 kernel with CONFIG_ARM_APPENDED_DTB.
To be honest I don't feel comfortable about doing that. One
knowledgeable guy on the debian-kernel mailing list said that "the
Kconfig entry for ARM_APPENDED_DTB is quite scary about enabling it and
booting without a DTB appended"[1] and indeed it doesn't look very
encouraging.
Another message on the thread talks about "concerns about damaging other
boards"[2] (maybe I am misreading this one?).
[1] http://lists.debian.org/debian-kernel/2012/03/msg00049.html
[2] http://lists.debian.org/debian-kernel/2012/03/msg00645.html
Is there a risk of damaging the board if it is accidentally booted with
the wrong DTB or without one?
Does it help if I test with only dreamplug-3.4.0.patch (which adds
CONFIG_MACH_DREAMPLUG) applied?
--
[]'s
Thiago Jung Bauermann
From: Jason Cooper <hidden> Date: 2012-05-31 13:31:58
On Thu, May 31, 2012 at 01:32:10AM -0300, Thiago Jung Bauermann wrote:
On Wed, 2012-05-30 at 23:09 -0400, Jason Cooper wrote:
quoted
Please try a vanilla v3.4 kernel with CONFIG_ARM_APPENDED_DTB.
To be honest I don't feel comfortable about doing that. One
knowledgeable guy on the debian-kernel mailing list said that "the
Kconfig entry for ARM_APPENDED_DTB is quite scary about enabling it and
booting without a DTB appended"[1] and indeed it doesn't look very
encouraging.
Yes, that's to discourage folks from doing that as a routine bootable
system. The whole advantage of DT is that it goes with the board, and
you then build one kernel for multiple boards. That advantage is lost
if people get in the habit of appending the DT to the kernel. But for
testing once, it's fine as long as you remember to append the dtb.
You may want to look at the kwboot patches to u-boot [1]. It's a
utility that allows you to load u-boot with only the serial port
connected. Many have reported success with it. This would then allow
you to add DT boot support (and fix a bunch of bugs in the stock
u-boot ;-) ).
Another message on the thread talks about "concerns about damaging
other boards"[2] (maybe I am misreading this one?).
Yes, you are mis-reading it. They are referring to breaking
drivers/board support on orion and mv78xxx. _Not_ breaking the
*physical* boards.
There's always a risk at this level. The statement in the Kconfig is
true. However, If you aren't willing to upgrade u-boot, you aren't
leaving too many other options. Knives are dangerous, too. People
still use them every day. Just be careful.
Does it help if I test with only dreamplug-3.4.0.patch (which adds
CONFIG_MACH_DREAMPLUG) applied?
On Thu, 2012-05-31 at 09:31 -0400, Jason Cooper wrote:
On Thu, May 31, 2012 at 01:32:10AM -0300, Thiago Jung Bauermann wrote:
You may want to look at the kwboot patches to u-boot [1]. It's a
utility that allows you to load u-boot with only the serial port
connected. Many have reported success with it. This would then allow
you to add DT boot support (and fix a bunch of bugs in the stock
u-boot ;-) ).
Thanks, I'll have a look. The impression I get though is that these
things are still too recent to have settled, so if I flash an u-boot
now, maybe I'll have to flash it again later. Might as well wait a bit
and do it just once.
quoted
Is there a risk of damaging the board if it is accidentally booted with
the wrong DTB or without one?
There's always a risk at this level. The statement in the Kconfig is
true. However, If you aren't willing to upgrade u-boot, you aren't
leaving too many other options. Knives are dangerous, too. People
still use them every day. Just be careful.
If you have an accident with a knife at home, the worst that will happen
is that you'll have to use a band-aid for a few days. On the other hand,
when I go to the butcher I see him wearing a metal chain gauntlet when
cutting meat. If he has an accident with *that* knife, he'll be in
trouble. In both cases you are dealing with knives and in both cases you
have to be careful... My question was, what kind of knife I'm dealing
with here? ;-)
I bought this Dreamplug for personal use and if it breaks, I won't buy
another one. That's a different level of risk tolerance than someone
who's
working professionally on an ARM board, where breaking it is just cost
of
doing business.
quoted
Does it help if I test with only dreamplug-3.4.0.patch (which adds
CONFIG_MACH_DREAMPLUG) applied?
Sure, see if the problem persists. That would rule out the other
patches.
I built a kernel with just that patch and it got stuck after
uncompressing the kernel. I'll have to build a new one with
CONFIG_ARM_PATCH_PHYS_VIRT disabled and try again tomorrow (I know, a
newer u-boot works around/fixes this).
--
[]'s
Thiago Jung Bauermann
From: Jason Cooper <hidden> Date: 2012-06-01 10:50:22
On Thu, May 31, 2012 at 11:17:29PM -0300, Thiago Jung Bauermann wrote:
On Thu, 2012-05-31 at 09:31 -0400, Jason Cooper wrote:
quoted
On Thu, May 31, 2012 at 01:32:10AM -0300, Thiago Jung Bauermann wrote:
You may want to look at the kwboot patches to u-boot [1]. It's a
utility that allows you to load u-boot with only the serial port
connected. Many have reported success with it. This would then allow
you to add DT boot support (and fix a bunch of bugs in the stock
u-boot ;-) ).
Thanks, I'll have a look. The impression I get though is that these
things are still too recent to have settled, so if I flash an u-boot
now, maybe I'll have to flash it again later. Might as well wait a bit
and do it just once.
The dreamplug code in u-boot is done. As long as you make sure
CONFIG_OF_LIBFDT if defined in include/configs/dreamplug.h, you'll only
need to do it once. Latest git has this, so 2012.06 will have it.
As the dtb grows, you just tftp it to the dreamplug, and write it in
like a kernel update (or, optionally, you can update it via Linux
userspace via the exposed spi flash block devices).
And honestly, 2012.04.01 is fine, with the exception of adding
CONFIG_OF_LIBFDT. Which really should be handled by a Kconfig-type
infrastructure. I can't tell you how tired I am of seeing "U-boot
YYYY.MM-dirty" when it boots just because I want an extra feature.
quoted
quoted
Is there a risk of damaging the board if it is accidentally booted with
the wrong DTB or without one?
There's always a risk at this level. The statement in the Kconfig is
true. However, If you aren't willing to upgrade u-boot, you aren't
leaving too many other options. Knives are dangerous, too. People
still use them every day. Just be careful.
If you have an accident with a knife at home, the worst that will happen
is that you'll have to use a band-aid for a few days. On the other hand,
when I go to the butcher I see him wearing a metal chain gauntlet when
cutting meat. If he has an accident with *that* knife, he'll be in
trouble. In both cases you are dealing with knives and in both cases you
have to be careful... My question was, what kind of knife I'm dealing
with here? ;-)
I bought this Dreamplug for personal use and if it breaks, I won't buy
another one. That's a different level of risk tolerance than someone
who's working professionally on an ARM board, where breaking it is
just cost of doing business.
From: Simon Baatz <hidden> Date: 2012-06-10 20:16:25
Hi,
[cross posted to linux-lvm, because I think it is a lvm problem]
On Wed, May 30, 2012 at 03:06:23PM -0300, Thiago Jung Bauermann wrote:
I have just upgraded my Dreamplug to the 3.4 kernel, and when creating
an LVM snapshot volume, I see errors for which I didn't find any report
yet:
# lvcreate -s -L 80M -n root-fsck-snapshot marv2-vg/root
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
Logical volume "root-fsck-snapshot" created
Ironically, the main reason I upgraded the kernel from 3.0.0 was to get
I see similar errors on an IB-NAS6210 box. 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.
In LVM2, there is a list in lib/mm/memlock.c of maps to ignore:
/* list of maps, that are unconditionaly ignored */
static const char * const _ignore_maps[] = {
"[vdso]",
"[vsyscall]",
};
"[vdso]" seem to be based on gate_vma as well. Thus, I think
"[vectors]" needs to be added to this list.
- Simon
Hi,
[cross posted to linux-lvm, because I think it is a lvm problem]
On Wed, May 30, 2012 at 03:06:23PM -0300, Thiago Jung Bauermann wrote:
quoted
I have just upgraded my Dreamplug to the 3.4 kernel, and when creating
an LVM snapshot volume, I see errors for which I didn't find any report
yet:
# lvcreate -s -L 80M -n root-fsck-snapshot marv2-vg/root
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
Logical volume "root-fsck-snapshot" created
Ironically, the main reason I upgraded the kernel from 3.0.0 was to get
I see similar errors on an IB-NAS6210 box. 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.
In LVM2, there is a list in lib/mm/memlock.c of maps to ignore:
/* list of maps, that are unconditionaly ignored */
static const char * const _ignore_maps[] = {
"[vdso]",
"[vsyscall]",
};
"[vdso]" seem to be based on gate_vma as well. Thus, I think
"[vectors]" needs to be added to this list.
Yep, looks like simple patch to add.
Is there any other area which is missing ?
Zdenek
Hi,
[cross posted to linux-lvm, because I think it is a lvm problem]
On Wed, May 30, 2012 at 03:06:23PM -0300, Thiago Jung Bauermann wrote:
quoted
I have just upgraded my Dreamplug to the 3.4 kernel, and when creating
an LVM snapshot volume, I see errors for which I didn't find any report
yet:
# lvcreate -s -L 80M -n root-fsck-snapshot marv2-vg/root
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]: mlock failed: Cannot allocate memory
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
Logical volume "root-fsck-snapshot" created
Ironically, the main reason I upgraded the kernel from 3.0.0 was to get
I see similar errors on an IB-NAS6210 box. 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.
In LVM2, there is a list in lib/mm/memlock.c of maps to ignore:
/* list of maps, that are unconditionaly ignored */
static const char * const _ignore_maps[] = {
"[vdso]",
"[vsyscall]",
};
"[vdso]" seem to be based on gate_vma as well. Thus, I think
"[vectors]" needs to be added to this list.
Opps - missed multilist posting - so again with all copies...
Yep, looks like simple patch to add.
Is there any other area which is missing ?
Zdenek