I need to use ttyS0 as serial communication in python script on my coral mini board, I disabled system service:
sudo systemctl stop systemd-logind
sudo systemctl stop serial-getty#ttyS0.service
But seems there still have output from Serial console in ttyS0 like:
IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
spidev spi0.0: SPI transfer timed out
I would like to know how to make the ttyS0 clean as no any other process using it, if its possible, better to do it in runtime.
Thanks!
I am trying to use RSelenium on a raspberry pi 3 B+. I managed to get R and RSelenium installed.
I first tried to use rsDriver(browser = "firefox"), but I did not manage to get it work (it ends up with an error saying Could not open firefox browser).
As it is recommended to use RSelenium with docker, I am trying to get docker run a Selenium/firefox standalone container.
I managed to get docker up and running. The hello-world run works, as well as an ubuntu bash (docker run -it ubuntu bash gets me an ubuntu terminal).
I pulled a standalone-firefox image with a given version (the 3)
here are the images I have:
ubuntu latest f576a39bda44 2 weeks ago 46.7MB
selenium/standalone-firefox 3 d803a00f9219 3 weeks ago 756MB
hello-world latest 618e43431df9 10 months ago 1.64kB
I then do
sudo docker run -d -p 4445:4444 selenium/standalone-firefox:3
But there is no container when I do docker ps, and
sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
351866263f7b selenium/standalone-firefox:3 "/opt/bin/entry_poin…" 10 seconds ago Exited (1) 6 seconds ago fervent_noether
shows that the container exited directly when executed. I tried with standalone-firefox:2.53.0 (pulling and executing), and it resulted in the same problem. What I am doing wrong ? The version of standalone-firefox is not supported by the raspberry pi ?
More generally, does someone know how to get RSelenium working on a raspberry pi (with firefox as browser)?
Edit
Following LinPy answer, I tried pulling docker images of selenium browsers compatible with the raspberry pi arm architecture. I found these:
https://hub.docker.com/u/kynetiv/
https://hub.docker.com/r/deinchristian/rpi-selenium-node-firefox
https://hub.docker.com/u/pun4drunk/
The docker containers ran without problem, but I never manager to have the remoteDriver connected to the broswer in RSelenium (different errors for different reasons, I do not detail here).
The only way I found to use RSelenium on the raspberry-pi without distant server was to execute the java selenium standalone server you can find here (I tried the 2.53.0):
java -jar selenium-server-standalone-2.53.0.jar
And then connect to it in R:
library(RSelenium)
rmDr <- remoteDriver(port = 4444L)
rmDr$open()
It was that easy in the end.
I think there is a missmatch between your app and the os ARCH . Actually it seems like application build for amd64, but you try start it on arm.
so check your Docker / APP versions and make sure they are compatible....
see this and this
You used the docker container incorrectly. You actually can see your container doing docker ps -a, but it is not good. You specified -p argument and didn't pass any port to that, and you passed the image without a tag. Follow the official documentation for this image and try again step by step:
https://github.com/SeleniumHQ/docker-selenium
I have a problem with my pl2303 converter. I'm using two of them like this:
LAPTOP <-USB-SERIAL-> <-SERIAL-SERIAL-> <-SERIAL-USB-> RASPBERRYPI
In other words, I'm connecting Raspberry Pi with my laptop using two usb-to-serial converters and having null modem in the middle.
I can communicate through minicom and "visually" it looks fine (all information is sent properly), but when I look into the logs it produces following dmesg output:
[ 343.390610] pl2303 ttyUSB1: pl2303_get_line_request - failed: -32
[ 343.685367] pl2303 ttyUSB1: error sending break = -32
I could live with that as long as everything works fine... but it doesn't. For example, I can't connect with RPi via ser2net. The "other side" simply doesn't get the messages. I suspect that this error is the cause of this problem. I was googling around, but I didn't find any solution. Could somebody help me with it?
Also - when I try to connect via ser2net, one thing breaks. Before that I can to stuff like
cat -v < /dev/ttyUSB0
and
echo "blablabla" > /dev/ttyUSB0
with success. After I try to connect via ser2net, it stops working and only minicom communication is fine.
To monitor a log file I have to connect to an ssh connection and redirect the output of the log file(let's call it RemoteLog.txt) out to a local machine so it can be read by a java program and put on a GUI.
Right now I have the output redirected out of the ssh connection and onto the local machine with the command:
ssh remote#ip.address tail logs/RemoteLog.txt -f > ~/Log/LocalLog.txt
and everything works fine technically with one exception: for some reason LocalLog.txt only gets updated with the changes to RemoteLog.txt every 35 seconds to the millisecond.
It doesn't matter the number of changes to RemoteLog, the number of lines specified with the tail command, or using the >> operator vs the > operator; there is always a 35 second delay between updates of LocalLog.txt while RemoteLog is constantly updating.
Does anyone have any clue why this might be?
I'm running a debian stable ThinkPad X1 (1294-3QG) with exactly three packages from squeeze-backports needed for the GraphicsModi:
initramfs-tools 0.99~bpo60+1
linux-base 3.4~bpo60+1
linux-image-3.2.0-0.bpo.2-amd64 3.2.9-1~bpo60
While running that kernel, starting for example paraview results in those errors:
Unrecognized deviceID 126
X Error: BadAlloc (insufficient resources for operation) 11
Extension: 154 (Uknown extension)
Minor opcode: 3 (Unknown request)
Resource id: 0x3200273
X Error: GLXBadContext 169
Extension: 154 (Uknown extension)
Minor opcode: 5 (Unknown request)
Resource id: 0x32002b0
paraview: ../../src/xcb_io.c:183: process_responses: Zusicherung »!(req && current_request && !(((long) (req->sequence) - (long) (current_request)) <= 0))« nicht erfüllt.
Somewhere on the net, I found the hint to offer the memory settings in the xorg.conf, but that did not solve my problem.
Starting within the current stable kernel works fine.
Running glxgearsresults similar:
Unrecognized deviceID 126
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Serial number of failed request: 27
Current serial number in output stream: 29
I further tried, to solve the problem by updating xserver-xorg-video-intel (and all dependencies libdrm-intel1 libxfont1, xserver-common, xserver-xorg, xserver-xorg-core, xserver-xorg-input-evdev, xserver-xorg-video-fbdev and xserver-xorg-video-vesa) to backports, but that was not prosperous.
Additional, I found the entry
[drm] MTRR allocation failed. Graphics performance may suffer.
in the output of dmesg.
I had the same issue on self-made server station with Intel i7 2700k (which has Intel HD 3000) running Debian Stable 6.0.4 (squeeze) x64. Basically I knew that this platform has loads of problems with unix systems (as always intel GPU does), but it purpose is server, so on-board graphic is fair enough for that. Anyways I wanted someday to run just a move (on TV connected via HDMI*/VGA), so I installed gnome-core with gdm3 to run manually.
With kernel 2.6.32-5-amd64 everything was excellent, besides few things, which forced me to upgrade kernel:
SSD support (added & improved from linux-image-2.6.33)
HDMI - no devices was recognized, couldn't add & change resolution (cvt xrandr).
So I added squeeze-backports to sources.list and upgraded only kernel (same what you did).
After that HDMI connection works great, but I noticed slow refresh rate - tearing during loading gdm3 login screen and after. I checked dmesg and kernel messages for some infos
cat dmesg | grep failed && cat dmesg | grep drm && cat /var/log/messages | grep failed && cat /var/log/messages | grep drm - found same. Than I run glxgears and found same error.
I was digging net for few days after some solutions and ideas.
Found many useless things about allocating RAM (enable_mtrr_cleanup) etc.
Basically for my hardly ever cinematic needs it wasn't tragedy, but I like when everything is perfect, so I still was working around to fix it.
And at last! Got it solved! Problem was not with the RAM or new kernel itself.
I have to mention here, that I compiled Debian kernel myself - 3.2 based on settings from previous install.
I removed also all unneeded libs for my architecture (i.e. libdrm for nvidia radeon and others - even VESA!!!)
I added just for a moment wheezy (testing) repositories, upgraded and installed new packages with dependences as root (only this ones):
echo deb http://ftp.pl.debian.org/debian/ testing main contrib non-free >> /etc/apt/sources.list
apt-get update
apt-get install --reinstall -t testing libdrm2 libdrm-intel1 xserver-xorg-video-intel xserver-xorg-core libgl1-mesa-glx libgl1-mesa-dri mesa-utils
dpkg-reconfigure xserver-xorg
That fixed all problems with rendering and allocation on Intel GPU :)
Think it should works for you and everyone with Intel GPU-s. Don't forget to remove wheeze (testing) from sources.list when you are done.
Regards, T_Send.
I solved it now on my own by updating some mesa concerning packages. I'm running debian stable with those following packages from backports:
initramfs-tools, libdrm-intel1, libgl1-mesa-dev, libgl1-mesa-dri,
libgl1-mesa-glx, linux-base, linux-headers-3.2.0-0.bpo.1-all-amd64,
linux-headers-3.2.0-0.bpo.1-amd64, linux-headers-3.2.0-0.bpo.1-common,
linux-headers-3.2.0-0.bpo.1-common-rt,
linux-headers-3.2.0-0.bpo.1-rt-amd64,
linux-headers-3.2.0-0.bpo.2-all-amd64,
linux-headers-3.2.0-0.bpo.2-amd64, linux-headers-3.2.0-0.bpo.2-common,
linux-headers-3.2.0-0.bpo.2-common-rt,
linux-headers-3.2.0-0.bpo.2-rt-amd64, linux-image-3.2.0-0.bpo.2-amd64,
linux-kbuild-3.2, mesa-common-dev
Hoping this info will help other, too.