I try to use X = Mmap.mmap(io, Vector{Float64}, (10^9,)) , but does not finish creating the array, the computer crashes, then i need restart the computer, although X = Mmap.mmap(io, Vector{Float64}, (10^8,)) finish creating the array without any problem. Is there any way to fix this?
I used a text file to store the array.
I use Julia 0.5.0
processor: INTEL: Intel(R) Core(TM) i7-3630QM CPU # 2.40GHz, 6037 MB
GPU: NVIDIA : GeForce GT 630M, 2048 MB
OS: Windows10, x64
Related
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 am trying to run r script on a GPU server provided by the institute.
Specifications of GPU server are as follows:
Host Name: gpu01.cc.iitk.ac.in,
Configuration: Four Tesla T10 GPUs added to each machine with 8 cores in each
Operating System: Linux
Specific Usage: Parallel Programming under Linux using CUDA with C Language
R code:
setwd("~/Documents/tm dataset")
library(ssh)
session <- ssh_connect("dgaurav#gpu01.cc.iitk.ac.in")
print(session)
out <- ssh_exec_wait(session, command = 'articles1_test.R')
Error:
ksh: articles1_test.R: not found
Your dataset and script are only on local machine... you nneed to cooy the to remote server before you can run them.
Trying to understand following error in a pmap execution of some embarrassingly parallel tasks. Running on Linux server. might be occurring while writing to HDF (part of parallel call), but I don't think so given stacktrace doesn't point to line in the user-function being executed, and reference to TCP suggests it's part of parallel calls. Has happened in several sequential runs, so not one-time fluke.
Worker 139 terminated.
ERROR (unhandled task failure): EOFError: read end of file
Stacktrace:
[1] unsafe_read(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Ptr{UInt8}, ::UInt64) at ./iobuffer.jl:105
[2] unsafe_read(::TCPSocket, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:752
[3] unsafe_read(::TCPSocket, ::Base.RefValue{NTuple{4,Int64}}, ::Int64) at ./io.jl:361
[4] read at ./io.jl:363 [inlined]
[5] deserialize_hdr_raw at ./distributed/messages.jl:170 [inlined]
[6] message_handler_loop(::TCPSocket, ::TCPSocket, ::Bool) at ./distributed/process_messages.jl:157
[7] process_tcp_streams(::TCPSocket, ::TCPSocket, ::Bool) at ./distributed/process_messages.jl:118
[8] (::Base.Distributed.##99#100{TCPSocket,TCPSocket,Bool})() at ./event.jl:73
Julia info:
julia> versioninfo()
Julia Version 0.6.0
Commit 9036443 (2017-06-19 13:05 UTC)
Platform Info:
OS: Linux (x86_64-pc-linux-gnu)
CPU: Intel(R) Xeon(R) CPU E5620 # 2.40GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.9.1 (ORCJIT, westmere)
[EDIT: more info] Also, if it's helpful, this appears to be happening well into the run -- output from the first set of parallel runs looks like it's being saved to disk, so this is not an immediate crash, but something that's happening at the end of a run or start of the second set of executions.
OK, so I did finally figure out at a high level what this means:
This is the error you get when one of the parallelized workers hits an error. The specific error language (EOFError: read end of file) doesn't really mean anything. And the references to read and io in the stackoverflow just relate to messaging between the overview task and workers.
In my case, the error was a memory overflow leading to the task manager terminating the worker.
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.
Do you know if there is a UNIX command that will tell me what the CPU configuration for my Sun OS UNIX machine is? I am also trying to determine the memory configuration. Is there a UNIX command that will tell me that?
There is no standard Unix command, AFAIK. I haven't used Sun OS, but on Linux, you can use this:
cat /proc/cpuinfo
Sorry that it is Linux, not Sun OS. There is probably something similar though for Sun OS.
The nproc command shows the number of processing units available:
$ nproc
Sample outputs: 4
lscpu gathers CPU architecture information form /proc/cpuinfon in human-read-able format:
$ lscpu
Sample outputs:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 4
CPU socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 15
Stepping: 7
CPU MHz: 1866.669
BogoMIPS: 3732.83
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
NUMA node0 CPU(s): 0-7
Try psrinfo to find the processor type and the number of physical processors installed on the system.
Firstly, it probably depends which version of Solaris you're running, but also what hardware you have.
On SPARC at least, you have psrinfo to show you processor information, which run on its own will show you the number of CPUs the machine sees. psrinfo -p shows you the number of physical processors installed. From that you can deduce the number of threads/cores per physical processors.
prtdiag will display a fair bit of info about the hardware in your machine. It looks like on a V240 you do get memory channel info from prtdiag, but you don't on a T2000. I guess that's an architecture issue between UltraSPARC IIIi and UltraSPARC T1.
I think you can use prtdiag or prtconf on many UNIXs
My favorite is to look at the boot messages. If it's been recently booted try running /etc/dmesg. Otherwise find the boot messages, logged in /var/adm or some place in /var.