#1

first draft is here: https://monome.org/docs/raspbian/

i have serialosc running fine on the newest raspbian stretch.

all suggestions and edits welcome! https://github.com/monome/docs

9 Likes
#2

@tehn I’ll probably do some PRs to update the Linux docs if that’s OK. They are pretty old, so could use some updating :slight_smile:

I was wondering if you (or someone else) knows for which distros packages have been created for libmonome and serialosc?

#3

that’d be immensely appreciated. i’m not sure which distros have relevant packages at this point, i’d be curious!

#4

I know the Arch packages in the AUR, and I’m working on packaging them for gentoo (that’s where the recent PRs are coming from :)).
I’ll search around if I can find packages for other distros. Will add a list with links to the linux setup page with the ones I can find.

#5

Tried this on the beaglebone black with ununtu and Debian. I get segmentation faults when running serialoscd.

Any tips or ideas how I can debug/fix this?

#6

what grid device are you using? does it always segfault or just sometimes? is this a hotplug issue or is the grid plugged in at boot?

i don’t have an immediate answer unfortunately and linux serialosc debugging is an upcoming priority

#7

2012 64, and 2009 256
Tried hotplugging, plugging on boot, plugging before and after running serialoscd. Segfault everytime. Happy to keep looking into this.

#8

I need to confirm this is the case but I believe I got the segfaults to go away after rebuilding serialosc against a newer version of libuv.

In my case I’m using an aarch64 (arm) linux 4.11.2 machine (which is neither an rpi3 nor a beaglebone)

#9

just a wee update. running directly works:

$ serialosc-device /dev/ttyUSB0

#10

Which version of libuv did you use?

#11

@simonvanderveldt Looking at my build directory I just pulled down the latest on the v1.x branch - at the time I built that branch was pointing at https://github.com/libuv/libuv/commit/c78caf0b34c18f62a945659eacf63cfb5a3c8396

Assuming you have cloned the serialosc source just cd into the third-party/libuv directory and:

  • git fetch origin
  • git checkout v1.x
  • rebuild

Hope that helps - I haven’t done a tone of stress testing since but hot plugging the devices I have was working well (arc2, arc4 2016, walnut grid 128).

edit: I should add that it had been my intention to do a bit more testing across macOS as well then if all appeared good, submit a pull request which bumps up the libuv dependency. Unfortunately I’ve been bogged down with other work.

#12

Hi everyone! I think I’ve just enabled ARM builds for libmonome and serialosc in my monome PPA. In theory, the debs should work on Raspbian too. Could anyone with a RasPi nearby verify that?

1 Like
#13

well i downloaded libmonome1_1.4.0+git20171023-0ubuntu1~artful1_armhf.deb and serialosc_1.4+git20170927-0ubuntu1~artful1_armhf.deb and installed them on an RPi 1 (armv6) running Rapsbian and got the following:

  • serialoscd and serialosc-detector return Segmentation fault
  • serialosc-device /dev/ttyUSB0 returns Illegal instruction

Before installing i did ./waf uninstall the existing libmonome and serialosc on that machine, and deleted the .config/serialosc directory.

On an RPi 2 (armv7) running another (~2016) Raspbian install, the packages installed fine but serialoscd also segfaults instantly if the grid is already connected, or does as soon as a grid is plugged in. If i then kill the remaining serialosc-detector process, and launch serialosc-device /dev/ttyUSB0, the grid is recognized (after printing sosc_zeroconf_init(): couldn't load libdns_sd.so).
After that (which creates the config file), serialoscd works as expected but segfaults after 3 hotplugging cycles. (edit; it still segfault if the grid is plugged when executing, and randomly after 3-4 hotplugging cycles).

1 Like
#14

Thanks! RPi1 isn’t exactly armhf, so yeah, Launchpad build won’t work on them. The segfaults on your RPi2 are interesting though, the hotplugging one also reproduces on x86 Linux sometimes, I think.

#15

just thought i should mention that a few months ago i used libmonome in a C program to read grid devices directly over serial under raspbian (so, same usage as in serialosc-device.)

encountered persistent segfaults on disconnect and traced this to a bad check on posix FD reads, which propagated a garbage device pointer. this PR seemed to fix it: https://github.com/monome/libmonome/pull/48

so, i guess make sure serialosc is being built against recent enough libmonome sources (which looks like it probably is)

1 Like
#16

Yeah, the PPA packages above are all latest git versions. I’ll try tracing the segfaults on an actual RPi over the weekend too and see if anything turns out. It would be nice to have a stable binary repo option for Raspbian systems in the end.

2 Likes
#17

cool, in that case i’d guess that its something on the zeroconf side and not libmonome<->serial, just based on the fact that i’ve had no libmonome stability issues on similar setups in the last 6 months. (also the missing dylib error…)

1 Like
#18

Thanks for the info! Was asking because of this issue https://github.com/monome/serialosc/issues/30.
I already have this working locally and am currently using libuv 1.10.2 from my distro. Unfortunately every now and then (say once in two weeks) I still run into a segfault. Looks like you’re on 1.15.0 so I’ll give that one a try and see if that fixes it.

Note I’ll probably create a PR this weekend to enable the use of system libuv, so if you use Linux and your distro has a libuv package that can be used instead of the git submodule.

Also for anyone running into segfaults, can you check if you get the same backtrace as in this issue? https://github.com/monome/serialosc/issues/22

#19

Sounds good. For what its worth the system I’m using is a nanopi NEO2 running a custom built kernel combined with ubuntu 16.04 packages. I haven’t investigated using the libuv as supplied by the system.

I haven’t ever heavily loaded the nanopi NEO2 so I can’t add any more insight regarding the possibility load related SEGVs.

#20

Whilst the segfault issue mentions it might be caused by load at the moment I’m not sure that’s the case, I’ve had a segfault with the same backtrace once whilst I had pretty much no load at all, so I personally am not sure the load is related to the segfaulting.

I guess what I am trying to say is, even if you don’t have a high load and you do experience a segfault please let us know :slight_smile: