After the SDK upgrade to Android 5, I cannot use the Intel Hardware Accelerated Execution Manager:
$ android-sdk-macosx/tools/emulator -avd AVD_for_LowMemoryDevice_by_User -netspeed full -netdelay none -gpu on
HAX is working and emulator runs in fast virt mode
emulator: VCPU shutdown request
EAX=80000001 EBX=019a0000 ECX=c0000080 EDX=00000000
ESI=00013c40 EDI=01d9d000 EBP=00100000 ESP=004f6104
EIP=001000f0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
CS =0010 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
FS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
GS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
LDT=0000 00000000 00000000 00008200 DPL=0 LDT
TR =0020 00000000 00000fff 00008b00 DPL=0 TSS64-busy
GDT= 00000000004ea098 00000030
IDT= 0000000000000000 00000000
CR0=80000011 CR2=0000000000000000 CR3=0000000001d97000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
emulator: VCPU shutdown request
Any ideas as to how to fix it?
(platform: OS X 10.10, java version "1.8.0_25")
I had the same issue when creating a Nexus 6 AVD with an x86_64 image and it appears the HAXM does not support that on an old Core 2 Duo (Mac Book Pro late 2009 for example).
This is specified in the Release note known issues in $ANDROID_SDK_HOME/extras/intel/Hardware_Accelerated_Execution_Manager.
HAXM driver does not support emulating a 64 bit system image on Intel
systems based on Core microarchitecture (Core, Core2 Duo etc.). All
systems based on Nehalem and beyond are supported. (Corei3, Core i5
and Core i7 machines).
Try the newest HAXM provide in Intel official site https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager-end-user-license-agreement-macosx ,now is 1.1.1.The one which from sdk manager is still old 1.1.0.
it works for me.
It seems that the SDK manager automatically installs HAXM 1.0.8 instead of 1.1.0/1.1.1. To fix this, navigate to
<android-sdk>/extras/intel/Hardware_Accelerated_Execution_Manager
and reinstall HAXM by executing
$ chmod +x silent_install.sh
$ sudo ./silent_install.sh -u
$ sudo ./silent_install.sh
The emulator should boot properly now.
Upgrading to the latest HAXM may not be enough (current version to date is 6.0.1).
You can still begin with a HAXM update, but if you run an older CPU such as a Core 2 Duo, you should definitely choose an x86 version of your virtual image, not x86_64.
When I started my first wear emulator it was fine until today when after restarting my MacBook Pro I've experienced the crash VCPU shutdown request.
The version of HAXM I'm using is 1.1.4. So I tried restarting, recreating emulator images... Nothing worked until I've reinstalled the HAXM driver using .dmg installer in /extras/HAXM... folder. Just FYI
I recently upgraded to El-capitan os, and I've encountered same problem.
First, uninstall HAXM throughly.
sudo /Library/Extensions/intelhaxm.kext/Contents/Resources/uninstall.sh
sudo rm /System/Library/LaunchDaemons/com.intel.haxm.plist
Second, reinstall HAXM with latest version.
https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager
This solved problem for me.
Following is the link i referred to HAXM on OS X keeps on disappearing
Solved!
Apparently, I was using HAXM 1.0.8 which is the latest version that is available at Intel's site. However, Android SDK Manager downloads a preview version on HAXM 1.1.0 which is required to run 64bit images.
If you are using Android Studio 0.8.13 or older, then upgrade it to latest. This issue is fixed in 0.8.14 Release.
It works with the latest Android studio after upgrading the SDK component to:
Intel x86 Emulator Accelerator (HAXM installer), revision 5.2
Solved the issue. You need to do these things:
Uninstall old HAXM:
sudo /System/Library/Extensions/intelhaxm.kext/Contents/Resources/uninstall.sh
Disable kext signing: apparently HAXM 1.1.0 is not signed appropriately
sudo nvram boot-args="kext-dev-mode=1". Reboot
Install the new HAXM 1.1.0 as usual (notice that if you don't disable kext signing, haxm will refuse to install with the error that VT/NX is disabled)
Add $ANDROID_HOME/tools/lib to your $LD_LIBRARY_PATH
API 21 AVD images work without a hitch for me now.
Source: http://www.csell.net/2014/09/03/VTNX_Not_Enabled/
Try to reduce Memory Limit used by HAXM.
https://software.intel.com/sites/default/files/managed/86/82/ss-mac-3.png
This works for me.
1- Update HAXM Accelerator to revision 5.2 From your SDK Manager
2- Install the new Updated HAXM (no need to uninstall the previous) -> (Restart the System)
3- Make the AVD of Lollipop Using following Configuration.
hope this helps
Now there is a new version HAXM 1.1.1 and it has a different version for Mac OS <10.9 and >10.9.
Updating HAXM from download manager worked for me. It's not downloaded automatically when you upgrade your system to android 5.x
if after the update it still doesn't works get a wipe data on your emulator and don't load it from snapshot because the problem is here, it's corrupted
it just happend to me right now and iv got it solved this way
I had a similar issue when I booted a Vagrant VM simultaneously. It then sent a VCPU shutdown request. Also the Android emulator wouldn't boot when a Vagrant VM was running. I hope this could help anyone.
emulator: VCPU shutdown request
EAX=00000000 EBX=c085e000 ECX=01000000 EDX=00000000
ESI=00000000 EDI=c0860000 EBP=c085ffbc ESP=c085ffb4
EIP=c02065cf EFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =007b 00000000 ffffffff 00c0f300 DPL=3 DS [-WA]
CS =0060 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =007b 00000000 ffffffff 00c0f300 DPL=3 DS [-WA]
FS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
GS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
LDT=0000 00000000 00000000 00008200 DPL=0 LDT
TR =0020 00001000 00000067 00008900 DPL=0 TSS32-avl
GDT= 0086a2c0 0000001f
IDT= 00000000 00000000
CR0=8005003b CR2=b6ec0004 CR3=3666b000 CR4=00000690
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
emulator: Failed to sync vcpu reg
Related
When I run MDART routing protocol tcl script in NS 2.35, it says:
When configured, ns found the right version of tclsh in /usr/bin/tclsh8.6
but it doesn't seem to be there anymore, so ns will fall back on running the first tclsh in your path. The wrong version of tclsh may break the test suites. Reconfigure and rebuild ns if this is a problem.
num_nodes is set 16
INITIALIZE THE LIST xListHead
channel.cc:sendUp - Calc highestAntennaZ_ and distCST_
highestAntennaZ_ = 1.5, distCST_ = 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0
SORTING LISTS ...DONE!
Segmentation fault (core dumped)
And the simulation end time supposely end at 205s but when run the animation, the simulation end at 8s. Why is that? Thanks
ns found the right version of tclsh in /usr/bin/tclsh8.6
but it doesn't seem to be there anymore
tcl8.6 : You are supposed to use the "ns-2.35 tcl8.5.10" : It doesn't change version or location. (Unless you move ns-allinone-2.35). The external tcl8.6 can change with e.g. an update. And later versions tend to be missing some files, e.g. in Debian / Ubuntu.
Example https://drive.google.com/file/d/0B7S255p3kFXNVVlxR0ZNRGVORjQ/view?usp=sharing
$ tar xvf ns-allinone-2.35_gcc5.tar.gz ## 2014 - 2017 update
$ cd ns-allinone-2.35/
$ export CC=gcc-4.8 CXX=g++-4.8 && ./install
Segmentation fault
MDART cannot be used with a contemporary OS. The latest that worked was an Ubuntu 18.04.4 updated 16 months ago. Please see my tests https://drive.google.com/drive/folders/1si2jA3lc-23lubVHb3tFbIAXfnhRfg5O?usp=sharing ..... CentOS 8 fails, Ubuntu 20.04 fails. Etc. "2021 OS" fails.
EDIT : Further tests revealed that an updated Ubuntu 18.04 failed : The latest Ubuntu version for MDART is 16.04 .
NOTE 1: The Ubuntu 16.04 nam package is corrupt. Please use https://drive.google.com/file/d/0B7S255p3kFXNdmxzSmRzaVRWb28/view?usp=sharing → nam_1.15-10-ubuntu14_amd64.deb
NOTE 2: The Ubuntu 16.04 ns command : sudo apt install ns2
NOTE 3: Building ns-allinone-2.35/ → Four cases of random Tk errors after the latest Ubuntu updates. Possible solutions: Use ns-allinone-2.35_2021.tar.xz https://drive.google.com/file/d/167cP7hPnJGiNL3rK4Mxnh_-0t7_S8FTL/view?usp=sharing with Tcl, Tk updated to version 8.5.17 .... And there are three options for extra gcc/g++ compilers to try out https://drive.google.com/drive/folders/1xVEATaYAwqvseBzYxKDzJoZ4-Hc_XOJm?usp=sharing
export CC=gcc447 CXX=g++447 && ./install ## can also be used with ns-allinone-2.35 version 2011
export CC=gcc48 CXX=g++48 && ./install
export CC=gcc54 CXX=g++54 && ./install
Simulation time : The setting is maximum time. Example : The setting set val(end) 1006.0 will run about 6 seconds and end the output text with : 1000 simulation seconds ....... Time is relative. ns2 was developed in the 90th when processors were very slow Pentium 1 / Pentium 2 . ... And different protocols behave different with simulation time.
DraftSight 2017SP1 Linux (beta) worked on Fedora 24. It fails after upgrading to Fedora 26. Running it from the command line so you can see the low-level errors,
/opt/dassault-systemes/DraftSight/Linux/DraftSight
Qt: Session management error: None of the authentication protocols specified are supported
Could not parse stylesheet of object 0x238a050
Could not parse stylesheet of object 0x238a050
In the graphics environment you see the usual start screens, then error pop-ups which offer to report the error and then close the application when clicked. One says that error-reporting is not available.
Similarly with 2017SP3 and 2018SP0. Fedora updates are current as of today.
This system is an Intel core i3. lspci reports "Intel Corp Xeon E3-1200 v3/4th Gen core processor Integrated Graphics Controller (rev 06)"
2018SP0 does work once an Nvidia GT710 card and the nvidia driver module are installed. It does not work with the nouveau driver module and the same card.
Does anybody have any insight as to the cause? A regression in Fedora, or a latent bug in DraftSight, or anything else?
Knowing whether it works with Fedora 26 and AMD graphics might be very helpful.
Edit March 2018
Doesn't work but differently on a system with AMD R5 230. No "Could not parse" errors, not anything else on the terminal window, but Draftsight starts up with the display all wrong and then locks up. Clicking the "X" gets to "the program is not responding".
Also worth noting that this isn't a Wayland issue. Systems are running Cinnamon and lightdm, so it's good old X.
Also a work-around, if performance is unimportant. (And it probably isn't, with Gen 4 Intel Graphics). Run it as a "remote" application on localhost, on a system with Intel graphics.
$ ssh -X 127.0.0.1
password:
Last login: Wed Mar ...
-bash-4.4$ /opt/dassault-systemes/DraftSight/Linux/DraftSight
(success)
Further update Fedora 29, DraftSight 2018SP3
New wrinkles for Nvidia, Cinnamon as above
Needs invocation
LD_PRELOAD=/usr/lib64/libfreetype.so.6 /opt/dassault-systemes/DraftSight/Linux/DraftSight
otherwise fails with /lib64/libfontconfig.so.1 lookup error FT_DOne_MM_Var
Also kernel 4.20 plus NVidia 390.87 fails to build. There's a patched NVidia installer that does work at if_not_false_then_true site.
Also does not install a .desktop file into /usr/share/applications
I had similar problems when I updated Fedora 24 to 25. The parse stylesheet messages still show up but I can run draftsight from an Xorg session, (not Wayland), using the nouveau drivers but only under root privileges using sudo .
You might try the following script:
sudo DISPLAY=$DISPLAY vblank_mode=1 /opt/dassault-systemes/DraftSight/Linux/DraftSight
I can only get DraftSight to run as root under Fedora 27, 4.18.16-100.fc27.x86_64. I have installed a VM with Ubuntu, and it runs fine, without elevated privileges.
Yesterday i downloaded GlassFish 5.0 and JDK9. When I'm trying to run server with asadmin start-domain GlassFish send to me exception
When I try to use "asadmin start-domainAfter" I got respond: "Remote server does not listen request on [localhost 4848]. Is the serwer up?"
Any can help me with this? I looked for solution at google, I tried kill process using port 4848, change port 4848 in domain.xml on another one, nothing helps.
It's my firts time with glassfish I don't know what to do. Anyone can help me?
I'm working at windows 7, InteliJ Ultimate 2017.2.4, JRE 1.8 and JDK 9.
GlassFish 5.0 not starting on JDK 9 is a known issue.
GlassFish 5.0 is certified only on JDK 8 (u144) as stated in the release notes:
https://javaee.github.io/glassfish/doc/5.0/release-notes.pdf
I use Windows 10 and I have installed JDK and JRE for version 9 and 8u141, 8u151, 8u144 (installed for test about this problem)
For exception I had had the same problem : the command "asadmin start-version" throw an exception.
Just check the version from CMD console :
C:\Users\xxxxx>**java -version**
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
Problem JAVA_HOME and PATH environment viariables are JDK8u151 ???
To solve the problem, the documentation advice that :
Alternatively, you can specifically set the Java path with the AS_JAVA property in the in the as-install/config/asenv.conf file.
C:\DEVENV\glassfish5\glassfish\config>dir
Le volume dans le lecteur C s’appelle OS
Le numéro de série du volume est 10BF-2BBE
Répertoire de C:\DEVENV\glassfish5\glassfish\config
08/09/2017 07:27 <DIR> .
08/09/2017 07:27 <DIR> ..
12/01/2018 17:44 3 516 asenv.bat
...
Consequently, I add the last line below :
set AS_IMQ_LIB=..\..\mq\lib
set AS_IMQ_BIN=..\..\mq\bin
set AS_CONFIG=..\config
set AS_INSTALL=..
set AS_DEF_DOMAINS_PATH=..\domains
set AS_DEF_NODES_PATH=..\nodes
set AS_DERBY_INSTALL=..\..\javadb
**set AS_JAVA=C:\Program Files\Java\jdk1.8.0_151**
Relaunch CMD console and start server with asadmin start-domain : it works properly....enjoy.
As mentioned above GlassFish 5.0 leverages new features in Java SE 8,
and is certified today on Java SE 8. Even though we have a lot of work
in front of us with the transition to the Eclipse Foundation, our
current intent is to certify Java SE 9 in an upcoming GlassFish 5
release.
JDK 9 should be supported in the next update, i.e. GlassFish 5.0.1
See end of https://blogs.oracle.com/theaquarium/java-ee-8-is-final-and-glassfish-50-is-released
If you are on a mac or linux machine, add the following to config/asenv.conf in your glassfish installation directory.
set AS_JAVA="path to your jdk 8"
For example, in Mac OS it will be
AS_JAVA="/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home"
Anyone having problems with NullPointerException, look out for your system PATH Variables. Be sure that they point to an acceptable JDK (As it was said before: GlassFish 5.0 is certified only to work on JDK 8u144). This NullPointerException is caused by using an incompartible JDK as mentioned here: https://docs.oracle.com/cd/E19226-01/820-7688/gipqi/index.html
In my case the PATH variable was correctly pointing to java8u144 bin, but my PATH also contained a pointer to C:\ProgramData\Oracle\Java\javapath. And someway an old version of java SDK was stored on \ProgramData\Oracle so GlassFish was using this old version of java as SDK.
I'm using chromedriver with https://chrome.richardlloyd.org.uk/ solution for my CentOS 6.6 machine and found that for chromedriver 2.29 it is asking for GLIBC_2.14, but for 2.28 it is not. Is it an issue or jus as planned ?
Kernel: 2.6.32-573.26.1.el6.x86_64
Libstdc:
[mdvoryanchenko#serv ~]$ strings /opt/google/chrome/lib/libstdc++.so.6 | grep -e 'GLIBC*'
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBC_2.3
GLIBC_2.2.5
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
The Situation
I have a 2 gpu server (Ubuntu 12.04) where I switched a Tesla C1060 with a GTX 670. Than I installed CUDA 5.0 over the 4.2. Afterwards I compiled all examples execpt for simpleMPI without error. But when I run ./devicequery I get following error message:
foo#bar-serv2:~/NVIDIA_CUDA-5.0_Samples/bin/linux/release$ ./deviceQuery
./deviceQuery Starting...
CUDA Device Query (Runtime API) version (CUDART static linking)
cudaGetDeviceCount returned 38
-> no CUDA-capable device is detected
What I have tried
To solve this I tried all of the thinks recommended by CUDA-capable device, but to no avail:
/dev/nvidia* is there and the permissions are 666 (crw-rw-rw-) and owner root:root
foo#bar-serv2:/dev$ ls -l nvidia*
crw-rw-rw- 1 root root 195, 0 Oct 24 18:51 nvidia0
crw-rw-rw- 1 root root 195, 1 Oct 24 18:51 nvidia1
crw-rw-rw- 1 root root 195, 255 Oct 24 18:50 nvidiactl
I tried executing the code with sudo
CUDA 5.0 installs driver and libraries at the same time
PS here is lspci | grep -i nvidia:
foo#bar-serv2:/dev$ lspci | grep -i nvidia
03:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 670] (rev a1)
03:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1)
04:00.0 VGA compatible controller: NVIDIA Corporation G94 [Quadro FX 1800] (rev a1)
[update]
foo#bar-serv2:~/NVIDIA_CUDA-5.0_Samples/bin/linux/release$ nvidia-smi -a
NVIDIA: API mismatch: the NVIDIA kernel module has version 295.59,
but this NVIDIA driver component has version 304.54. Please make
sure that the kernel module and all NVIDIA driver components
have the same version.
Failed to initialize NVML: Unknown Error
How could that be, if I use the CUDA 5.0 installer to install driver and libs at the same time. Could the old 4.2 version, that is still lying around mess things up?
I came across this issue, and running
nvidia-smi
informed me of an API mismatch. The problem was that my Linux distro had installed updates that required a system restart, so restarting resolved the issue.
See this stack overflow question Installing cuda 5 samples in Ubuntu 12.10.
Ubuntu 12 is not a supported Linux distro (yet). For reference see CUDA 5.0 Toolkit Release Notes And Errata
** Distributions Currently Supported
Distribution 32 64 Kernel GCC GLIBC
----------------- -- -- --------------------- ---------- -------------
Fedora 16 X X 3.1.0-7.fc16 4.6.2 2.14.90
ICC Compiler 12.1 X
OpenSUSE 12.1 X 3.1.0-1.2-desktop 4.6.2 2.14.1
Red Hat RHEL 6.x X 2.6.32-131.0.15.el6 4.4.5 2.12
Red Hat RHEL 5.5+ X 2.6.18-238.el5 4.1.2 2.5
SUSE SLES 11 SP2 X 3.0.13-0.27-pae 4.3.4 2.11.3
SUSE SLES 11.1 X X 2.6.32.12-0.7-pae 4.3.4 2.11.1
Ubuntu 11.10 X X 3.0.0-19-generic-pae 4.6.1 2.13
Ubuntu 10.04 X X 2.6.35-23-generic 4.4.5 2.12.1
If you want to do it run on Ubuntu 12 anyway then see answer of rpardo. It looks like this distro instead of installing 64 bit libraries to /usr/lib64 installs them to /usr/lib/x86_64-linux-gnu/
I'd suggest searching for all instances of libcuda.so and libnvidia-ml.so on the system. Since the driver doesn't support this distro it might have installed libraries to a path that is not pointed by LD_LIBRARY_PATH. Then move the libraries around and/or change the LD_LIBRARY_PATH to point to this location (it should be the first path on the left). Then retry nvidia-smi or deviceQuery
Good luck
I got error 38 for cudaGetDeviceCount on a windows machine with GTX980 GPU.
After I downloaded the latest driver for GTX 980 fro the NVIDIA site, installed it and restarted, everything is fine. Looks like the CUDA installer is not installing the latest driver.
Try running the sample using sudo (or, you might do a 'sudo su', set LD_LIBRARY_PATH to the path of cuda libraries and run the sample while being root). Apparently, since you've probably installed CUDA 5.0 using sudo, the samples doesn't run with normal user. However, if you run a sample with root, then you'll be able to run samples with the regular user too! I've not yet restarted the system to see if samples work with normal user even after reboot, or each time you should run at least one CUDA application with root.
The problem might completely disappear if you install CUDA TookKit without using sudo.
I had very similar problem on Debian and it turns out that loaded nvidia module had different version than libcuda1.
To check for installed nvidia module you should do:
$ sudo modinfo nvidia-current | grep version
version: 319.82
If it doesn't match version of libcuda1 this the root of your problems.