I run poclbm on my system but for some reason both deepbit and slush don't "see" the work being performed. My system reports about 200 megabashes per second being done. I tried mining with my cpu using the same settings, and then both deepbit and slush recognized that work was being performed.
These are the errors I am getting out of the respective mining hardware (every minute or so):
poclbm error: pit.deepbit.net:8332 22/02/2013 21:50:59, Verification failed, check hardware! (0:0:Cypress, d47b7ba0)
cgminer error: [2013-02-22 22:18:51] GPU0: invalid nonce - HW error
I am using Ubuntu 12.10 (Quantal Quetzal) with the 12.10 version poclbm with an ATI 5800 series video card. The video drivers are installed and work as far as I can tell. When I run a "aticonfig --odgc --adapter=all", the gpu does seem to be utilized with poclbm (around 70% utilization or so).
I found the solution through an irc channel (Freenode on channcel #cgminer). Basically, at least on the version of Ubuntu that I have (12.10), the 2.8 version of the SDK does NOT work properly with cgminer or poclbm. I was instructed to download the 2.4 version of the SDK. Here:
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.4-lnx32.tgz
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.4-lnx64.tgz
Some distributions require the "2.7" version so I'll put the links here:
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.7-lnx32.tgz
http://developer.amd.com/Downloads/AMD-APP-SDK-v2.7-lnx64.tgz
I compiled it. There is no "make install" for this Makefile, apparently, so you have to manually copy the files to your lib directory:
for 32 bit: $ cp -pv lib/x86/* /usr/lib/
for 64 bit: $ cp -pv lib/x86_64/* /usr/lib/
Also copy the include files: $ rsync -avl include/CL/ /usr/include/CL/
With the libraries installed in the appropriate directories, I recompiled cgminer and then it worked. I also tried it with poclbm and it worked with that too.
Hm, I experienced the same error with pclbm and cgminer. Then I found https://bitcointalk.org/index.php?topic=139406.msg1502120#msg1502120 .. I tried phoenix and all is ok now. Hope it helps. Sry my bad english.
Related
In order to patch RedHat 7 machines to version 7.9, I've created an RPM repository with RPMs extracted from a DVD.iso file of the patch (example source guide), and updated said machines using yum.
The patch has succeeded with many of the machines (RHEL 7.7 only), but the rest (7.0, 7.2 and some 7.7 as well) have failed the with the following error:
Error: requested datatype filelists not available
I've also tried to gradualize the process and patch the 7.0 and 7.2 ones to 7.7 first by the same process, but yielded the same result. I've made sure I got each and every file in the Packages folder.
It is rather puzzling for me that some succeed and some fail, especially those with the same version. But I'm assuming they were created differently as I don't have the information to say otherwise. So my best direction would be to go by the error.
In this github post, lr1980 says:
https://blog.packagecloud.io/eng/2015/07/20/yum-repository-internals/
this means the "filelists.xml.gz" is missing on repo => it's a packager.io problem
Indeed, browsing my repository's repodata folder reveals only other.xml.gz and primary.xml.gz files, which are also the only files pointed to in the repomd.xml.
I've tried uploading the filelists.xml.gz file from the dvd.iso and reindexing, but it gets removed (admittedly am not familiar with this area of knowledge.. at all). What does "it's a packager.io problem" mean?
How can I force the repo to have such a file, assuming that's what I need? Or what can I do to solve this issue otherwise?
Many thanks
I'm having issues getting the ODBC driver for Snowflake to work on an M1 Apple Silicon Mac running Big Sur.
Successfully following the instructions on Snowflake's website gets me to the point where testing the driver from the command line (using iodbctest) using the DSN results in the following error:
1: SQLDriverConnect = [iODBC][Driver Manager]dlopen(/opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib, 6): no suitable image found. Did find:
/opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib: no matching architecture in universal wrapper
/opt/snowfl (0) SQLSTATE=00000
2: SQLDriverConnect = [iODBC][Driver Manager]Specified driver could not be loaded (0) SQLSTATE=IM003
My Snowflake driver is installed to /opt/snowflake/snowflakeodbc, so that is correct -- I'm suspicious that this is specifically an M1 problem. I'm using the 2.24.1 version of the driver available from the download mirror here, and the path to the driver in /etc/odbcinst.ini is /opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib (which exists and seems, from all my research, that it should be right).
When I run a connection via DBI in R, I get a completely different error:
Error: nanodbc/nanodbc.cpp:1021: 00000:
[Snowflake][ODBC] (11560) Unable to locate SQLGetPrivateProfileString function.
In other StackOverflow posts, people have referenced the above error meaning that there is a missing library of some kind (IODBC isn't configured correctly?), but I've tried quite a few things to no avail. Any guidance would be great.
Tinkered with this a bit more and realized it's an artifact of the installation pathways for the .dmgs & the preset paths in simba.snowflake.ini.
You need to point the Snowflake driver towards the iODBC dylib (as per a sideswiping statement in the docs) -- the driver is originally configured to look for the ODBC dylib (not iODBC) in a folder that's on the path.
When you install the iODBC driver, verify that it is installed to /usr/local/iODBC (this was where my Silicon Mac installed it to) -- and that /usr/local/iODBC/lib has libiodbc.dylib in it. If so, navigate to your installed snowflake driver directory (should be /etc/snowflake) and alter the simba.snowflake.ini file (/etc/snowflake/snowflake/snowflakeodbc/universal/simba.snowflake.ini). You want to uncomment & alter the last line to be both uncommented & point with a full path towards the iODBC dylib (instead of the default, which is the ODBC dylib).
# Darwin specific ODBCInstLib
# iODBC
ODBCInstLib=/usr/local/iODBC/lib/libiodbcinst.dylib
Make sure to comment out any other ODBCInstLib line so that only one is configured. That should enable you to get your connection to snowflake up and running on an M1 Mac.
Big Sur is macOS v11.n
Snowflake supports macOS 10.14 and 10.15 Supported OSs
So what you are trying to do is not supported and is unlikely to work
None of the other solutions worked for me but #kiran-kumawat 's answer set me down a path that worked.
It seems like the core of the issue is that the odbc code is looking for arm64 architecture drivers but Snowflake is providing it in x86_64 architecture. By installing an x86_64 versions of odbc we are able to have it successfully talk to the driver.
First I uninstalled R and Rstudio. (it may be possible to sim-link or change things behind the scenes to make this work with existing installs but I am not sure).
Then install rosetta (apples software for translating between architectures) and a version of homebrew built with it. I am leaving my main version of homebrew in place.
softwareupdate --install-rosetta
arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
Then use that version of homebrew to install odbc, R, and Rstudio.
arch -x86_64 /usr/local/Homebrew/bin/brew install unixodbc
arch -x86_64 /usr/local/Homebrew/bin/brew install --cask rstudio
arch -x86_64 /usr/local/Homebrew/bin/brew install --cask r
We then need to install the snowflake driver: https://sfc-repo.snowflakecomputing.com/odbc/mac64/latest/index.html
Click through all the install prompts.
Modify your files
/usr/local/etc/odbcinst.ini:
[Snowflake Driver]
Driver = /opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib
/usr/local/etc/odbc.ini
[Snowflake]
Driver = Snowflake Driver
uid = <uid>
server = <server>
role = <role>
warehouse = <warehouse>
authenticator = externalbrowser
We also need to modify the simba.snowflake.ini file.
It is somewhat locked down so run:
sudo chmod 646 /opt/snowflake/snowflakeodbc/lib/universal/simba.snowflake.ini
Then
vim /opt/snowflake/snowflakeodbc/lib/universal/simba.snowflake.ini
And find the ODBCInstLib line that is uncommented and change it to:
ODBCInstLib=/usr/local/Cellar/unixodbc/2.3.9_1/lib/libodbcinst.dylib
After setting this up I was able to use this connection successfully:
install.packages("DBI")
install.packages("odbc")
con <- DBI::dbConnect(odbc::odbc(), "Snowflake")
one of our team member suggested below steps and it worked for us for Apple M1 series
Install the latest snowflake driver
Uninstall m1 based homebrew using cmd
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall.sh)"
Install intel based homebrew - restart terminal when done
arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
Re-install unixodbc
arch -x86_64 brew install unixodbc
Test
isql -v Pattern
in your database.yml file for connection to snowflake make following change-
replace "dsn: <DSN_NAME>" with following
conn_str: "Driver={PATH};Locale=en-US;uid={USER_NAME};pwd= {PASSWORD};server=<yours>.snowflakecomputing.com;role=<ROLE>;charset=UTF-8;warehouse=<WAREHOUSE>;database=<DATABASE>;schema=<SCHEMA>;"
Has anyone gotten this to work? I use excel w odbc to refresh snowflake files and have tried multiple ways to move the drivers etc and followed snowflake instructions but never works. I did get parallels to work running windows arm but would prefer to just do this in Mac OS
I also have a M1 (version Monterey 12.0) and I ran into similar issues when I tested the driver. Nevertheless, when I tried the "real connection" it worked like a charm. So, maybe it would be good for you to go and test the "real connection" to avoid a wasting of time using such testing. Hope you find this useful.
I am currently using the linux-x86.img which I downloaded from the documentation page for gem5 (http://www.m5sim.org/Download), but since I was not able to compile the fscanf and fopen commands on this image I was wondering if there is a more recent image which I could download and use instead.
The error message throw when trying to compile the lines with fopen and fscanf are
./obj/edgelist.o: In function loadEdgeArray': edgelist.c:(.text+0x148): undefined reference to __isoc99_fscanf'
./obj/edgelist.o: In function loadEdgeArrayInfo': edgelist.c:(.text+0x20c): undefined reference to __isoc99_fscanf'
collect2: ld returned 1 exit status
make: *** [test] Error 1
This error is thrown when trying to compile from both from qemu as well as gem5.
Here's one setup that generates such an image with Buildroot. I'm a fan of Buildroot because it builds everything from source. I don't understand how fscanf and fopen could fail in that image, but I have tested them in the above setup and they work fine.
Boot used to work in the past, but gem5 X86 full system boot has been broken for likely easy to fix reasons for a few months now as of March 2020 on the gem5 side, although there are efforts in place to fix it, and so likely it will work again soon: https://www.gem5.org/project/2020/03/09/boot-tests.html
Other alternatives include:
https://gem5art.readthedocs.io/en/latest/ which Jason has been pushing and uses Packer to generate disk images
You can also extract working disk images from Docker: https://hub.docker.com/_/ubuntu This requires exporting them to a file to give to gem5.
It is also worth noting that when the gem5.org website migrated from the old Wiki to the new static website setup in Q1 2020, we lost the ability of doing directory listing under http://dist.gem5.org/dist/current/arm/ for some reason, and so devs were forced to list them one by one on the static website... https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries
I am not sure why the error is no longer occurring for me, but documenting the steps I went through which might have fixed something. I reinstalled Ubuntu18.04 therefore had to rebuild gem5 and I used the parsec image (http://www.cs.utexas.edu/~parsec_m5/x86root-parsec.img.bz2) referenced in this answer Booting gem5 X86 Ubuntu Full System Simulation
I am tying to work/setup the Systemtap tool for profiling OS procesess, on a Virtual Linux. I am using VirtualBox to run the image. Via
rpm -q kernel
and
cat /proc/version
The version obtained is:
Linux version 2.6.32-5-686 (Debian 2.6.32-48squeeze4)
I have correctly downloaded and installed the tool and wrote a simple program (.stp). However I keep getting the same error, which I have searched information in many places without success:
After executing:
sudo stap my_profiler.stp
I get:
semantic error: libdwfl failure (all kernel modules found): no error
Pass 3: translation failed. Try again with another '--vp 001' option.
According to https://sourceware.org/systemtap/SystemTap_Beginners_Guide/errors.html
semantic error: libdwfl failure
There was a problem processing the debugging information. In most cases, this error results from the installation of a kernel-debuginfo package whose version does not match the probed kernel exactly. The installed kernel-debuginfo package itself may have some consistency or correctness problems.
I have found no relevant information on the "kernel-debuginfo" package. I have also tried the verbose option without benefit. I even tried with an old Snapshot of the VM. Any ideas?
The code of the .stp program I ran:
probe timer.profile{
printf("Process: %s\n", execname())
printf("Process ID: %d\n", pid())
}
Found the problem!!!! It seemed that I was using the wrong version of the Linux Kernel. I was using the default kernel supplied by the version I wrote in the question. It seems that that version (the 2.6.32-5-686 one) has problems with the debug-info so all I did was try the same with another version (the Linux version 3.9.6 with gcc version 4.7.2 Debian 4.7.2-5) and it worked without trouble :)
I've a gumstix Overo which I am configuring to work with a e-CAM camera. The documentation provided by camera manufacture asks me to patch a 2.6.34 kernel and compile in Video For Linux support. When I look at gumstix user documentation they say I should execute:
bitbake -c menuconfig virtual/linux
However when I run this command I get
bacon:~/proj/overo-oe$ bitbake -c menuconfig virtual/linux
NOTE: Handling BitBake files: \ (7100/7100) [100 %]
NOTE: Parsing finished. 6382 cached, 413 parsed, 305 skipped, 2 masked.
ERROR: Nothing PROVIDES 'virtual/linux'
I'm not altogether sure about how I provide virtual/linux. Any ideas about how to fix this error?
This might be a case of out-of-date documentation. In any case, my current work around is to name the kernel explicitly: bitbake -c menuconfig linux-omap3-2.6.34
I can help with a step-by-step procedure to bitbake 3.0 kernel.
If that may be helpful for you. Using a WMware Ubuntu ...
I would stay away from convoluted build systems as bitbake. Every one seems to be inventing one... making the 'tool' to get more of your time then the thing you want to do with the tool. All of them are the same. Linus would quote on those guys:
Just don't do it...!