* Re: Strange memory problem with Linux booted from U-Boot
2005-03-28 14:57 ` Strange memory problem with Linux booted from U-Boot Ara Avanesyan
@ 2005-03-28 15:06 ` Jan Engelhardt
2005-03-29 7:02 ` Ara Avanesyan
2005-03-28 16:17 ` linux-os
2005-03-30 7:21 ` Eugene Surovegin
2 siblings, 1 reply; 9+ messages in thread
From: Jan Engelhardt @ 2005-03-28 15:06 UTC (permalink / raw)
To: Ara Avanesyan; +Cc: linux-kernel, avila
>Hi,
>
>I need some help on solving this strange problem.
>Here is what I have,
>I have a loadable module (linux.2.4.20) which contains a 2 mb static gloabal
>array.
>
>Additional information:
>The same error occurs if I just run depmod -a.
I'd be more interested in the kernel space code...
Jan Engelhardt
--
No TOFU for me, please.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Strange memory problem with Linux booted from U-Boot
2005-03-28 15:06 ` Jan Engelhardt
@ 2005-03-29 7:02 ` Ara Avanesyan
0 siblings, 0 replies; 9+ messages in thread
From: Ara Avanesyan @ 2005-03-29 7:02 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-kernel, avila
----- Original Message -----
From: "Jan Engelhardt" <jengelh@linux01.gwdg.de>
To: "Ara Avanesyan" <araav@hylink.am>
Cc: <linux-kernel@vger.kernel.org>; <avila@lists.unixstudios.net>
Sent: Monday, March 28, 2005 8:06 PM
Subject: Re: Strange memory problem with Linux booted from U-Boot
> >Hi,
> >
> >I need some help on solving this strange problem.
> >Here is what I have,
> >I have a loadable module (linux.2.4.20) which contains a 2 mb static
gloabal
> >array.
> >
> >Additional information:
> >The same error occurs if I just run depmod -a.
>
> I'd be more interested in the kernel space code...
>
>
>
> Jan Engelhardt
> --
> No TOFU for me, please.
>
Oh, the code for kernel space is exactly the same code translated to C:
That is:
___________
#include <linux/vmalloc.h>
void mtestit(char val)
{
char *buf;
int i, j;
int size = 64;
int pass = 2 * 1024 * 1024;
printk("starting val == %x\n", val);
buf = vmalloc(size);
printk("allocated memory of %d bytes. buf == %x\n", size, (int)buf);
for (j = 0; j < pass; j++)
{
printk("passing %d", j);
for (i = 0; i < size; i++)
{
buf[i] = val;
}
printk("passed\n");
}
printk("freeing\n");
vfree(buf);
printk("finished!\n");
}
___________
I call this in a module's entry point and insmod that module.
now, mtestit(0xff) works, but mtestit(0x00) crashes:(
Works fine with RedBoot. Very strange to me:)
Moreover, works fine if I do the very same thing from
within U-Boot (mw.b 100000 0 100000).
I'm interested in ideas of what could potentially be the
cause of this strange behaviour.
__
Thanks,
Ara
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Strange memory problem with Linux booted from U-Boot
2005-03-28 14:57 ` Strange memory problem with Linux booted from U-Boot Ara Avanesyan
2005-03-28 15:06 ` Jan Engelhardt
@ 2005-03-28 16:17 ` linux-os
2005-03-30 7:21 ` Eugene Surovegin
2 siblings, 0 replies; 9+ messages in thread
From: linux-os @ 2005-03-28 16:17 UTC (permalink / raw)
To: Ara Avanesyan; +Cc: Linux kernel, avila
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3248 bytes --]
I tried your program with several 'val' values including ~0 and
0. The results were the same. In spite of using character pointers
on large negative integers, everything worked. What was the observed
kernel problem?? Perhaps, the kernel's printk() was not as kind
as g++ and you got some strange printed results??
On Mon, 28 Mar 2005, Ara Avanesyan wrote:
> Hi,
>
> I need some help on solving this strange problem.
> Here is what I have,
> I have a loadable module (linux.2.4.20) which contains a 2 mb static gloabal
> array.
> When I load it from linux booted via U-Boot the system crashes.
> Everything works ok if I do the same thing with the same linux booted with
> RedBoot.
> Before loading the module I check the current meminfo and get the same
> result both times.
>
> Additional information:
> The same error occurs if I just run depmod -a.
>
> system: Avila board 64 MB RAM, ixdp425 architecture, U-Boot: 1.1.2.
> Linux is MontaVista(R) Linux(R) Professional Edition 3.1.
>
> Ok, now an amazing reproduction of the same problem from user mode:
> the code below works for val = (~0), but not for 0, or even (~ff).
> Again, it works fine for linux booted from RedBoot.
>
> Some glue or something where and what to look?
> Any ideas of what potentially could cause this problem?
>
> Please CC me on reply.
>
> Thanks!
> Ara
>
> Several days ago I posted this question to U-boot mailing list but got not
> much help there:)
>
> ____
> error message:
> Unable to handle kernel paging request at virtual address e59f30f8
> mm = c000a320 pgd = c3e60000
> *pgd = 00000000, *pmd = 00000000
> Internal error: Oops: 0
> CPU: 0
> pc 2 [<c0054f64>] lr : [<00000000>] Tainted: GF
> sp : c3e45e94 ip : c3e45eb4 fp : c3e45eb0
> r10: 00000000 r9 : c3e45f04 r8 : 00000004
> r7 : 00000004 r6 : c016a000 r5 : c3e44000 r4 : e59f3054
> r3 : e91ba870 r2 : c019cc70 r1 : 00000000 r0 : 00000000
> Flags: nzCv IRQs on FIQs on Mode SVC_32 Control: 39FF Table: 03E60000
> DAC: 00000015
> Process klogd (pid: 89, stack limit = 0xc3e443a0)
> Stack: (0xc3e45e94 to 0xc3e46000)
>
> ___
> Now the (user level) code:
>
> #include <iostream>
>
> using namespace std;
>
> const int pass = 64;
> const int size = 2 * 1024 * 1024;
> const int val = 0xffffff00;
> int main()
> {
> cout << "starting val == " << hex << val << endl;
> char *buf = new char[size];
> cout << "allocated memory of " << size << " bytes. buf == " << (int)buf
> << endl;
>
> for (int j = 0; j < pass; j++)
> {
> cout << "passing " << j << endl;
> for (int i = 0; i < size; i++)
> {
> buf[i] = val;
> }
> cout << "passed" << endl;
> }
>
> cout << "freeing" << endl;
> delete []buf;
> cout << "finished!" << endl;
> return 0;
> }
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
[-- Attachment #2: Type: TEXT/PLAIN, Size: 1661 bytes --]
Script started on Mon 28 Mar 2005 11:12:26 AM EST
LINUX> g++ -o xxx -Wall -O2 xxx.cpp
LINUX> ./xxx
starting val == ffffffff
allocated memory of 200000 bytes. buf == b7dde008
passing 0
passed
passing 1
passed
passing 2
passed
passing 3
passed
passing 4
passed
passing 5
passed
passing 6
passed
passing 7
passed
passing 8
passed
passing 9
passed
passing a
passed
passing b
passed
passing c
passed
passing d
passed
passing e
passed
passing f
passed
passing 10
passed
passing 11
passed
passing 12
passed
passing 13
passed
passing 14
passed
passing 15
passed
passing 16
passed
passing 17
passed
passing 18
passed
passing 19
passed
passing 1a
passed
passing 1b
passed
passing 1c
passed
passing 1d
passed
passing 1e
passed
passing 1f
passed
passing 20
passed
passing 21
passed
passing 22
passed
passing 23
passed
passing 24
passed
passing 25
passed
passing 26
passed
passing 27
passed
passing 28
passed
passing 29
passed
passing 2a
passed
passing 2b
passed
passing 2c
passed
passing 2d
passed
passing 2e
passed
passing 2f
passed
passing 30
passed
passing 31
passed
passing 32
passed
passing 33
passed
passing 34
passed
passing 35
passed
passing 36
passed
passing 37
passed
passing 38
passed
passing 39
passed
passing 3a
passed
passing 3b
passed
passing 3c
passed
passing 3d
passed
passing 3e
passed
passing 3f
passed
freeing
finished!
LINUX> exit
Script done on Mon 28 Mar 2005 11:12:59 AM EST
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Strange memory problem with Linux booted from U-Boot
2005-03-28 14:57 ` Strange memory problem with Linux booted from U-Boot Ara Avanesyan
2005-03-28 15:06 ` Jan Engelhardt
2005-03-28 16:17 ` linux-os
@ 2005-03-30 7:21 ` Eugene Surovegin
2005-03-31 13:39 ` Ara Avanesyan
2 siblings, 1 reply; 9+ messages in thread
From: Eugene Surovegin @ 2005-03-30 7:21 UTC (permalink / raw)
To: Ara Avanesyan; +Cc: linux-kernel, avila
On Mon, Mar 28, 2005 at 07:57:52PM +0500, Ara Avanesyan wrote:
> Hi,
>
> I need some help on solving this strange problem.
> Here is what I have,
> I have a loadable module (linux.2.4.20) which contains a 2 mb static gloabal
> array.
> When I load it from linux booted via U-Boot the system crashes.
> Everything works ok if I do the same thing with the same linux booted with
> RedBoot.
As usual for such problems, check how different firmware configure
memory controller, etc. Get dump of relevant chip registers under
U-Boot and RedBoot and compare them.
Other possible problem area can be firmware -> kernel interface. I'm
not familiar with that particular chip and RedBoot, but it's not
uncommon for different firmware to have different conventions for the
environment in which kernel starts execution.
I'd recommend posting to the specific mail-lists, lkml doesn't seem
a good place for embedded and firmware related questions :)
--
Eugene
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Strange memory problem with Linux booted from U-Boot
2005-03-30 7:21 ` Eugene Surovegin
@ 2005-03-31 13:39 ` Ara Avanesyan
0 siblings, 0 replies; 9+ messages in thread
From: Ara Avanesyan @ 2005-03-31 13:39 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linux-kernel, avila
> On Mon, Mar 28, 2005 at 07:57:52PM +0500, Ara Avanesyan wrote:
> > Hi,
> >
> > I need some help on solving this strange problem.
> > Here is what I have,
> > I have a loadable module (linux.2.4.20) which contains a 2 mb static
gloabal
> > array.
> > When I load it from linux booted via U-Boot the system crashes.
> > Everything works ok if I do the same thing with the same linux booted
with
> > RedBoot.
>
> As usual for such problems, check how different firmware configure
> memory controller, etc. Get dump of relevant chip registers under
> U-Boot and RedBoot and compare them.
>
> Other possible problem area can be firmware -> kernel interface. I'm
> not familiar with that particular chip and RedBoot, but it's not
> uncommon for different firmware to have different conventions for the
> environment in which kernel starts execution.
>
> I'd recommend posting to the specific mail-lists, lkml doesn't seem
> a good place for embedded and firmware related questions :)
>
> --
> Eugene
>
Eugene,
Thanks for your response and ideas.
Actually the problem is concerning to linux part as the same code works fine
within U-Boot as I posted before. This is why I asked lkml for help what
might
cause this behaviour.
__
Thanks,
Ara
^ permalink raw reply [flat|nested] 9+ messages in thread