Results 1 to 4 of 4
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) ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 03-06-2010 #1
- Join Date
- Mar 2010
user space mmap overlapping with kernel ioremap range
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.
- 03-08-2010 #2
- Join Date
- Mar 2010
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.
- 01-30-2012 #3
- Join Date
- Jan 2012
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().
- 01-30-2012 #4
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!