I can't run use mongodb on my arch linux.
package installed: mongodb-bin
error when use mongo: illegal hardware instruction (core dumped) mongo
My processor: AMD Athlon(tm) II X2 270
From the
release notes:
MongoDB 5.0 requires AMD Bulldozer or later.
How to check:
cat /proc/cpuinfo | grep -i avx
(Advanced Vector Extention(avx) needed for 5.0)
Related
I have setup a kubernetes node with a nvidia tesla k80 and followed this tutorial to try to run a pytorch docker image with nvidia drivers and cuda drivers working.
My nvidia drivers and cuda drivers are all accessible inside my pod at /usr/local:
$> ls /usr/local
bin cuda cuda-10.0 etc games include lib man nvidia sbin share src
And my GPU is also recongnized by my image nvidia/cuda:10.0-runtime-ubuntu18.04:
$> /usr/local/nvidia/bin/nvidia-smi
Fri Nov 8 16:24:35 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 410.79 Driver Version: 410.79 CUDA Version: 10.0 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla K80 Off | 00000000:00:04.0 Off | 0 |
| N/A 73C P8 35W / 149W | 0MiB / 11441MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
But after installing pytorch 1.3.0 i'm not able to make pytorch recognize my cuda installation even with LD_LIBRARY_PATH set to /usr/local/nvidia/lib64:/usr/local/cuda/lib64:
$> python3 -c "import torch; print(torch.cuda.is_available())"
False
$> python3
Python 3.6.8 (default, Oct 7 2019, 12:59:55)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> print ('\t\ttorch.cuda.current_device() =', torch.cuda.current_device())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.6/dist-packages/torch/cuda/__init__.py", line 386, in current_device
_lazy_init()
File "/usr/local/lib/python3.6/dist-packages/torch/cuda/__init__.py", line 192, in _lazy_init
_check_driver()
File "/usr/local/lib/python3.6/dist-packages/torch/cuda/__init__.py", line 111, in _check_driver
of the CUDA driver.""".format(str(torch._C._cuda_getDriverVersion())))
AssertionError:
The NVIDIA driver on your system is too old (found version 10000).
Please update your GPU driver by downloading and installing a new
version from the URL: http://www.nvidia.com/Download/index.aspx
Alternatively, go to: https://pytorch.org to install
a PyTorch version that has been compiled with your version
of the CUDA driver.
The error above is strange because my cuda version for my image is 10.0 and Google GKE mentions that:
The latest supported CUDA version is 10.0
Also, it's GKE's daemonsets that automatically installs NVIDIA drivers
After adding GPU nodes to your cluster, you need to install NVIDIA's device drivers to the nodes.
Google provides a DaemonSet that automatically installs the drivers for you.
Refer to the section below for installation instructions for Container-Optimized OS (COS) and Ubuntu nodes.
To deploy the installation DaemonSet, run the following command:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml
I have tried everything i could think of, without success...
I have resolved my problem by downgrading my pytorch version by buildling my docker images from pytorch/pytorch:1.2-cuda10.0-cudnn7-devel.
I still don't really know why before it was not working as it should otherwise then by guessing that pytorch 1.3.0 is not compatible with cuda 10.0.
I am heaving a strange problem under gentoo. Mongodb extension is working fine in apache2 and cli, but fpm fails to start:
/etc/init.d/php-fpm restart
* Testing PHP FastCGI Process Manager configuration ...
[30-Jan-2016 13:59:47] NOTICE: configuration file /etc/php/fpm-php7.0/php-fpm.conf test is successful
zend_mm_heap corrupted [ !! ]
php -v
PHP 7.0.2-pl5-gentoo (cli) (built: Jan 30 2016 13:16:21) ( ZTS )
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2015 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
Here is the info from cli:
php -i|grep mongo
mongodb
mongodb support => enabled
mongodb version => 1.1.3-dev
mongodb stability => devel
libmongoc version => 1.3.1-dev
mongodb.debug => no value => no value
I even compiled mongodb without sasl but the result is the same.
Mongodb extension was manually compiled like this(my system is x86_64):
git clone https://github.com/mongodb/mongo-php-driver.git
cd mongo-php-driver; git submodule sync && git submodule update --init
Run phpize:
phpize --clean
phpize
Remove the aclocal.m4 file:
rm aclocal.m4
Run aclocal and autoconf:
aclocal
autoconf
Now configure, make and install the package:
./configure --without-mongodb_sasl (i tried with and without this)
make
make install
add extension=mongodb.so in php.ini: /etc/php/fpm-php7.0/php.ini
restart php-fpm: /etc/init.d/php-fpm restart
The strangest thing is that if i start php-fpm process with gdb to backtrace the extensions works.
gdb -q /usr/lib/php7.0/bin/php-fpm
Reading symbols from /usr/lib/php7.0/bin/php-fpm...(no debugging symbols found)...done.
(gdb) set args --pid /run/php-fpm.pid --fpm-config /etc/php/fpm-php7.0/php-fpm.conf -c /etc/php/fpm-php7.0/
(gdb) run
Starting program: /usr/lib64/php7.0/bin/php-fpm --pid /run/php-fpm.pid --fpm-config /etc/php/fpm-php7.0/php-fpm.conf -c /etc/php/fpm-php7.0/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Inferior 1 (process 4075) exited normally]
(gdb)
Any help is apreciated
For the sake of the lazy googler, this is fixed in version 1.1.5 of the php-mongodb-driver
I've just installed RASPBIAN 3.18 and next packages:
wget http://mirrordirector.raspbian.org/raspbian/pool/main/b/bluez/bluez_4.99- 2_armhf.deb
wget http://mirrordirector.raspbian.org/raspbian/pool/main/libc/libcap- ng/libcap-ng0_0.6.6-2_armhf.deb
wget http://mirrordirector.raspbian.org/raspbian/pool/main/r/radvd/radvd_1.8.5- 1_armhf.deb
wget -O kernel.zip http://www.nordicsemi.com/eng/nordic/download_resource/41602/5/28710770
unzip kernel.zip
sudo dpkg -i radvd_1.8.5-1_armhf.deb
sudo dpkg -i libcap-ng0_0.6.6-2_armhf.deb
sudo dpkg -i bluez_4.99-2_armhf.deb
sudo dpkg -i linux-image-3.17.4-release+_1_armhf.deb
sudo dpkg -i linux-headers-3.17.4-release+_1_armhf.deb
sudo nano /boot/config.txt
Add the following line:
kernel=vmlinuz-3.17.4-release+ to config.txt
save and exit
sudo reboot
and when I restart I got an screen more or less as the print screen attached. Any idea ?
One thing is sure: The rainbow screen means the GPU firmware is loaded, but there is a problem with the kernel image. Which one? Impossible to say from here. Perhaps not found or corrupt. Might be that the kernel you got from www.nordicsemi.com is broken. Might be you have a typo somewhere. But it can also be a faulty SD-card. Or a wrong power supply. According to Google:
In some cases (Stuck on the Rainbow Screen), freezing at this point has been fixed by adding "boot_delay=1" to the config.txt file.
If nothing helps, you probably have to go back to the default Raspian kernel. If you need a more recent kernel than in the default Raspian, you can switch to Raspian testing. The testing kernel should be a bit more recent... and definitely works for me.
This might also help you (https://www.raspberrypi.org/forums/viewtopic.php?t=58151)
Error ACT LED patterns
While booting the ACT LED should blink in an irregular pattern, indicating it is reading from the card. If it starts blinking in a regular (Morse code like) pattern then it is signaling an error.
When it blinks just once: possibly you have a Rpi from Micron. Take a good look at the processor if it says M with an orbit around it, then using the latest software ( after Sept 2013 ) will solve your problem. Also make sure you have a 4Gb SD card: a 2Gb doesn't work in this particular case.
Other patterns that might appear during a failed boot mean:
3 flashes: start.elf not found
4 flashes: start.elf not launch-able (corrupt)
7 flashes: kernel.img not found
8 flashes: SDRAM not recognized. You need newer bootcode.bin/start.elf firmware, or your SDRAM is damaged
Firmware before 20th October 2012 required loader.bin, and the meaning of the flashes was slightly different:
3 flashes: loader.bin not found
4 flashes: loader.bin not launch-able (corrupt)
5 flashes: start.elf not found
6 flashes: start.elf not launch-able
7 flashes: kernel.img not found
I have used CellSDK in past to emulate/debug and test code for powerpc7 architecture on x86_64 machines. Now i want to emulate test code for upcoming (Google/intel etc) PowerPC8 compiler is available, can someone tell me qemu that can emulate ppc64 on x86_64 so i can test code(scheduler) on it .
The minimum Requirement to emulate ppc kernel on Qemu is qemu binaries kenrel image and rootfs.
For arm its like this
qemu-system-arm -M versatilepb -m 128M -kernel zImage -hda rootfs.ext3 -no-reboot -show-cursor -usb -usbdevice wacom-tablet -no-reboot -serial stdio -m 256 --append "root=/dev/sda rw console=ttyAMA0,115200 console=tty mem=256M highres=off console=ttyS0"
For more details on ppc_64 have a look at
http://gmplib.org/~tege/qemu.html
here 10 and 11
You might want to use IBM SDK other than CellIDE.
https://www-304.ibm.com/webapp/set2/sas/f/lopdiags/sdklop.html
Also, if you are doing open source development, you can try to get a free access to real ppc64 machines. It works pretty well.
http://openpower.ic.unicamp.br/minicloud/
OS: Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Trying to run this command to install meteor:
curl install.meteor.com | /bin/sh
============= Output Error ===============
Installing /tmp/meteor-install-Nv47529/meteor-0.3.6-1.x86_64.rpm
error: Failed dependencies:
libc.so.6(GLIBC_2.6)(64bit) is needed by meteor-0.3.6-1.x86_64
libc.so.6(GLIBC_2.7)(64bit) is needed by meteor-0.3.6-1.x86_64
libc.so.6(GLIBC_2.9)(64bit) is needed by meteor-0.3.6-1.x86_64
libstdc++.so.6(GLIBCXX_3.4.9)(64bit) is needed by meteor-0.3.6-1.x86_64
Installation failed.
============= Output Error ===============
glib is missing showing but check glib using
rpm -qa --qf="%{n}-%{v}-%{r}.%{arch}\n" | grep glibc | sort
showing me
compat-glibc-2.3.4-2.26.i386
compat-glibc-2.3.4-2.26.x86_64
compat-glibc-headers-2.3.4-2.26.x86_64
glibc-2.5-49.el5_5.7.i686
glibc-2.5-49.el5_5.7.x86_64
glibc-common-2.5-49.el5_5.7.x86_64
glibc-devel-2.5-49.el5_5.7.i386
glibc-devel-2.5-49.el5_5.7.x86_64
glibc-headers-2.5-49.el5_5.7.x86_64
glibc-utils-2.5-49.el5_5.7.x86_64
so any idea what is the issue?
GLIBC_2.6 is required by the RPM, you only have GLIBC_2.5 so you need to upgrade.
Alternatively, this dependency may be more strict than it needs to be; try packing Meteor yourself.