As much I know that mcelog is used to check the memory errors in the hardware. I want to simulate the same case. I don't have any machine which is having the issue with hardware where I can simulate this case. Can anybody suggest me some simulator or any other way through which I can generate these errors. Because my main aim is to display the Uncorrectable Memory errors. Thanks.
You can use the tool mce-inject, but you'll need to load the mce_inject kernel module. This kernel module is available on Ubuntu 12.04 (the only system I have access to) and should be available on newer Ubuntus, as well.
First, you need to load the module:
$ sudo modprobe mce_inject
Next, you need to download the source for the mce_inject tool, install the dependencies, and compile it:
$ git clone https://github.com/andikleen/mce-inject.git
$ sudo apt-get install flex bison
$ cd mce-inject
$ make
Next, you need to create a file that simulates the error you want. You should check the mce-inject man page (included in the source) for more information on the structure. You can find some examples in the test/ directory in the [mce-inject source](
Injecting a FATAL error can destabilize and crash the system; doing this is not recommended.
Once you've decided which example file to use (or have created your own) you can inject it with mce-inject. For example, injecting the test/corrected example error included with mce-inject:
$ sudo ./mce-inject test/corrected
You can now check your logs and find that the error has been injected.
Related
Currently I'm experimenting with the Cell/BE CPU under Linux. What I'm trying to do is running simulations in the near future, e.g. about the weather or black holes.
Problem is, Linux only discovers the main CPU of the Cell (the PPE), all other SPUs (7 should be available to Linux) are "sleeping". They just don't work out of the box.
What works is the PPE and it's recognized as a two-threaded CPU with one core by the OS. Also, the SPEs are shown at every boot (with small penguins showing a red "PPE" in them), but afterwards are shown nowhere.
Is it possible to "free" these specialised cores for use by the Linux OS? If so, how?
As noone seems to be interested or can answer this question I'll provide the details myself.
In fact there exists a workaround:
First, create an entry point for the SPUFS:
# sudo mkdir /spu
Create a mount point for the filesystem so you won’t have to manually mount after a reboot. Add this line to /etc/fstab
spufs /spu spufs defaults 0 0
Now reboot and test to make sure the SPUFS is mounted (in a terminal):
spu-top
You should see the 7 SPEs running with 0% load average.
Now Google for the following package to get the runtime library and headers you need for SPE development:
libspe2-2.3.0.135.tar.gz
You should find it on the first hit. Just unpack, build, and install it:
./configure
make
sudo make install
You can ignore the build warnings (or fix them if you have obsessive compulsive disorder).
You can use pkg-config to find the location of the runtime and headers though they are in /usr/local if I recall.
You of course need the gcc-spe compiler and the rest of the PPU and SPU toolchains but those you can install with apt-get as they are in the repos.
Source: comment by Exillis via redribbongnulinux.000webhostapp.com
I used a library (the library is called cublas) in my CUDA code which I 'm writing in linux, I can compile my code successfully using nvcc but when I run the code I get this error:
error while loading shared libraries: libcublas.so.7.5: cannot open shared object file: No such file or directory
I found This link as a solution which suggests to run some commands in order to solve the issue. one solution based on this link is running the following command:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib
The system which gpu locates in it and I am using to run my code on it is shared between me and other people, I am not a sudo user in that system. I am wondering if running this command is safe and does not affect other settings of the system
Can anyone please help me to know that>
Thank you so much
I am wondering if running this command is safe and does not affect other settings of the system
Yes, you'll be fine.
This command:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib
only affects the process you execute it in.
It will not affect any other user's process, or any other process of yours.
Furthermore, if you log out and log in again, you will have to execute that command again. It is not "sticky"
I'm trying to compile geany-plugins-1.28. The debugger plugin (the only one I need) gives the error:
debug.c:53:21: fatal error: vte/vte.h: No such file or directory
#include <vte/vte.h>
Clearly it needs to know where this file is located to compile. I found the vte.h file in the src directory of the main program geany-1.28. When running
sudo ./configure cflags=-I/home/pi/Desktop/geany-1.28/src
I get the same error about the missing header later trying to compile the debugger plugin.
I ran
./configure --help
to get all the flag options. The output is here
How do I get this to configure correctly so that it compiles. I need to compile the debugger version 1.28 myself because apt only installs 1.24 which I think has a bug because it crashes when I run my code with the error:
close failed in file object destructor:
sys.execpthook is missing
lost sys.stderr
CFLAGS is case-sensitive environment variable, so you should set it before running configure, not try to pass it as a command line argument. This variant:
$ export CFLAGS=-I/home/pi/Desktop/geany-1.28/src
$ ./configure
leaves CFLAGS set for current shell until you leave it. While this:
$ CFLAGS=-I/home/pi/Desktop/geany-1.28/src ./configure
sets variable only for current command, i.e. configure.
Some other issues:
You do not need sudo to configure and make. It is also unnecessary for make install if you set PREFIX to a path you have privileges to write to.
Does plugin's build system also builds all it's dependencies? If not, you may face linker errors a bit later.
Update:
I have tried to build debugger plugin and got rid of your error. It seems that vte.h coming with Geany is it's intrinsic, while the plugin requires full-featured file from the library. So I just installed vte and vte-devel from repos. Nevertheless, I got some other unrelated errors coming from Glib. I will not continue my attempts to build all this right now. Hope my effort will be helpful at least a little.
As in this answer stated, vte.h is not the file you are looking for. Install libvte(-dev) package on your system and rerun configure.
Just for the record: vte.h on Geany is a dummy to allow Geany to kind of dynamical enable vte or disable it depending on vte is installed on the system or not.
I installed Rmpi on my linux machine and it successfully loads in R. There are two versions of MPICH on my machine, and I (believe) have installed Rmpi with the latest version. I also had to update my LD_LIBRARY_PATH. I primarily followed the installation instructions here.
After loading Rmpi in R, I run mpi.spawn.Rslaves(nslaves=4) and get the following error message:
Error in mpi.spawn.Rslaves(nslaves = 2) :
You cannot use MPI_Comm_spawn API
Does anyone know how I can get Rmpi working?
Thanks!
You need to use MPICH2 for spawn support. If you have MPICH2 installed, you may still need to specify --with-Rmpi-type=MPICH2 when installing Rmpi. If you used --with-Rmpi-type=MPICH instead, it would disable functions such as mpi.spawn.Rslaves.
Also note that MPICH2 apparently does not support spawning workers unless the program is launched using a command such as mpiexec. This basically means that you can't execute mpi.spawn.Rslaves from an interactive R session using MPICH2, although this is possible using Open MPI. To be clear, this is not the issue that you're reporting, but you may encounter this after you have correctly installed Rmpi using MPICH2.
I was able to install Rmpi 0.6-5 using MPICH 3.1.3 with the command:
$ R CMD INSTALL Rmpi_0.6-5.tar.gz --configure-args='--with-mpi=$HOME/mpich-install --with-Rmpi-type=MPICH2'
To debug a configuration problem, you should install Rmpi from a directory rather than a tar file. That will allow you to examine the "config.log" file afterwards which will provide important information. Here is how I did that on my Linux box:
$ tar xzvf Rmpi_0.6-5.tar.gz
$ R CMD INSTALL Rmpi --configure-args='--with-mpi=$HOME/mpich-install --with-Rmpi-type=MPICH2'
In order to get spawn support, the MPI2 macro needs to be defined when compiling the C code in Rmpi. You can check if that is happening by searching for "PKG_CPPFLAGS" in config.log:
$ grep PKG_CPPFLAGS Rmpi/config.log
PKG_CPPFLAGS='-I/home/steve/mpich-install/include -DMPI2 -DMPICH2'
I have found "config.log" to be very useful for debugging configuration and build problems.
Note that you can use Rmpi without spawn support. You'll need to start all of the workers using mpirun (or mpiexec, etc) and it will be much more difficult, if not impossible, to use functions such as mpi.apply, mpi.applyLB, etc. But if you just need to initialize MPI so you can use MPI from functions implemented in C or Fortran, you will probably need to start all of the workers via mpirun.
I'm trying to modify GTK2 on Ubuntu Oneiric.
I download the source:
apt-get source libgtk2.0-0
cd gtk+2.0-2.24.6/
I try to compile and overwrite the current GTK2:
./configure --prefix=/usr
sudo make
Soemhow I get an error (I have all the necessary libraries and the build-essential package etc):
In file included from gtkquery.c:26:0:
gtkquery.h:31:2: error: #error "gtkfilechooserprivate.h is not supported API for general use"
By the way, I am able to modify and recompile GTK3 with no problems with the same steps.
If use debuild, I get thousands of
dpkg-source: error: cannot represent change to gtk+2.3.0-2.24.6/gtk+2.0-2.24.6/something: binary file contents changed
You won't get anything near the Ubuntu-provided build if you try building it by hand that way -- you'll miss all the ./configure options and other settings. (Look into debian/rules for the full details of what they're setting.)
Instead, try debian/rules build.
For reasons I haven't investigated yet (possibly including me not understanding how it should work), that didn't work on the first package I tried, but setting up pbuilder let me build the package I wanted.
It might feel like overkill to get a clean chroot as a build environment, but it is way too easy to build yourself problems that no one else in the world can replicate because you've got something funny on your local system.