Re: Linux 2.4.17 bug, mmap of /dev/mem

In the meantime I managed to make some minimal changes to 2.4.14 to
get it partially up on our box. The modified files are
Makefile
  Setting arch: to ppc, and setting up CROSS_COMPILE

arch/ppc/8260_io/uart.c
arch/ppc/8260_io/fcc_enet.c
  Slight changes to reflect our port assignments

fs/proc/proc_misc.c
include/asm-ppc/est8260.h
  These work together to pass some information from ppcboot to linux,
  so I can configure networking and whatnot.

Basically I'm making no major changes to the linux kernel, and the problem
is still there. I am trying to get 2.4.8 working but it looks like things
have moved around quite a bit, so I'm not sure how successful I'll be...

So: 2.4.2_hhl20 doesn't have the problem
2.4.8 = still trying to get it up on our box
2.4.14 has the problem
2.4.17 has the problem

Here is the current program to demonstrate the problem:

#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#define ADDR 0xf0010000
#define SIZE 0x00002000

main()
{
void *where;
int fd;
int t;
volatile unsigned long *base;
int i;

	fd=open("/dev/mem",O_RDWR);
	if(fd<0) {printf("Failed to open\n");return;}

	for(i=0;i<500;++i)
	{
		int status;
		if(fork()) {wait(&status);continue;}

		where=mmap(0,SIZE,PROT_READ|PROT_WRITE,MAP_SHARED,fd,ADDR);
		if(where==(void *)0xffffffff)
		{
			close(fd);
			printf("mmap failed\n");
			return -1;
		}

		base=(void *)where;

		t=base[0];
		base[0]=t;
		printf("%4d,%x\n",i,t);
		munmap(where,SIZE);
		exit(0);
	}
	close(fd);
	printf("done---mt\n");
}
---cut---
The above program fails at about iteration 228 on linux 2.4.17. On 2.4.14
it fails at an unpredictable iteration, from maybe 180 to 350. The number
of other seemingly harmless shell comands executed, like "ls", before running
the above program has an effect, meaning the above program will fail sooner
the more times a program has been executed by the shell.

In the case of 2.4.17, if I power up the box, wait until login prompt, login
as root, then run the above program, it very reliably fails at iteration
228. If I do 5 'ls' commands before, then it fails at iteration 223. Strange,
huh?

BTW the mmap is mapping the IMM area at 0xf0xxxxxx, but since the program
does a read then write back of the same value nothing should be affected.
The register I'm setting is the SIUMCR on the 8260.

Thanks--
Dave

You are asking in the right place, but some of us that should be looking
at it are swamped on other projects at the moment.  I've been using
mmap() without trouble to do similar things, and when I get a moment
I'll peruse your messages in the archives.

Thanks.

       -- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

David Ashley wrote:

#define ADDR 0xf0010000
#define SIZE 0x00002000

Oh, now I remember......I found it amusing someone could think they
could just map the CPM memory and start reading and writing it.
You can't do stuff like that and expect the system to keep running
correctly.  The first 128 bytes of the DPRAM are initialized for
the SMC (whether you use it or not).  You have to be really, really
careful when you map anything like this, and you have to understand
the interaction of everything else that may also have access to these
memory spaces.  A common mistake is people map things like GPIO into
application space, and then think they can atomically update the
registers.  This doesnt' work because there may be drivers that
also do the same thing.

The above program fails at about iteration 228 on linux 2.4.17. On 2.4.14
it fails at an unpredictable iteration, from maybe 180 to 350. The number
of other seemingly harmless shell comands executed, like "ls",

How does it fail?  If you are actually using the SMC as a console device
I'm surprised it runs that long.

There isn't anything wrong with mmap()......


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Dan Malek wrote:

Oh, now I remember......I found it amusing someone could think they
could just map the CPM memory and start reading and writing it.

...Or the memory controller or whatever else is there.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/