user space mmap overlapping with kernel ioremap range

[IGW]

Hello all,

Sorry for yet another mmap-related question.

Bottom line question - is there any problem with mmap'ing (with /dev/mem) over a range that includes memory requested (and granted to) a kernel module?

details follow ...
Embedded ARM based system kernel is 2.6.29 basically.

I have a simple driver that needs to check a GPIO status line, read from phys address (easy enough) and toggle another GPIO line. (Using iowrite32 call - slower than I would like, but that is another issue.) Data arrives very regularly and predictably and there is plenty of buffering at various points - kernel timer is used rather than interrupt at this stage.

The driver claims address range:
0xFFFFF000 for 0x0A00 bytes long.
(check_mem_region followed by request_mem_region and ioremap).

I want access in user space to these GPIO controllers (and some other hardware registers) as well. So I mmap (on /dev/mem) an overlapping region:
0xFFFFE0000 for length 0x2000.

This all seems to go OK - the return values from the kernel module calls and the user space call to mmap all pass OK. All return values are checked carefully and defensively.

However, I am getting occasional seg faults on some fairly simple user space processing and I am wondering if there is a problem with these overlapping memory regions.

This is not a mutual exclusion issue.

I have searched pretty hard and been through ldd3. I did try to mmap through my driver but this caused more problems - probably as the address range in the driver is less than a page (other drivers in the system claim some of the surrounding memory.

Obviously it is necessary to *not* disturb the memory locations used by the being managed by the driver - the nature of the Atmel 9260 GPIO ports make this easy though.

So...is there any problem with mmap'ing (with /dev/mem) over a range that includes memory requested (and granted to) a kernel module?

For those of you still here, ...thanks for any help you can provide.

[IGW]

Just to clear this up in case anyone comes past here, and since traffic from the experts os pretty light on here I thought I would provide an update...

This was a case of RTFM, but what %%$%^&^^ (I am sort of smiling here) would put the parameter order in iowrite32 as "value" followed by "address"!

It was staring me in the face and I just couldn't see it. My history and expectation was that the call would be iowrite32(address, value).

It was my own fault for not reading carefully enough - we can get blinded by our pasts and expectations - sort of a life lesson there.

So it is not surprising the kernel oops'ed when I tried to write to all sort of weird locations.

My code, including the user mmap'ed blocks overlapping memory allocated by the kernel is all working OK.

[mashhur]

hi there,
could you please tell me how did you get ioremap() worked.
I am stuck on it, im having a list of errors when i compile the code uses ioremap().
thanks.

[jayd512]

Hi, mashhur. And welcome aboard!

This thread is almost 2 years old, so locking it down.
Please feel free to start a new thread if you need help with anything, though.
Don't forget to provide some details on the issue!