do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600
-
@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!
-
@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
-
@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.
-
@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.
-
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.
-
@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.
-
@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.
-
@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)?!
-
@Luciano-S. Communication efficiency is the ONLY thing that maters.
-
@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>```
-
@Luciano-S @fossette @Kit-Bishop @WereCatf
we actually have KERNEL_DEVMEM and KERNEL_DEVKMEM enabled, the firmware just stopped mapping/dev/mema little while ago. Haven't had the time to dive into it tho!A known issues page and changelog is in the works!
-
@Luciano-S @fossette @Kit-Bishop @WereCatf
Update: the firmware changelog and known issues listing is up! See the docs site: https://docs.onion.io/omega2-docs/firmware-reference.html
Will try to carve out time this week to look into this
/dev/memissue.
-
@Lazar-Demin Well, that's a start. I still would like to have access to the actual sources you build the firmware-images from, so maybe I could be of help.
-
@Lazar-Demin
Any update relating to the fast-gpio thing?Thanks
-
@Lazar-Demin
Any update relating to the fast-gpio thing?Thanks
-
@Lazar-Demin It was working fine in 0.1.6 b137, and not working since 0.1.6 b138 (up to 0.1.9-b157). Whatever was changed between 137 and 138, that would by bmy main suspect.
-
Anyone heard of any updates to this issue? Seems like the onion people only now and then comments and then its all quiet for a long time or forever.
-
@Lazar-Demin @administrators @Global-Moderators
Hi Lazar, I am sure you guys are busy with the shipping and interruptions you had etc. I still wonder how you handle software support during this period? There seems to several issues out there that should be pretty straight forward to solve and not take much of your time but stops many people in doing their work. Have you guys consider being somewhat more open about what prevents you from just fixing these issues ASAP? I see that there are several images being built continuously but not any updates to the issues?While I, hopefully, have your attention. Do you know the reason why Onion has elected to not build with POSIX Messaging Queues enabled (mqueue)? This is an essential part of messaging between threads and processes and is enabled in the Kernel by default by most Linux distros. It would only require to enable the flag CONFIG_POSIX_MQUEUE when building. This one flag is enabled by default but NOT enabled in Onion builds.
Enabling this feature would open up a lot of possible IPC features on your device.
Thanks,
Michael
-
Ok, b160 fixes the missing
/dev/memdevice so fast-gpio will now work correctly!.
Also, we're now building the firmware with POSIX Messaging Queues enabled!The issue was that our kernel config was setup to enable DEVMEM and DEV_KMEM, but for some reason the regular buildroot config had that disabled.
We're getting a better handle on the remaining shipments and the customer support backlog so we'll be spending more time actually making the Omega better in March. We hear what you guys are saying in terms of the community working the make the firmware better, so we will be open sourcing the firmware sometime in March as well
Thank you all for your continued patience and support for a young company
-
@Lazar-Demin said in do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600:
Ok, b160 fixes the missing
/dev/memdevice so fast-gpio will now work correctly!.
Also, we're now building the firmware with POSIX Messaging Queues enabled!The issue was that our kernel config was setup to enable DEVMEM and DEV_KMEM, but for some reason the regular buildroot config had that disabled.
What, already?
Amazing, it's only been several months now!
