1. Home
  2. Omega Talk
  3. do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600

do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600

  • L

    Have received an Omega 2 and an Omega 2+. Literally a clean device, nothing that's been done to it, the Omega 2 I can run fast-gpio fine, and it sets GPIO pins. The Omega 2+ however, I try and run fast-gpio, and all I get is this segfault:

    [   32.277374]
do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600
[   32.286272] epc = 00401d51 in fast-gpio[400000+3000]
[   32.291364] ra  = 00401a89 in fast-gpio[400000+3000]
[   32.296408]
Segmentation fault

    Is this a broken device? It's literally brand new, and isn't working!

    1
  • WereCatf

    What firmware version are you running? The Onion-devs forgot to enable CONFIG_DEVMEM in the newer firmware. The last working one is 0.1.6 b137

    2
  • L

    Ooooh. That doesn't sound too good!

    Ω-ware: 0.1.7 b139

    I'll have a google around as to how to roll back the firmware then!

    Cheers.

    0 WereCatf 1 Reply
  • WereCatf

    @Luke-Lowrey The images are at http://repo.onion.io/omega2/images/

    In CLI do:

    cd /tmp
wget http://repo.onion.io/omega2/images/omega2p-v0.1.6-b137.bin
sysupgrade omega2p-v0.1.6-b137.bin

    Wait for the LED to turn off, then restart your Omega2p and wait several minutes while the LED blinks.

    8
  • L

    Amazing! That's working now.

    Many thanks for your help. You've saved me from pulling my hair out!

    I'm also new on here. Is there a rep / thanks system on this forum?

    0 L 1 Reply
  • L

    @Luke-Lowrey , i dont know what you mean with rep ... reputation?

    on the lower right corner you have the quote link on the side of this you can ppls request up or downwote, see smal arrows. ... and you change the reputation of a person this way.

    0
  • P

    D'oh! I wish I'd caught this thread a few days ago, it must have cropped up right after I started searching for the same problem.

    Thanks for the rollback tips @WereCatf - I may hang tight and wait for a firmware update to fix it.

    On the plus side, I have a built and tested toolchain now! But of course the fast-gpio I compiled from source didn't work either.

    0
  • R

    Thanks for this. Just started trying fast-gpio on a brand new Omega2 and getting seg faults. I'll try the roll back.

    0
  • K

    fast-gpio is written in C/C++ and operates by using memory mapping to the GPIO registers.
    While I haven't had time to look at things closely yet but there are potential issues that need to be taken care of/changed for a version of fast-gpio for Omega2 as compared to Omega1:

    1. Needs to be built specifically for the Omega2 processor which is different from the Omega1
    2. The memory mapped GPIO registers are accessed as 32 bit values - the endian-ness of the Omega2 processor is different from the Omega1 and will need to be taken care of to check that it is appropriate in each case
    3. Being a different processor, the memory mapping of the GPIO registers may well be different on the Omega2 and Omega1 and will need to be taken care of to check that it is appropriate in each case

    Since I have some C/C++ code of my own for doing things similar to fast-gpio I will be looking at these issues in more detail when I have time

    -1 WereCatf 1 Reply
  • WereCatf

    @Kit-Bishop I'm not sure why you're trying to confuse matters. Fast-gpio works just fine and uses the correct register-addresses. The problem is, that in these newer images the Onion-devs forgot to enable KERNEL_DEVMEM, ie. /dev/mem doesn't exist, and fast-gpio just assumes it does and doesn't actually check whether it succeeded in opening /dev/mem or not. Then it just proceeds to try and fiddle with the registers, even though it never managed to mmap them and that's why it crashes!

    0 K 1 Reply
  • K

    @WereCatf Not trying to confuse the issue.
    As I said:

    I haven't had time to look at things closely

    I was just surmising about possible issues since I have some similar C/C++ code that I will need to review for the Omega2

    Though I don't know how you can say:

    Fast-gpio works just fine
    if there are issues with KERNEL_DEVMEM not enabled - though I would concede that this is more a system issue rather than with fast-gpio
    Though it does raise questions of how much actual testing has been done on the software released for the Omega2

    0 WereCatf 1 Reply
  • WereCatf

    @Kit-Bishop I can say that because:

    • /dev/mem doesn't exist in the newer images and it's obviously needed in order to be able to access the GPIO-registers
    • I have tested fast-gpio and it works fine in the images with /dev/mem
    • I have looked at the source-code for fast-gpio

    If you don't believe me, you're entirely free to check things yourself.

    0 K 1 Reply
  • K

    @WereCatf I do believe you 🙂
    My point is that if there is a feature that is not currently enable (i.e /dev/mem) in the current official releases that some official components rely on to work, then those components cannot actually be said to currently work.
    Not everyone {wants to/is able to/is capable of/has time for/has resources for} building their own releases just to fix a system shortcoming that causes components to fail.

    0
  • F

    My proposition was to add a KNOWN ISSUES section in the docs so people wouldn't waste-time/pull-their-hair/risk-an-heart-attack to try features that aren't yet ready for the users.

    1 L 1 Reply
  • L

    @fossette , known issues will be solved tin time .. so i guess they should stay out of the documentation ... a link to the forum instead would be ok.

    -1 F 1 Reply
  • F

    @Luciano-S. said in do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600:

    a link to the forum instead would be ok.

    If it doesn't get lost in the numerous postings, it's a good idea ... for example a PINNED POST.

    However, changelog files and man pages often list known issues, so I don't see anything wrong with a mention in the doc files, especially if it's the first place users should refer to first. Afterward, they get transferred from KNOWN ISSUES to TROUBLESHOOTING.

    0 L 1 Reply
  • L

    @fossette said in [do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600](/topic/1208/do_page_fault-sending-sigsegv-to-fast-gpio-for-

    However, changelog files and man pages often list known issues,

    If they are permanent that's ok. But a missing sd-card drivers for example don't have to be mentioned, because the drivers will be added and the error is gone ... why confuse ppl about something like this who not exists anymore (in near future)?!

    0 F 1 Reply
  • F

    @Luciano-S. Communication efficiency is the ONLY thing that maters.

    0 L 1 Reply
  • L

    @fossette , great ... then pls. go on to communicate here in the Forum ... you do a great job to show the others where to look ... but stop asking for something (more work) for Onion.io.

    If you have solutions for their problems post them on git-hub as pull request. If you really want you can also try to make your "Known issues" and propose as pull request. But don't for get to do the maintenance for this section. You will see it is a lot of work/time you will miss for other tasks 😉

    </end_of_discussion>
<start_doing_it>
Thats how opensource community works!
</start_doing_it>```
    0
  • Lazar Demin
    administrators

    @Luciano-S @fossette @Kit-Bishop @WereCatf
    we actually have KERNEL_DEVMEM and KERNEL_DEVKMEM enabled, the firmware just stopped mapping /dev/mem a little while ago. Haven't had the time to dive into it tho!

    A known issues page and changelog is in the works!

    3 E 1 Reply
omega2+ 335 fast-gpio 20
Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.