Error message "ioctl_set_msg failed:-1" when trying to transmit.

[varpus]

I'm able to transmit a test tone but can't seem to run the program normally. It get just past the point of telling me NTP will be used to periodically Calibrate the Transmission frequency. Transmission will continue forever until stopped with CTRL-C. Then this:

ioctl_set_msg failed:-1 ioctl_set_msg failed:-1

And the pi zero locks up.

Not sure what to do to fix this or if it's a bug in the software. I'm running the latest Jessie on a PI Zero version 1.3.

[itdaniher]

6 also saw a lockup on latest Jessie...

[Manawyrm]

second this, running on ArchlinuxARM, locks up.

[JamesP6000]

Can you send the actual command line that you used? I have an old RPi1, latest Jessie, and I'm not seeing any hangups. I've been told (but have no direct experience) that this code works as-is on the Zero.

JP

[Manawyrm]

I tried (as root) ./wspr --test-tone 780e3 and ./wspr --test-tone 144e6 I think the problem might have to do with the MAJOR_NUM hardcoded in mailbox.h.

I'm using ArchLinux ARM (this happens on Pi Zero and Pi 3, btw), which uses a recent kernel, and it seems that the major num of /dev/vcio is not longer 249, but 248. I've tried to change that, but it didn't help unfortunatly.

[JamesP6000]

Not sure how I can help with ArchLinux... I'm not at all familiar with that OS and this code was developed first on Raspbian then Jessie.

JP

[Manawyrm]

I fear that this issue is going to come to raspbian in the next release as well, ArchLinux is just more recent. Maybe rpi-update on a Raspbian could make this issue happen?

[varpus]

It's already in Raspbian. That is what I was using. I can install an older version and it works but when I update it stops working. Same error that points to the mailbox.h being the issue every single time I test with the latest version of the Raspbian. There needs to be a warning issued that this software won't work on the newest releases out for the Raspberry Pi until the problem is fixed.

[JamesP6000]

On another thread, it was the GUI that was causing the problem. Are you guys using the GUI?

JP

`** PWM Peripheral:

---

The code uses the RPi PWM peripheral to time the frequency transitions of the output clock. This peripheral is also used by the RPi sound system and hence any sound events that occur during a WSPR transmission will interfere with WSPR transmissions. Sound can be permanently disabled by editing /etc/modules and commenting out the snd-bcm2835 device.`

[Manawyrm]

No gui, I also tried to unload snd-bcm2835, didn't help either.

[varpus]

It didn't work for me either. I also tried it in Jessie Lite and it still hangs up.

[wwinzig]

Same story here...not working on a Raspi1 and crashing with _ioctl_setmsg failed:-1 Whats interesting.... If you reboot the Raspi afterwards wspr in general is not working anymore. If you issue a simple wspr -h it comes back with nothing or it crashes as well. If you recompile -h shows again output. Weired... RasPi2 and higher works without any issues. Seems to be a problem with Raspi1 only.

[th0ma5w]

FWIW I commented on the other issue what I had been seeing for a few months, random crashes, but since the latest updates I'm now getting the issue represented her verbatim.

[th0ma5w]

So I rolled back to 6fb46c5ac4874a88db9fa7535c27c985810851ab ... sort of arbitrarily picked because it is before some things in the logs that mention the RPi2 ... anyway... works fine on the RPi1. So, sorry I haven't spent the time to try out every checkin since then, but could be an option for others. make clean; git checkout 6fb46c5ac4874a88db9fa7535c27c985810851ab; make clean; make; ....

[mustafatan75]

Same issue with Zero + TAP2 20M WSPR-Pi :( but works fine with Raspberry 3 + TAP2 20M WSPR-Pi :)

[jcp-sd]

I've been running the WsprryPi code I checked out back in late 2014 with no problems on updated Wheezy and Jessie systems (all original 700 MHz ARMv6l SoC systems).

