Find the answer to your Linux question:
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.
  1. #1
    IGW
    IGW is offline
    Just Joined!
    Join Date
    Mar 2010
    Posts
    2

    user space mmap overlapping with kernel ioremap range


    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.

  2. #2
    IGW
    IGW is offline
    Just Joined!
    Join Date
    Mar 2010
    Posts
    2

    Solved

    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.

  3. #3
    Just Joined!
    Join Date
    Jan 2012
    Posts
    1
    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.

  4. #4
    Administrator jayd512's Avatar
    Join Date
    Feb 2008
    Location
    Kentucky
    Posts
    5,023
    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!
    Jay

    New users, read this first.
    New Member FAQ
    Registered Linux User #463940
    I do not respond to private messages asking for Linux help. Please keep it on the public boards.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •