On 12/27/06, Linus Torvalds <[email protected]> wrote:
> On Wed, 27 Dec 2006, Gordon Farquharson wrote:
> >
> > I don't think so. I did reduce the target size
> >
> > #define TARGETSIZE (100 << 12)
>
> That's just 400kB!
>
> There's no way you should see corruption with that kind of value. It
> should all stay solidly in the cache.
>
> Is this perhaps with ARM nommu or something else strange? It may be that
> the program just doesn't work at all if mmap() is faked out with a malloc
> or similar.
Definitely a question for the ARM gurus. I'm out of my depth.
Gordon
--
Gordon Farquharson
* Gordon Farquharson <[email protected]> [2006-12-27 22:38]:
> >That's just 400kB!
> >
> >There's no way you should see corruption with that kind of value. It
> >should all stay solidly in the cache.
> >
> >Is this perhaps with ARM nommu or something else strange? It may be that
> >the program just doesn't work at all if mmap() is faked out with a malloc
> >or similar.
>
> Definitely a question for the ARM gurus. I'm out of my depth.
The CPU has a MMU. For reference, it's a IXP4xx based device with 32 MB
of memory.
--
Martin Michlmayr
http://www.cyrius.com/
* Gordon Farquharson <[email protected]> [2006-12-27 22:38]:
> >> #define TARGETSIZE (100 << 12)
> >
> >That's just 400kB!
> >
> >There's no way you should see corruption with that kind of value. It
> >should all stay solidly in the cache.
> >
> >Is this perhaps with ARM nommu or something else strange? It may be that
> >the program just doesn't work at all if mmap() is faked out with a malloc
> >or similar.
>
> Definitely a question for the ARM gurus. I'm out of my depth.
By the way, I just tried it with TARGETSIZE (100 << 12) on a different
ARM machine (a Thecus N2100 based on an IOP32x chip with 128 MB of
memory) and I see similar results to that from Gordon:
Writing chunk 279/280 (99%)
Chunk 256 corrupted (1-1455) (1025-2479)
Expected 0, got 1
Written as (199)43(184)
Chunk 258 corrupted (1-1455) (3945-1303)
Expected 2, got 3
Written as (184)74(145)
Chunk 260 corrupted (1-1455) (2769-127)
Expected 4, got 5
Written as (145)89(237)
Chunk 262 corrupted (1-1455) (1593-3047)
Expected 6, got 7
Written as (237)168(174)
Chunk 264 corrupted (1-1455) (417-1871)
Expected 8, got 9
Written as (174)135(161)
Chunk 266 corrupted (1-1455) (3337-695)
Expected 10, got 11
Written as (161)123(180)
Chunk 268 corrupted (1-1455) (2161-3615)
Expected 12, got 13
Written as (180)13(19)
Chunk 270 corrupted (1-1455) (985-2439)
Expected 14, got 15
Written as (19)172(106)
Chunk 272 corrupted (1-1455) (3905-1263)
Expected 16, got 17
Written as (106)212(140)
Chunk 274 corrupted (1-1455) (2729-87)
Expected 18, got 19
Written as (140)124(73)
Chunk 276 corrupted (1-1455) (1553-3007)
Expected 20, got 21
Written as (73)151(52)
Chunk 278 corrupted (1-1455) (377-1831)
Expected 22, got 23
Written as (52)215(99)
Checking chunk 279/280 (99%)
--
Martin Michlmayr
http://www.cyrius.com/
On Thu, Dec 28, 2006 at 11:16:59AM +0100, Martin Michlmayr wrote:
> * Gordon Farquharson <[email protected]> [2006-12-27 22:38]:
> > >> #define TARGETSIZE (100 << 12)
> > >
> > >That's just 400kB!
> > >
> > >There's no way you should see corruption with that kind of value. It
> > >should all stay solidly in the cache.
> > >
> > >Is this perhaps with ARM nommu or something else strange? It may be that
> > >the program just doesn't work at all if mmap() is faked out with a malloc
> > >or similar.
> >
> > Definitely a question for the ARM gurus. I'm out of my depth.
>
> By the way, I just tried it with TARGETSIZE (100 << 12) on a different
> ARM machine (a Thecus N2100 based on an IOP32x chip with 128 MB of
> memory) and I see similar results to that from Gordon:
Work around the glibc memset() problem by passing nr & 255, and re-run
the test. You're getting false positives.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
* Russell King <[email protected]> [2006-12-28 10:49]:
> > By the way, I just tried it with TARGETSIZE (100 << 12) on a different
> > ARM machine (a Thecus N2100 based on an IOP32x chip with 128 MB of
> > memory) and I see similar results to that from Gordon:
>
> Work around the glibc memset() problem by passing nr & 255, and re-run
> the test. You're getting false positives.
Yeah, I saw your message about this problem after I sent mine.
--
Martin Michlmayr
http://www.cyrius.com/