My server cpu is Intel(R) Xeon(R) Silver 4214 CPU # 2.20GHz The detail
I wonder why this CPU support TEE but don't support Intel SGX? whta's the point? is there any way I can install SGX by myself or run SGX program on this server?
Your CPU supports TXT (Trusted Execution Technology), not TEE (Trusted execution environment).
TXT is a different technology. You can read it up here.
I'm trying to upload code to an Arduino-Mega in Ubuntu 18.04. I'm using Oracle Virtual Machine to run Ubuntu and my computer is Win10.
From Win10, the port the Arduino is using is COM3. In the VM settings, I have these settings for Serial Port 1:
In Ubuntu, I run 'sudo arduino' in the terminal and compile my code.
In the Arduino IDE, the only Serial Port I can connect to is ttyS2:
When I try to upload the code, I get these error messages:
Before, I kept having the error message "Native Serial Port, can't obtain info", but now I just get these error messages.
Any help is appreciated, thank you everyone!
The issue was simple, I forgot to select the Arduino in the Ubuntu environment (Devices > USB > Arduino)
We have set up one VM (Virtual Machine) (Ubuntu Desktop 16.04) on VMM (virtual-manager) running QEMU / KVM. We are using Ubuntu Desktop 16.04 as our HOST OS. We execute suspicious C language code on our guest VM. We want to intercept certain instructions executed in the form of suspicious C language code on our guest VM from our HOST OS.
To accomplish this task, We are trying to capture Intel PT traces for our guest OS using the below command on our host. We're getting the following error when running this command on our terminal.
$ perf kvm --guest --guestkallsyms=guest-kallsyms --guestmodules=guest-modules record -e intel_pt//
Couldn't record guest kernel [0]'s reference relocation symbol.
" guest-kallsyms and guest-modules are the kallsyms and module files we copied from the guest onto our host. "
Does perf kvm command support intel_pt//?
Our System Configuration:
Operating System: Ubuntu 16.04.6 LTS
Kernel: Linux 4.15.0-66-generic
Architecture: x86-64
We are running docker 1.9 on rhel7 in test/prod. (installed from docker official repos)
Would like to use the overlay-network driver, but it requires kernel 3.16 according to the getting started guide.
RHEL7 runs a 3.10 kernel.
What are my options for using the docker overlay network driver with RHEL7?
I have tested flannel, but in my understandig flannel is external from docker, thus not being controlled via the docker network cli commands
Docker engine 1.10 will support overlay network on 3.10+ kernels according to the releasenotes of the first RC
https://github.com/docker/docker/releases/tag/v1.10.0-rc1
One option is to install a recent kernel through the Elrepo repository (http://elrepo.org). A quick start guide is available at http://www.certdepot.net/rhel7-install-recent-stable-kernel/.
However, the new kernel will avoid any Red Hat support.
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.