I have been using a number of Raspberry Pi 4 devices running Raspbian Buster with the standard packaged version of Supercollider (3.10.0) sound synth for some time. Last week, an 'apt update & upgrade' stopped them all from working. This only affected the Raspberry Pi OS as the other versions on ubuntu (amd/intel) all continued to function. Installing ubuntu on the RPi4 was partially successful, but the sound output was badly distorted.
I could not find out whether it was a problem with Supercollider, Jackd or an updated OS file that either one of Supercollider or Jackd rely on. I tried a weeks' worth of fixes and solutions found elsewhere on the interweb, none worked, although error messages were similar.
I have finally got myself back to square one by reimaging with 2020-08-20-raspios-buster-armhf-full.img and NOT updating anything with 'apt update/upgrade'.
If anyone is interested in this issue being resolved and are able to provide me some useful tips on upgrading a bit at a time or comparing the files in two debian images, please let me know. Otherwise I will just continue with this old OS version and hope someone else fixes this issue before I have to apt update. Anyone else with this issue, I hope that knowing that 2020-08-20-raspios-buster is a potential solution will be of use to you.
I have tried so, so many different solutions and absolutely nothing worked, so no more suggestions like that please.
Here are the consistent error messages for users seraching:-
JackPosixProcessSync::LockedTimedWait error usec = 5000000 err = Connection timed out
Driver is not running
Cannot read socket fd = 5 err = Success
Cannot create new client
CheckRes error
JackSocketClientChannel read fail
Cannot open SuperCollider client
JackShmReadWritePtr1::~JackShmReadWritePtr1 - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
terminate called without an active exception
could not initialize audio.
ALSA: poll time out, polled for 34828070 usecs
JackAudioDriver::ProcessAsync: read error, stopping...
Related
I am running on a Windows 10 machine and want to install the flutter to my PC. Upon following the first step to install it I've been keeping stuck by this error. I thought re doing it would just get it over, but yeah no. it keeps on getting the error again. Could I get someone to solve this ?
remote: Enumerating objects: 289848, done.
error: 5920 bytes of body are still expected0 MiB | 29.00 KiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: index-pack failed
pls check here this is the msg I've been getting
Have you write rights on that location?
Does it work when you download the zip file from here https://flutter.dev/docs/get-started/install/windows and extract it in that folder? (note: if the context for admin rights pops up, it means you dont have write rights in there and you should activate the powershell with admin rights in the future)
First off, try instead using the Git desktop application. This will make it easier for you, as long as you don't need to do anything too complex on git, besides just cloning, pulling, pushing and merging with a master branch.
https://desktop.github.com/
Second, this is not an issue with flutter, this sounds like it might be a firewall issue. Do you by any chance have any antivirus software running that could be blocking the connection?
If that's the case for example, if you are running with AVG, just turn off the internet security option, then you should be able to clone the repo.
We are controlling a Keithley DMM6500 using the pyVisa library. In our setup, we are keeping an iPython kernel running (through Spyder).
The problem we're running into is the following: whenever a function that interacts with the DMM encounters an unhandled exception (like a KeyboardInterrupt), any subsequent calls to the DMM result in the error VI_ERROR_SYSTEM_ERROR (-1073807360): Unknown system error (miscellaneous error).
In order to fix this, we have tried to call device.clear() and device.close() / device.open(), but this doesn't seem to work. Even rebooting the device does not work. The only thing that fixes the issue, it seems, is to completely restart our iPython kernel.
Is there any way to programmatically restore communication with the device, such that we can avoid having to reboot the ipython kernel?
Some of your question is unclear so my answer might not help, however, it sounds like the terminal is locking the connection and you're loosing the reference.
The two way I have done this in the past:
Open the connection when talking to the device and close the connection when finished. This is useful if your connection is unstable but takes a fraction longer to open and close the connection a lot.
2)In your program you should have a try/except to handle the connection to the insturument and when the program errors you need to close the connection so that it doesn't become locked.
example:
try:
run_program()
except:
close_connection_to_all devices() # build a function to clear connection to all devices
dump_any_unsaved_data() # maybe you want to dump some of the variable to see what the data was when it errored for debug
I'm currently busy with my masters project which involves setting up comms on UART between a Raspberry Pi Model 2 B V1.1 and a Pixhawk Flight Controller using Mavlink protocol.
The first step is, of course, to get the UART set up and working. I'm not one to run after help at the first sign of a problem. I have been struggling with this for days and it's forced me to doubt the purpose of my existence more than once. I feel stupid and frustrated. Please see if you can provide any assistance.
My first resource was this tutorial, which should be relatively straight forward:
http://ardupilot.org/dev/docs/raspberry-pi-via-mavlink.html
The tutorial simply installs all the necessary packages and dependencies, as well as sets up the UART. I followed the steps to disable OS use of the serial port through raspi-config, however after attempting to test the connection I get an error:
[Errno 2] No such file or directory: '/dev/ttyAMA0'
Which is very strange. So after disabling and enabling OS use of serial port through rasp-config a few times and checking, every time I disable it, the /dev/ttyAMA0 file disappears. Now how the hell is anything supposed to work on the UART if disabling OS use of the UART removes that file!? Nevertheless I powered through. I enabled OS use of the serial port, which leaves the ttyAMA0 file right where it is and followed another suggestion, which is to change the /boot/cmdline.txt and remove all reference to ttyAMA0, as shown in the following link:
http://www.raspberry-projects.com/pi/pi-operating-systems/raspbian/io-pins-raspbian/uart-pins
This seemed to work alright. I could now initiate comms between the RPi and the Pixhawk flight controller and get some information that looked correct. Then the black magic started. The next day I tested the connection and it consistently spat out complete rubbish. But Nothing changed since the previous day. Somewhere I must be missing something. I followed all the same tutorials and steps attempting to get the more positive results I got the previous day. However that only led to more erratic behaviour. When connecting the serial lines to my Pixhawk Flight Controller, the keyboard/mouse seems to get interrupted momentarily every now and then. Everything just went backwards. I have already reinstalled Raspbian Jessie in a desperate attempt to get things to work.
Here are a few things I suspect could possibly contribute to the problems:
Baud rate not correct (to communicate with my Flight Controller baud rate needs to be 57600). Best way I've found to set this baud rate is to append "init_uart_baud=57600" to /boot/config.txt/. I have also read about other ways such as appending a line to /etc/crontab. Any suggestions?
Pixhawk miraculously and sporadically refused to communicate back with RPi.
Any assistance will be appreciated. Thank you.
SOLVED:
Looks like a known bug in the latest raspbian, easy to fix though.
These need to be done as the root user.
Disable "serial console" through GUI-preferences or "sudo raspi-config." Then reboot the pi.
Then change the following line in the file /boot/config.txt at the bottom of the file from:
enable_uart=0
to
enable_uart=1
Disable the ModemMonitor service by running the following command as root:
systemctl disable ModemManager.service
Then add youself to the dialout group, just to be sure you have the required permissions on the serial port:
adduser pi dialout
That should give you unrestricted proper access to the serial port.
Resources:
[url]https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=148515[/url]
and
[url]https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=82779[/url]
I had researched this for days now and troubleshooting all the readings listed on Google sites. I solved the serial UART settings for connecting my RPi3 Model B (typed at command line the following:
`cat /proc/cpuinfo`
to find my Pixhawk hardware info.)
FYI: You must be root when working with mavproxy so, sudo su
or sudo -s
Also, you must be a member of the dialout group, so do this at CMD line:
sudo usermod -a -G dialout root (enable root user!)
Do all the RPi regular stuff:
sudo apt-get update && sudo apt-get upgrade and sudo rpi-update.
Did all as outlined in the Ardupilot website. I did NOT use the
"apsync-rpi". (I used the 2017-03-02-raspbian-jessie.img.) at here
On my RPi3, using $uname -a: results--> Linux raspberrypi 4.4.50-v7+
My $sudo nano /boot/config.txt file has one change at bottom of file;
THIS statement: enable_uart=1 (has a good side effect of forcing the
core_freq to 250 which reduces poor signal frequency)
Important discovery: so the articles state that RPI3 UART and tty settings have changes. (link here)
What I have discovered after much ado is this for my sudo nano /boot/cmdline.txt file:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 etc.,.
-Notice I am not using ttyS0 in the /boot/cmdline.txt file. I tried the ttyS0 a dozen times and it never worked properly. For some reason, I am not able to explain it at this time, although the console=/dev/tty1 works if written in the /boot/cmdline.txt file.
Make sure you have the wiring correct between your RPi and the Pixhawk.
Telem 2. Also set the correct parameters in Mission Planner as I
have;
Go to CONFIGTUNING->STANDARD PARAMS; (my settings)
-The Serial0 baud rate(SERIALO_PROTOCOL) is: 115200
-The Console protocol selection(SERIAL0_PROTOCOL) is: MAVlink1
-Telem1 baud rate(SERIAL1_BAUD) is at: 115200
-Telem1 protocol selection(SERIAL1_PROTOCOL) IS MAVlink2
-Telemtry 2 Baud rate(SERIAL2_BAUD) is 921600
-Telemetry 2 protocol selection(SERIAL2_PROTOCOL) is MAVlink1
The RPi and pixhawk communicate at 921600 baud rate.
-Once I get the RPi3 powered up with it's own +5/VCC source and connect to my MP with a 3.0 USB cable from my PC-Windows10PRo, (okay, I have Arch and Debian Linux distros and Apple OSes too!) I enter:
`mavproxy.py --master=/dev/ttyS0 --baudrate 921600 --aircraft Plane`
It works for me!
Happy experimenting and flying!
This question is an extension for that question.
Yet again: I'm working under CentOS 6.0 and I have a remote win7 folder, mounted with:
mount -t cifs //PC128/mnt /media/net -o "username=WORKGROUP\user,password=pwd,rw,noexec,soft,uid=user,gid=user"
When remote folder is not available (e.g. network cable is pulled out) an attempt to access the remote folder locks an application I'm working on. At first I detected that QDir::exists() caused locking for 20-90 seconds (I still can't find out why such difference), further I detected that any call to stat() function leads to application lock.
I followed an advice provided in topic above, I moved QDir::exists() call (and later - call to the stat() function) to another thread and this didn't solve the problem. The application still hangs when connection is suddenly lost. Qt trace shows that lock is somewhere in the kernel:
0 __kernel_vsyscall
1 __xstat64#GLIBC_2.1 /lib/libc.so.6
2 QFSFileEnginePrivate::doStat stat.h
I did also tried to check if remote share is still mounted before trying to access folder itself, but it didn't help. Approaches such as:
mount | grep /media/net
show that shared folder is still mounted even is there is no active connection to the network.
Checking folder status differences such as:
stat -fc%t:%T /media/net/ != stat -fc%t:%T /media/net/..
also hangs for ~20 seconds.
So I have several questions:
Is there any way to change CIFS timeouts? I did try to find out but it seems that there is no appropriate parameters and no CIFS config.
How can I check if remote folder is still mounted and not get locked?
How can I check is folder exists and also not get locked?
Your problem: "An unreachable network filesystem" is a very well known example which trigger linux hung task which isn't the same of zombies process at all(killing the parent PID won't do anything)
An hung task, is task which triggered a system call that cause problem in the kernel, so that the system call never return.
The major particularity is that the task is declared in the "D" state by the scheduler which mean the program is in an uninterruptible state. This mean that you can do nothing to stop you program: You can trigger all signal to the task, it would not respond. Launching hundreds of SIGTERM/SIGKILL does nothing!
This the case whith my old kernel: when my nfs server crash, I need to reboot the client to kill the tasks using the filesystem. I compiled it a long time ago (I have still the build tree on my hdd) and during the configuration I saw this in lib/Kconfig.debug:
config DETECT_HUNG_TASK
bool "Detect Hung Tasks"
depends on DEBUG_KERNEL
default LOCKUP_DETECTOR
help
Say Y here to enable the kernel to detect "hung tasks",
which are bugs that cause the task to be stuck in
uninterruptible "D" state indefinitiley.
When a hung task is detected, the kernel will print the
current stack trace (which you should report), but the
task will stay in uninterruptible state. If lockdep is
enabled then all held locks will also be reported. This
feature has negligible overhead.
It was only proposing to detect such tash or panic on detection: I don't checked if recent kernel actually can solve the problem (It seems to be the case with your question), but I think it didn't worth enabling it.
There is second problem : normally, the detection occur after 120 seconds, but I saw also a Konfig option for this:
config DEFAULT_HUNG_TASK_TIMEOUT
int "Default timeout for hung task detection (in seconds)"
depends on DETECT_HUNG_TASK
default 120
help
This option controls the default timeout (in seconds) used
to determine when a task has become non-responsive and should
be considered hung.
It can be adjusted at runtime via the kernel.hung_task_timeout_secs
sysctl or by writing a value to
/proc/sys/kernel/hung_task_timeout_secs.
A timeout of 0 disables the check. The default is two minutes.
Keeping the default should be fine in most cases.
This also works with kernel threads: example: make a loop device to a file on a fuse filesystem. Then crash the userspace program controlling the fuse filesystem!
You should a get a Ktread which name is in the form loopX (X correspond normally to your loopback device number) HUNGing!
weblinks:
https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work (look at the answer written by ultrasawblade)
http://www.linuxquestions.org/questions/linux-general-1/kill-a-hung-task-when-kill-9-doesn't-help-697305/
http://forums-web2.gentoo.org/viewtopic-t-811557-start-0.html
http://comments.gmane.org/gmane.linux.kernel/1189978
http://comments.gmane.org/gmane.linux.kernel.cifs/7674 (This is a case similar to yours)
In your case of the three question: you have the answer: This probably due to what is probably a well known bug in the vfs linux kernel layer! (There is no CIFS timeouts)
After much trial & error I found a solution that persists.
# vim /etc/fstab
//192.168.1.122/myshare /mnt/share cifs username=user,password=password,_netdev 0 0
The _netdev option is important since we are mounting a network device. Clients may hang during the boot process if the system encounters any difficulties with the network.
https://www.redhat.com/sysadmin/samba-windows-linux
I am trying to make a 'dual core' RaspberryPi for a project I am working on. I had followed this tutorial by Simon Cox. Unfortunately I could not get the two RasPi to talk to each other. (This was using Hydra as the process manager)
After looking more carefully at the MPICH installers guide, which can be found here, I tried to use the -phrase to pass the passphrase I had created. However I could not find it as part of the hydra commands. So I re-installed with smpd and after many compiling attempts. I configured with:
/configure -prefix=/home/pi/mpich-install --with-pm=smpd --with-pmi=smpd
I also had to install libbsl-dev to get the MD5 that smpd requires. I also exported the path that the commands mpiexec and mpicc are in. After setting the passphrase I copied the image to a second SD card and put it in a second RasPi. I then set up the passphrase using ssh-keygen.
I was able to run the cpi program on the master Pi and the slave Pi individually but when I tried to run multiple processes on both at the same time I got the error
Fatal error in MPI_Init: Other MPI error, error stack:
MPIR_Init``_thread(392).................:
MPID_Init(139)........................: channel initialization failed
MPIDI_CH3_Init(38)....................:
MPID_nem_init(196)....................:
MPIDI_CH3I_Seg_commit(366)............:
MPIU_SHMW_Hnd_deserialize(324)........:
MPIU_SHMW_Seg_open(863)...............:
MPIU_SHMW_Seg_create_attach_templ(637): open failed - No such file or directory
Can someone please suggest how I can either fix this problem or get the RaspberryPis to communicate using MPICH?
Thanks
E.Lee
If anyone else has this problem make sure your hosts don't have the same name!
You can change it by following this tutorial http://raspi.tv/2012/how-to-change-the-name-of-your-raspberry-pi-new-hostname