When starting Xwayland to listen on TCP:
Xwayland :1 -listen tcp -ac &
...I get some errors like:
glamor: 'wl_drm' not supported
Missing Wayland requirements for glamor GBM backend
Failed to initialize glamor, falling back to sw
I've installed all of the dependencies that I think Xwayland needs...mesa, libdrm, intel driver, a.s.o.
How can I find out what is still missing here?
Related
I use Linux and mspdebug.
I use chinese MSP-FET430UIF.
I cannot connect or program my MSP430FR2476.
Is it possible with my programmer and mspdebug?
What can I do?
mspdebug -d /dev/ttyUSB0 uif
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 Daniel Beer <dlbeer#gmail.com>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Chip info database from MSP430.dll v3.15.0.1 Copyright (C) 2013 TI, Inc.
Trying to open /dev/ttyUSB0 at 460800 bps...
Initializing FET...
FET protocol version is 20406001
Set Vcc: 3000 mV
Configured for Spy-Bi-Wire
fet: FET returned error code 4 (Could not find device or device not supported)
fet: command C_IDENT1 failed
Using Olimex identification procedure
fet: FET returned error code 4 (Could not find device or device not supported)
fet: missing info
fet: identify failed
Trying again...
Initializing FET...
FET protocol version is 20406001
Set Vcc: 3000 mV
Configured for Spy-Bi-Wire
Sending reset...
fet: FET returned error code 4 (Could not find device or device not supported)
warning: fet: reset failed
fet: FET returned error code 4 (Could not find device or device not supported)
fet: command C_IDENT1 failed
Using Olimex identification procedure
fet: FET returned error code 4 (Could not find device or device not supported)
fet: missing info
fet: identify failed
I'm attempting to enable SSL on hiveserver2.
I can run in the default binary mode fine. http mode works no problem. As soon as I enable SSL through hive-site.xml, i'm faced with the following error.
ERROR [Thread-28] thrift.ThriftCLIService: Error starting HiveServer2: could not start ThriftHttpCLIService
java.net.BindException: Address already in use
There is nothing using any of the ports, prior to starting hiveserver2. Checked with netstat -tupln
Ports i've configured in hive-site.xml are
hive.server2.webui.port 11002
hive.server2.thrift.http.port 11001
hive.server2.thrift.port 11000
and invoking hiveserver2 via the service /opt/hive/bin/hive --service hiveserver2 &
O/S ubuntu (on kubernetes)
Hive version 3.0.0
Any help greatly appreciate. Google search for problems with ThriftHTTPCliService came up short.
For anyone that come across this post.
I upgraded to Hive 3.1.0, along with the metastore schema.
This fixed the issue, although unsure as to the underlying cause.
I have a custom nrf52 chip on a pcb with swd pins exposed. I have cloned and installed the latest openocd from https://github.com/ntfreak/openocd. The latest version includes all the latest pathes for the nrf52 chip, so no need for any additional changes as suggested in many older guides online. I am able to connect to the chip using ST-LinkV2. when connected I can read and write memory locations using mdw and mdb. I can also run some basic openocd commands like dump_image e.t.c, which confirms that the setup is good. But halt and program commannds always lead to errors like:
JTAG failure -4
JTAG failure -4
JTAG failure -4
JTAG failure -4
JTAG failure -4
JTAG failure -4
target halted due to debug-request, current mode: Thread
xPSR: 00000000 pc: 00000000 msp: 00000000
jtag status contains invalid mode value - communication failure
Polling target nrf52.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Previous state query failed, trying to reconnect
jtag status contains invalid mode value - communication failure
Polling target nrf52.cpu failed, trying to reexamine
if I try to use flash image_write I get the error,
JTAG failure
Error setting register
error starting target flash write algorithm
Failed to enable read-only operation
Failed to write to nrf52 flash
error writing to flash at address 0x00000000 at offset 0x00000000
in procedure 'dap'
jtag status contains invalid mode value - communication failure
Polling target nrf52.cpu failed, trying to reexamine
I have read different guides online, and one of the possible solutions involves the APPPROTECT register which has to be disabled to enable any writes to flash.
APP_PROTECT, But the dap commmand which is supposed to help us access this bit,
dap apreg 1 0x04 0x01
returns an error:
invalid subcommand apreg 1 0x04 0x01
Please, I will like to know if anyone has had success programming a new empty nrf52 chip with the stlink-v2 and the steps which are necessary, or if any one has encountered similar problems. Thanks.
Here is my config file:
#nRF52832 Target
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/nrf52.cfg]
#reset_config srst_nogate connect_assert_srst
I solved the "protected nRF52" chip problem this way, on Windows, using a Particle.io Debugger https://store.particle.io/products/particle-debugger setup to program nRF52 chips from Arduino as described in https://www.forward.com.au/pfod/BLE/LowPower/index.html
Note: The recovery process described here does NOT need Arduino to be installed
Download OpenOCD-20181130.7z pre-compiled openocd for windows from
http://gnutoolchains.com/arm-eabi/openocd/
The latest version of openocd src on https://github.com/ntfreak/openocd should also work as it includes the apreg cmd in target\arm_adi_v5.c
unzip, open cmd prompt to unzip dir, enter cmd
bin\openocd.exe -d2 -f interface/cmsis-dap.cfg -f target/nrf52.cfg
response
Info : auto-selecting first available session transport "swd". To override use '
transport select <transport>'.
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Error: Could not find MEM-AP to control the core
Info : Listening on port 3333 for gdb connections
Open telnet program eg teraTerm and connect to localhost on port 4444, i.e. 127.0.0.1 telnet port 4444
cmd window shows
Info : accepting 'telnet' connection on tcp/4444
in telnet (i.e. teraTerm) type
nrf52.dap apreg 1 0x04
returns 0 <<< chip protected
then
nrf52.dap apreg 1 0x04 0x01
then
nrf52.dap apreg 1 0x04
returns 1 << chip un-protected
then power cycle board
Can now use arduino ide to flash softdevice and code low power BLE
Even though the dap command is listed by openOCD help, it isn't implemented for transport hla_swd that you have to use with ST-Link.
If the ST-Link is a generic type from China, it can be upgraded to CMSIS-DAP which uses the swd transport and supports the nrf52.dap apreg 1 0x04 0x01 command to disable the readback protection and erase the flash. You'll need another ST-Link to do that, or you can instead install CMSIS-DAP on a generic STM32F103C8T6 board.
After that you can either use ST-Link to program the nRF52 or continue using CMSIS-DAP, which can also be used to program STM32 MCU.
Nucleo board embedded ST-Links can also be upgraded to J-Link, which allow the use of the "recover" option in nRFgo Studio to erase the flash, it should also work with "nrfjtool --recover" or OpenOCD.
If anyone encounters this problem, I solved the problem by getting an original Jlink-Edu. I also had to pull the reset pin of the microcontroller high to get the jlink working.
There are lots of JTAG messages.
I think you might be missing the
transport select hla_swd
line in your (board) cfg file. The NRF5x chips only work properly with SWD, and ST-Link uses the hla_swd variant.
I'm having trouble with setting up Sentry server in HTTPS mode. Every now and then, reasonably often while seemingly random, this error message gets written by Raven (Sentry client) into log files:
Unable to reach Sentry log server: <urlopen error [Errno 8] _ssl.c:504: EOF occurred in violation of protocol> (url: https://$(valid_server)/)
Web UI works fine. Vast majority of the messages from Raven are received fine and Sentry processes them into usable output. However, due to these errors, something gets lost from time to time.
I have tried to figure this one out, but dead ends seem to follow another. Basically it seems a lot like this:
Python Requests requests.exceptions.SSLError: [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
But when testing my Sentry server with similar s_client query using TLS 1.2, it leads to a valid session unlike with the example there.
It's also not about this, since SNI isn't used:
python-requests 2.0.0 - [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
I'm not able to reproduce the error coherently. Raven's tests are passed and nothing is acutely wrong, until an error pops up in the log.
My set up is: Raven 4.2.1 in Python 2.7.5, Nginx 1.6.0 as reverse proxy handling HTTPS, and finally Sentry 6.4.4 with default Gunicorn 0.17.4. Nginx configs are pretty much similar to official documentation (http://sentry.readthedocs.org/en/latest/quickstart/nginx.html) with a few alterations due to HTTPS.
I ran into the same issue and got it fixed by installing the following dependencies:
On Ubuntu:
sudo aptitude install libffi-dev
And then via pip:
pip install pyopenssl ndg-httpsclient pyasn1
The problem seems to be that Python 2.X doesn't support SNI (which is needed for TLS) out of the box as explained here.
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.