I now installed angstrom on my pandaboard and the bug does not occur.
angstrom kernel: 2.6.35.3
from http://narcissus.angstrom-distribution.org/
So the bug is at least not hardware related, but ubuntu specific.
it's up to you to think about if it's more valid now
--
You received this bug
I think that really only means that more drivers are enabled on the
ubuntu kernel so greater chance of address conflict..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/697004
Title:
mmap for fixed
Hi Andre,
Well, there is no bug here.
You try to mmap some memory and request the kernel to provide a specific
virtual address. Unfortunately, the virtual address you request is not
available in your process address space. So fortunately, the kernel provides
you a replacement address that is
I believe the observed mmap behavior is correct:
By looking at the mappings already configured for the running process, I see
that (cat /proc/pid/maps):
...
40084000-4009b000 r-xp b3:02 91605 /lib/ld-2.12.1.so
4009b000-4009d000 rw-p 00:00 0
400a3000-400a4000 r--p 00017000
Sebastien,
Thanks for taking look at this. I agree with you on this. mmap behavior
is correct.
Andre, as we found here, we believe this is invalidate. For the location
mapped by libraries on ARM, we need to check the loader configuration
maybe.
-Bryan
** Changed in: linux-ti-omap4 (Ubuntu)
Andre and Rob,
After testing this program on omap4/omap3/imx51, I got the same result.
Some mmap system call return value is not the one we expected. But it is
OK on x86.
I think this issue can be divided into two parts:
1. mmap doesn't make sure to return the virtual mmaping address as we want.
Hi Bryan,
Thanks for doing more tests.
My opinion stays the same: ARM behaviour is wrong :)
I didn't had that issue for example with an older kernel in qemu-system-arm,
but i guess being a VM it has no value for regression testing.
And yes, there are Apps depending on the x86 mmap behaviour...
I
Andre,
No problem. I will post this issue to upstream ARM mail list and copy
you in that. Is the testcase here the right one for posting?
And which older kernel works for you? If it is a regression, it is
easier to find a fix.
-Bryan
--
You received this bug notification because you are a
I guess the testcase is fine.
the older kernel was 2.6.28-versatile
though we can't really say if it's a regression, but we will see
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/697004
Title:
mmap
Great, Could you please me know your public email address. I'm going to
copy you in the email.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/697004
Title:
mmap for fixed address fails for higher
Since there is only 1G memory in Panda, the physical address is from 0x0
to 0x3FFF. If you try to mmap fixed address from this arrange, it
will works. But for upper 1G memory mapping, it will give you other
virtual address.
Try this loop:
--
for(i=0x3000;i0x4001;i+=0x1)
--
It
The virtual memory should depend on physical memory in size, not in position.
That's why it's called mapping.
And i already had success with mapping 64k at address greater than 0x7000
on machines with only 256MB Ram and 512MB swap...
So something else must be wrong.
A wild guess from me:
ARM stack grows down (fwiw)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/697004
Title:
mmap for fixed address fails for higher addresses
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
13 matches
Mail list logo
