To checkout source code for msm Hammerhead android kernel, I followed the following steps.
[1] Downloaded msm kernel source for android.
$ git clone https://android.googlesource.com/kernel/msm.git
[2] Checked commit message for Hammerhead kernel in my AOSP.
commit 8b392a30f1228e890fa0f7b39598f3b1c73cea94
Author: The Android Open Source Project
Date: Thu Dec 5 15:38:00 2013 -0800
Snapshot to fc777b6d3b2b20ba7270059dd2df284c94844abf
Change-Id: I81ee5ccb10876cbc1413442a7bc256e888c0fcdd
[3] In msm directory where i downloaded source code in [1],
git checkout fc777b6d3b2b20ba7270059dd2df284c94844abf
I get the following error
fatal: reference is not a tree: fc777b6d3b2b20ba7270059dd2df284c94844abf
How can i get the correct SHA1 for msm kernel corresponding to kernel binaries ?
Finally found the solution.
Google changed the way they are adding new kernel binaries to AOSP code.
Instead of using SHA1 as commit message, they are using snapshot id.
Below are the steps to checkout the correct version of msm code.
[1] Run the following command on your existing kernel binary found in device/lge/hammerhead-kernel.
bzgrep -a 'Linux version' vmlinux.bz2
[2] This will give you the following output. May be a different SHA1 in your case.
Linux version 3.4.0-gadb2201 (android-build#vpbs1.mtv.corp.google.com) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed Nov 20 14:42:53 PST 2013
Linux version CIFS VFS Client for Linux<7>%s: sess setup type %d
[3] The required SHA1 ID is adb2201. Note: skip the letter 'g'.
[4] Now checkout with this SHA1 in your msm directory.
git checkout adb2201
Now you are on the same branch in kernel source as the kernel binary in AOSP code.
Related
I'm new to Redhat OpenShift and trying to deploy node application (with angularjs + mysql) and running into build issues.
Using openshift console created node application and in advanced options pointed to the private repository and linked configured secret (ssh key to private repository).
My build is failing with "Assemble script failed". Pasting the logs as below (from console - obfuscated private keys and values).
Not sure if I'm missing some configurations. Appreciate help on this.
Cloning "ssh://username#bitbucket.org/username/my-app.git" ...
Commit: xxxxxxxxxxxxxxxxx (Fixed readme)
Author: Name <email>
Date: Wed Sep 6 19:50:59 2017 -0700
Pulling image "docker-
registry.default.svc:5000/openshift/nodejs#sha256:0000000000000" ...
---> Installing application source
---> Building your Node application from source
Current git config
url.https://github.com.insteadof=git#github.com:
url.https://.insteadof=ssh://
url.https://github.com.insteadof=ssh://git#github.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=ssh://username#bitbucket.org/username/my-app.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master
---> Installing dependencies
---> Using 'npm install -s --only=production'
error: build error: non-zero (13) exit code from docker-
registry.default.svc:5000/openshift/nodejs#sha256:0000000000000
Pls note that my source code is hosted on private repository and per log above it appears openshift is able to access the repository and download the source code.
Thanks Graham for the pointer. I recreated the application and this time in advanced options on the web console selected 1 GB (from default of 500 mb) after which my build worked fine.
I am trying to build a custom platform using the provided example (NodePlatform_Ubuntu) at
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/custom-platforms.html#custom-platforms-pda
I installed EB CLI (my OS is MacOSX El Captain):
➜ custom-platform ebp --version
EB CLI 3.10.1 (Python 2.7.1)
For some reason, EB CLI insists on using Python 2.7.1 instead of the already installed Python 3.x (python3 command works), but this shouldn't matter according to http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-install.html it supports Python 2.7
While "ebp init" works perfectly. the "ebp create" fails.
➜ custom-platform ebp create
Creating application version archive "app-170427_145319".
Uploading custom-platform/app-170427_145319.zip to S3. This may take a while.
Upload Complete.
Note: An environment called 'eb-custom-platform-builder-packer' has been created in order to build your application. This environment will not automatically be terminated and it does have a cost associated with it. Once your platform creation has completed you can terminate this builder environment using the command 'eb terminate'.
INFO: createPlatform is starting.
INFO: Initiated platform version creation for 'custom-platform/1.0.2'.
INFO: Creating Packer builder environment 'eb-custom-platform-builder-packer'.
ERROR: Packer environment eb-custom-platform-builder-packer is not available, current status: terminated.
INFO: Failed to create platform version 'custom-platform/1.0.2'.
This is the error:
ERROR: Packer environment eb-custom-platform-builder-packer is not available, current status: terminated.
More logs (debug mode):
2017-04-27 14:19:55,698 (DEBUG) ebcli.lib.aws : Response: {u'Events': [{u'PlatformArn': 'arn:aws:elasticbeanstalk:us-west-2:107875334514:platform/custom-platform/1.0.1', u'Message': "Failed to create platform version 'custom-platform/1.0.1'.", u'Severity': 'INFO', u'EventDate': datetime.datetime(2017, 4, 27, 11, 19, 52, 84000, tzinfo=tzutc()), u'RequestId': 'f762956d-2b3a-11e7-8cd7-c96ae1e26915'}, {u'PlatformArn': 'arn:aws:elasticbeanstalk:us-west-2:107875334514:platform/custom-platform/1.0.1', u'Message': 'Packer environment eb-custom-platform-builder-packer is not available, current status: terminated.', u'Severity': 'ERROR', u'EventDate': datetime.datetime(2017, 4, 27, 11, 19, 51, 861000, tzinfo=tzutc()), u'RequestId': 'f762956d-2b3a-11e7-8cd7-c96ae1e26915'}], 'ResponseMetadata': {'date': 'Thu, 27 Apr 2017 11:19:52 GMT', 'RetryAttempts': 0, 'HTTPStatusCode': 200, 'RequestId': '6f7dcea9-2b3b-11e7-8cd7-c96ae1e26915'}}
ERROR: Packer environment eb-custom-platform-builder-packer is not available, current status: terminated.
INFO: Failed to create platform version 'custom-platform/1.0.1'.
Note that the app-170427_145319.zip is successfully uploaded to S3.
Any idea what's wrong?
It is was failing with instance profile(role) aws-elasticbeanstalk-custom-platform-ec2-role not getting necessary role inline policy attached to it.
Because of lot of modifications and changes, apparently due to an EB CLI bug, the instance profile got corrupted and was not taking InstanceProfile ARN when tried to create a profile with same name "aws-elasticbeanstalk-custom-platform-ec2-role".
So, we went ahead and created a new one named "custom-platform" and attached necessary inline policy permissions I have mentioned in the case.
Once that IAM issues are sorted, we went onto packer bundle,did "ebp init" and then ran "ebp create" but with -ip flag and used this instance profile custom-platform, as in
ebp create -ip custom-platform
I compiled ejabberd 15.07 (make install, using a prefix for destination).
I am under Linux Mint 16 (based on Ubuntu 13.10) with the distro's erlang package (version R16B01).
I also tested on Ubuntu 12.04 using Erlang OTP 18.0 (erlang compiled myself and ejabberd compiled using --with-erlang, distro's packages are not installed).
ejabberd works perfectly fine in both environments except that the erlang.log file is not created, basically no erlang SASL logs at all.
I upgraded from distro's ejabberd v2.1.10 where that file used to contain a bunch of supervisor logs or component crash/restarts.
Looking at ejabberdctl script, it actually does set the sasl_error_logger file like it always did in the past (e.g. in versions 2.x).
If I do
gperrot#tristan ~/apps/ejabberd/sbin $ su -c 'erl -sasl sasl_error_logger \{file,\"/home/gperrot/apps/ejabberd/var/log/ejabberd/erlang.log\"\}'
Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false]
Eshell V5.10.2 (abort with ^G)
1> application:start(sasl).
ok
I can get a erlang.log file created with some content.
I used bash -x ejabberdctl start to check the command it uses:
sh -c '/usr/bin/erl -sname ejabberd#localhost -noinput -detached -pa /home/gperrot/apps/ejabberd/lib/ejabberd/ebin -mnesia dir "\"/home/gperrot/apps/ejabberd/var/lib/ejabberd\"" -ejabberd log_rate_limit 100 log_rotate_size 10485760 log_rotate_count 1 log_rotate_date '\''""'\'' -s ejabberd -sasl sasl_error_logger \{file,\"/home/gperrot/apps/ejabberd/var/log/ejabberd/erlang.log\"\} +K true -smp auto +P 250000 start ""'
File path is set properly, same user running, same file permissions.
I don't understand why I get no erlang.log file managed by ejabberd.
SASL is correctly started:
gperrot#tristan ~/apps/ejabberd/sbin $ ejabberdctl debug
(ejabberd#localhost)1> application:start(sasl).
{error,{already_started,sasl}}
And in ejabberd.log I also get
2015-09-04 17:29:51.252 [info] <0.7.0> Application sasl started on node ejabberd#localhost
But not erlang.log file.
Any idea why?
Recently a colleague needed to use NVML to query device information, so I downloaded the Tesla development kit 3.304.5 and copied the file nvml.h to /usr/include. To test, I compiled the example code in tdk_3.304.5/nvml/example and it worked fine.
Over a weekend, something changed in the system (I cannot determine what was changed and I am not the only one with access to the machine) and now any code that uses nvml.h, such as the example code, fails with the following error:
Failed to initialize NVML:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
WARNING:
You should always run with libnvidia-ml.so that is installed with your NVIDIA Display Driver. By default it's installed in /usr/lib and /usr/lib64. libnvidia-ml.so in TDK package is a stub library that is attached only for build purposes (e.g. machine that you build your application doesn't have to have Display Driver installed).
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
However, I can still run nvidia-smi and read information about my K20m's state, and as far as I am aware nvidia-smi is just a set of calls to nvml.h. The error message I receive is somewhat cryptic, but I believe it is telling me that the nvidia-ml.so file needs to match the Tesla driver that I have installed on my system. Just to ensure everything is correct, I re-downloaded CUDA 5.0 and installed the driver, CUDA runtime, and the test files. I am certain that the nvidia-ml.so file matches the driver (both are 304.54) so I am quite confused as to what could be going wrong. I can compile and run the test code with nvcc as well as run my own CUDA code, as long as it doesn't include nvml.h.
Has anyone encountered this error or have any thoughts on rectifying the issue?
$ ls -la /usr/lib/libnvidia-ml*
lrwxrwxrwx. 1 root root 17 Jul 19 10:08 /usr/lib/libnvidia-ml.so -> libnvidia-ml.so.1
lrwxrwxrwx. 1 root root 22 Jul 19 10:08 /usr/lib/libnvidia-ml.so.1 -> libnvidia-ml.so.304.54
-rwxr-xr-x. 1 root root 391872 Jul 19 10:08 /usr/lib/libnvidia-ml.so.304.54
$ ls -la /usr/lib64/libnvidia-ml*
lrwxrwxrwx. 1 root root 17 Jul 19 10:08 /usr/lib64/libnvidia-ml.so -> libnvidia-ml.so.1
lrwxrwxrwx. 1 root root 22 Jul 19 10:08 /usr/lib64/libnvidia-ml.so.1 -> libnvidia-ml.so.304.54
-rwxr-xr-x. 1 root root 394792 Jul 19 10:08 /usr/lib64/libnvidia-ml.so.304.54
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 304.54 Sat Sep 29 00:05:49 PDT 2012
GCC version: gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2012 NVIDIA Corporation
Built on Fri_Sep_21_17:28:58_PDT_2012
Cuda compilation tools, release 5.0, V0.2.1221
$ whereis nvml.h
nvml: /usr/include/nvml.h
$ ldd example
linux-vdso.so.1 => (0x00007fff2da66000)
libnvidia-ml.so.1 => /usr/lib64/libnvidia-ml.so.1 (0x00007f33ff6db000)
libc.so.6 => /lib64/libc.so.6 (0x000000300e400000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000300ec00000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000300e800000)
/lib64/ld-linux-x86-64.so.2 (0x000000300e000000)
EDIT: The solution was to remove all extra instances of libnvidia-ml.so. For some reason there were a LOT of them.
$ sudo find / -name 'libnvidia-ml*'
/usr/lib/libnvidia-ml.so.304.54
/usr/lib/libnvidia-ml.so
/usr/lib/libnvidia-ml.so.1
/usr/opt/lib/libnvidia-ml.so
/usr/opt/lib/libnvidia-ml.so.1
/usr/opt/lib64/libnvidia-ml.so
/usr/opt/lib64/libnvidia-ml.so.1
/usr/opt/nvml/lib/libnvidia-ml.so
/usr/opt/nvml/lib/libnvidia-ml.so.1
/usr/opt/nvml/lib64/libnvidia-ml.so
/usr/opt/nvml/lib64/libnvidia-ml.so.1
/usr/lib64/libnvidia-ml.so.304.54
/usr/lib64/libnvidia-ml.so
/usr/lib64/libnvidia-ml.so.1
/lib/libnvidia-ml.so.old
/lib/libnvidia-ml.so.1
You are getting this error because the application that is trying to use nvml is loading the stub library that is located in:
...tdk_install_path/lib64/libnvidia-ml.so
instead of the one in:
/usr/lib64/libnvidia-ml.so
I was able to reproduce your error when I added the stub library path to my LD_LIBRARY_PATH environment variable. So that is one possible source of error, if someone added the path of the stub library that comes with the tdk distribution to your LD_LIBRARY_PATH environment variable, but probably not the only way this could happen. If someone in an unusual fashion copied the stub library to some system path, that might also be an issue.
You'll need to try and figure out why your system is loading that stub library in place of the correct one in /usr/lib64. Alternatively, for discovery purposes, you could try deleting all instances of the stub library anywhere on your system (leave the correct libraries in /usr/lib and /usr/lib64 alone), and you should be able to observe correct behavior.
I solved the problem this way on a GTX 1070 using windows 10 : go to device manager, select the GPU that is having a problem, disable the GPU and enable back.
I was having this same or similar issue with EWBF Cuda Miner for zCash.
Here is a way to automatically implement Pro7ech's answer (which worked for me) for WIN10:
Install WDK for Windows 10 if you don't already have it: This will give you the ability to use devcon.exe which allows manipulation of devices via batch scripts:
https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk
You might also need the Windows SDK if you don't have visual studio with Desktop development with C++ workload:
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
To make things easier, you might want to add the installation path to your PATH environment variable:
https://www.howtogeek.com/118594/how-to-edit-your-system-path-for-easy-command-line-access/
Devcon.exe was installed here for me:
C:\Program Files (x86)\Windows Kits\10\Tools\x64
So now run this or similar in a cmd.exe prompt to get the device id:
devcon findall * | find /i "nvidia"
Here is what mine looks like:
C:\Users\Soenhay>devcon findall * | find /i "nvidia"
HDAUDIO\FUNC_01&VEN_10DE&DEV_0083&SUBSYS_38426674&REV_1001\5&1C277AD4&0&0001: NVIDIA High Definition Audio
SWD\MMDEVAPI\{0.0.0.00000000}.{574980C3-9747-42EF-A78C-4C304E070B81}: SAMSUNG (NVIDIA High Definition Audio)
ROOT\UNNAMED_DEVICE\0000 : NVIDIA Virtual Audio Device (Wave Extensible) (WDM)
PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000: NVIDIA GeForce GTX 1070
From that I see that my graphics device id is:
PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000
So I create a batch file with the following to disable and re-enable the driver:
devcon disable "#PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000"
devcon enable "#PCI\VEN_10DE&DEV_1B81&SUBSYS_66743842&REV_A1\4&1F1337ch33s3&0&0000"
Now, when I get the NVML error when starting the miner I just run this batch file and it fixes it. You could also just add those 2 lines to the beginning of your start.bat file to do this every time but I found that the error does not always happen every time I restart the miner time now.
References:
superuser post
devcon commands
devcon examples
No matching devices found.
NOTE:
The command should have the # symbol at the beginning of the device id.
The batch script should be run as administrator.
I have faced the same error.
Found a solutions is to run command:
nvidia-uninstall
Google shows a couple of hits for this issue, but never a solution that I can find. It's always just a few other people saying "it works for me", and the issue dries up. I've tested both with the "-incremental=true" flag to mxmlc and with the <incremental>true</incremental> tag in my flex config.xml with the same result:
Failed to match the compile target with /export/vampire/build/Editor.swf.cache. The cache file will not be reused.
I get this on each compile after the first that creates the cache, whether the source files were modified or not.
I've checked file permissions (not expecting anything - the cache file and the swf it's checking against were both created by MXMLC to begin with):
-rw-rw-r-- 1 nathan nathan 3181508 2009-07-15 17:50 Editor.swf
-rw-rw-r-- 1 nathan nathan 5756512 2009-07-15 17:50 Editor.swf.cache
$ flex_sdk/bin/mxmlc -version
Version 3.3.0 build 4852
$ uname -a
Linux sargasso 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux
Ubuntu 8.04
It looks like the "Failed to match compile target" error is being caused by an updated timestamp on the flex config file. Even if the config file is unmodified, mxmlc will throw out the old compile cache and recompile everything as long as the timestamp is newer than that on the cache file. This misleading error message is all the info you get.