When I tried PiCW for the first time on an updated Jessie system (Linux raspberrypi 4.9.24+ #993 Wed Apr 26 17:56:54 BST 2017 on an original 700 MHz ARMv6l SoC), it locked up my RPi just as noted in the posts above. So I tried the newest WsprryPi source code out of curiosity, and it too froze my RPi, (so the rest of this post is about the newest WsprryPi code).

The wspr program printed "ioctl_set_msg failed:-1" twice, so I did a bit of digging into the source code to see where those messages were coming from, which appeared to be somewhere in the "mailbox" functions in mailbox.c file. After adding some additional code to catch and print errors in those functions, it's mem_alloc() and mem_lock() that were failing! I added a call to perror() in the mbox_property() functionfor the case when the ioctl returns an error. I got: "Inappropriate ioctl for device".

After one of the reboots, I got a lucky break. I had read enough source code to know /dev/vcio was relevant, and happened to do a long list on /dev to see if that device node had been created by the kernel. I had seen mention of major numbers of 249 and/or 100, but to my surprise; it was/is 248 on my system. (It's 249 on another armv6 RPi running updated Wheezy). Listing is here;

# ls -l /dev/vc* crw------- 1 root root 250, 0 May 12 19:11 /dev/vc-cma crw------- 1 root root 249, 0 May 12 19:11 /dev/vc-mem crw-rw---- 1 root video 246, 0 May 12 19:11 /dev/vchiq crw-rw---- 1 root video 248, 0 May 12 19:11 /dev/vcio ...snip... crw-rw---- 1 root video 245, 0 May 12 19:11 /dev/vcsm

I uncommented some of the debug code already in mbox_open(), and discovered the program was creating it's own device node with major number 249, which corresponds to /dev/vc-mem on my RPi. Not sure when this changed, but no wonder things went badly wrong!

I rewrote the code to setup the communication with /dev/vcio and can make it available for others to test (works fine on the systems I have available). The code first tries to open /dev/vcio. If that fails, only then is an attempt made to create a new device node, first with major number 249, then with 100. (I really didn't see any good reason to ever unlink /dev/vcio, so I removed all of the existing code that did that).

If anyone wants to try my fixes applied to 8764a6f7.. , it's here: https://github.com/jcp-sd/WsprryPi

Note: If you ever run the 8764a6f7.. version (and possibly other recent ones), you will need to reboot your RPi (as it deletes the /dev/vcio device node created by the kernel at boot).

[mustafatan75]

Thanks jcp-sd. It works now 👍

[JamesP6000]

John, this is really great! Can you send me a pull request so I can merge the changes?

Thanks, James

[jcp-sd]

Just created a pull request: https://github.com/JamesP6000/WsprryPi/pull/9

The important changes are to the mbox_open() and open_mbox() functions. The remaining changes are not required but should greatly improve error handling should similar issues appear in the future.

The rest of the week will be a little on the busy side, but I will merge these changes into PiCW when I get a chance as my recent attempt to use that program is what brought these issues to my attention.

73, John

[JamesP6000]

Thanks John! Just approved the pull request but I'll keep the warning in the README for a few more weeks to see if anyone else still has problems. Feel free to send me a pull request for PiCW when you're ready!

Have you had any contacts with PiCW? I only TX at QRP power levels and was never able to find my calls on the RBN. WSPR works just fine though.

James

[jcp-sd]

Hi James,

Here is a pull request for the (essentially same) changes to PiCW: https://github.com/JamesP6000/PiCW/pull/6

My first attempt to run PiCW was only a week ago or so, and it always crashed, so not much experience with it to date. Getting heard on RBN sounds like a pretty high bar to clear when transmitting CW at only 10mW. I was planning to try a local QSO with friends by ground wave or maybe NVIS, but I suspect even that will be a challenging task. I have made a dozen or so transmissions this evening and everything seems solid on my RPI1 with the new changes, so let the experiments begin!

P.S. I was going to suggest someone post a followup to the other open issue https://github.com/JamesP6000/WsprryPi/issues/6 that looks to me to be a duplicate of this one...

73, John