Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 401. (Read 5805537 times)

[RESOLVED] - Updated to 2.11.2... Thanks for the suggestion Kano.

Hello,

My cgminer doesn't display any Options when I hit the keys P for Pools Options and G for GPU options etc. Anyone know what I might have done wrong?

I've got cgminer2.10.5 64bit running on Ubuntu12.10. Only got the 1 GPU (7970).

Thanks in advance,
QG

2.11.2a 2.11.2 recompiled on 64 bit xubuntu 11.04 (as usual) and also on the RPi 32 (2012-12-16-wheezy-raspbian)

https://github.com/kanoi/cgminer-binaries
(the 64 bit version also works on Fedora 16 and 17)

To get the 64 bit xubuntu 11.04 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Ubuntu_11.04_x86_64/cgminer-2.11.2a
chmod +x cgminer-2.11.2a
md5sum cgminer-2.11.2a
f8ed7b7718d98084ed4baacf6b31d6bb  cgminer-2.11.2a

To get the RPi 32bit binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/RPi_32/cgminer-2.11.2a
chmod +x cgminer-2.11.2a
md5sum cgminer-2.11.2a
fa9d9320acf7cd3d39881e29648618d1  cgminer-2.11.2a

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
On xubuntu 11.04 - first get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

I've run both binaries without any problems with 1x6950 (yep I've started using one again ) 1xBFL, 2xICA and 1xMMQ

The same configure options as cvolivas' binary version for 64 bit xubuntu 11.04
In case anyone was wondering:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make
However, the -g (instead of -O2) means it's a debug build so if anyone finds a problem and has core dumps enabled, it will dump a much more useful debug core.

All FPGAs (only) for the RPi 32bit version
CFLAGS="-g -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-modminer --enable-ztex
make clean
make
You will need to install libusb-1.0.0

Reminders from before:

1
Important re-paste from before:
Now some important information about the BFL USB driver.
On linux, if you wish to switch back to the 2.10.5a, 2.10.4a or earlier version, you'll need to unplug and re-plug in your FPGAs or reboot your rig.
On windows (as described in FPGA-README) you'll need to update your windows USB driver to use the new cgminer


2
OK, if you are running cgminer 2.11.0 (or later) on linux as non-root user you may need to do the following also:

Create /etc/udev/rules.d/01-cgminer.rules
With:
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6014", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="plugdev"
ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0003", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="plugdev"

And also:
sudo usermod -G plugdev -a `whoami`

Then reboot ... (or use udevadm to reload the rules and retrigger the devices - but I couldn't get that to work on my RPi without rebooting)

That is a bit overkill, but for now that's what I suggest unless I come up with a simpler set of rules.

Edit: if your linux distro doesn't have the 'plugdev' group, you can create it like:
sudo groupadd plugdev


3
If you read the FPGA-README, it mentions you need to use the WinUSB driver - not the FTDI one.
As per:
Cgminer no longer uses the specific drivers - it's direct USB using the single libusb driver
(for everything 'USB' except Icarus - until I get around to changing that ... possibly one day in the far future )

Edit: 2 suggestions about zadig:
1) Run it as administrator
2) Menu: Options -> List all devices

New version: 2.11.2, 9th March 2013

Keep on quashing bugs in 2.11 series and developing further, hopefully a stable release soonish (this one if we're lucky!).


Human readable changelog:

Numerous fixes to the parallel pool test startup code which should work robustly now, including fixes for crashes and failure to fall back to pools when they come back to life.
Ability to start work on a backup pool much sooner once a stratum pool gets an interrupted connection.
Hopefully fixes for API related crashes.
Fixed a memory leak with GPU share submission.
More named threads on operating systems that support them.
Make AMD APP SDK 2.8 GPUs use diablo kernel for non-Tahiti chipsets.
Fixed an ancient bug where if you have multiple OpenCL platforms installed (eg Intel and AMD) with no devices on the highest numbered one, cgminer would refuse to work on any devices.


Full changelog:

- Whitelist AMD APP SDK 2.8 for diablo kernel.
- Cope with the highest opencl platform not having usable devices.
- Fix memory leak with share submission on GPU work structures as discovered by
twobitcoins.
- usb_cleanup() without locking.
- Use curl_easy_cleanup to close any open stratum sockets. (Spotted by luke-Jr)
- Show pool number in switch message
- Don't start testing any pools with the watchpool thread if any of the test
threads are still active.
- Set sockd to false should curl setup fail on stratum.
- Close any open sockets when reusing a curl handle and reopen the socket
whenever we're retrying stratum.
- Set pool died on failed testing to allow idle flag and time to be set.
- Remove unused pthread_t typedefs from struct pool.
- Perform pool_resus on all pools that are found alive with the test pool
threads.
- Use pool_unworkable in select_balanced as well.
- Differentiate pool_unusable from pool_unworkable.
- Keep a connection open on higher priority stratum pools to fail back to them.
- Rename threads according to what pool they're associated with as well.
- Set the wrong bool in pool_active
- Start the stratum thread only if we successfully init and authorise it,
otherwise unset the init flag.
- Make the initialisation of the stratum thread more robust allowing the
watchpool thread safe access to it after the stratum thread is started.
- API no longer ignore send() status
- API make the main socket non-static

Mining in mobile, tablet?
My head spinning.

I am still having issues.. Card is clocked at stock speeds and everything is up to date...



Keep getting Invalid Nonce - HW error....


Any ideas?

Working hard to fix remaining showstopper bugs in 2.11... new version out today sometime.

Yeah the ASIC MiniRig will be using an ASUS Nexus7 (I have a Nexus7 already given to me by BFL while I was there)
I also have a Samsung Galaxy S III (free with my contract renewal on my phone a week before I went to BFL)
So yeah I'll be messing with testing cgminer on android soon ... and hoping at least the Nexus7 can handle 1.5TH/s ... so a GSIII 'should' handle an FPGA or a Single ASIC easily enough
"George" at BFL of course is the one doing it - but I'll try getting it to work on the command line on the Nexus7 (and my phone) myself as well once we have some ASIC hardware and cgminer working with it.
ckolivas current git (and mine also - but nothing extra in my git at the moment) are all the new USB code with hotplug etc.

Guy's
There is a problem with pool authorization with 2.11.1 tried latest commit (81567e515707891837f52bc3aac7d5916dfff5a2). When i start cgminer it says pool rejected share error unauthorized. After a couple of restarts it is ok. This happens for the first time though and was ok all the way up to 2.10.5
Best

I am stupid:
Mining with a 5550 SFF:

Can anyone help me with my issue:

C:\Users\Galaxy\Desktop\Hashing\guiminer\miners\cgminer-2.10.5-win32\cgminer.exe -u Galaxy10 -p ******** -o http://25.174.60.33:8332 d 0 -l 1 -T

This is a sub net within a closed network, but i get the following after 30 seconds, and I know the addressee works, also made a local host and it still fails with -o http://127.0.0.1:8332  but CG miner crashes (hard) after loading strantum.

Galaxy10  Password: *******
 [2013-03-08 13:33:49] Press any key to exit, or cgminer will try again in 15s.
 [2013-03-08 13:35:07] Pool 0 slow/down or URL or credentials invalid
 [2013-03-08 13:35:07] Unable to get work from pool 0 http://25.174.60.33:8332
 [2013-03-08 13:35:07] No servers were found that could be used to get work from
.
 [2013-03-08 13:35:07] Please check the details from the list below of the serve
rs you have input
 [2013-03-08 13:35:07] Most likely you have input the wrong URL, forgotten to ad
d a port, or have not set up workers
 [2013-03-08 13:35:07] Pool: 0  URL: http://25.174.60.33:8332  User:Galaxy10  Password: ********
 [2013-03-08 13:35:07] Press any key to exit, or cgminer will try again in 15s.

Contversely this string works:
C:\Users\Galaxy\Desktop\Hashing\guiminer\miners\Coin\coin-miner.exe -u Galaxy10 -p ******** -o http://25.174.60.33:8332

Updated to 11.1 adn now strantum:

C:\Users\Galaxy\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\mi
ning_proxy_1.2.0.exe\twisted\internet\win32eventreactor.py:64: UserWarning: Reli
able disconnection notification requires pywin32 215 or later
C:\Users\Galaxy\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\mi
ning_proxy_1.2.0.exe\twisted\web\util.py:372: DeprecationWarning: Passing filena
mes or file objects to XMLFile is deprecated since Twisted 12.1.  Pass a FilePat
h instead.
2013-03-08 13:42:20,914 INFO proxy jobs. # C extension for midstate not
available. Using default implementation instead.
2013-03-08 13:42:20,917 INFO proxy mining_proxy.main # Stratum proxy version: 1.
2.0
2013-03-08 13:42:20,917 INFO proxy mining_proxy.main # Trying to connect to Stra
tum pool at stratum.bitcoin.cz:3333
2013-03-08 13:42:21,029 INFO stats stats.print_stats # 1 peers connected, state
changed 1 times
2013-03-08 13:42:21,029 INFO proxy mining_proxy.on_connect # Connected to Stratu
m pool at stratum.bitcoin.cz:3333
2013-03-08 13:42:21,029 INFO proxy mining_proxy.on_connect # Subscribing for min
ing jobs
2013-03-08 13:42:21,151 INFO proxy mining_proxy.main # -------------------------
----------------------------------------------
2013-03-08 13:42:21,151 INFO proxy mining_proxy.main # PROXY IS LISTENING ON ALL
 IPs ON PORT 3333 (stratum) AND 8332 (getwork)
2013-03-08 13:42:21,151 INFO proxy mining_proxy.main # -------------------------
----------------------------------------------
2013-03-08 13:42:21,153 INFO proxy client_service.handle_event # New job b for p
revhash a01b50b9, clean_jobs=True
2013-03-08 13:42:34,239 INFO stats stats.print_stats # 2 peers connected, state
changed 1 times
2013-03-08 13:42:34,240 ERROR protocol protocol.process_failure # [Failure insta
nce: Traceback: : subscribe() takes exactly 1 argum
ent (2 given)
stratum\protocol.pyo:166:dataReceived
stratum\protocol.pyo:191:lineReceived
stratum\services.pyo:13:_handle_event
stratum\services.pyo:81:call
--- ---
twisted\internet\defer.pyo:134:maybeDeferred
stratum\services.pyo:78:_run
twisted\internet\defer.pyo:1178:unwindGenerator
]
None

Hmmm ... talking about memory: The 7970s that I use have 6GB each. Might this be a problem? 7970s usually only have 3GB.

Working on it. There're some fixes in git already which should prevent the crash.

Yup, me too........

cgminer-2.11.1-x86_64-built.tar.lrz is the linux build ...

what is the difference between win32.zip version and cgminer-2.11.1-x86_64-built.tar.lrz

No idea, I only ever got 575kH out of my 7970s but I had 4 of them and ran them at stock memclocks with 4GB ram.

How much would I need for 2 x 7970 ?

I'd say it's unlikely, but I don't really play with scrypt much any more. Perhaps you just need more system ram.

Yep at the moment all BFL/MMQ devices are detected immediately.

--hotplug 0 will only stop it finding new devices when you plug them in.

I've decided on how to handle this already but not implemented it yet.
I'll move it further up the todo list

In the mean time, if you start the cgminer that uses the FPGAs first (with -G), then start the GPU cgminer 2nd with --hotplug 0 then the GPU miner won't pick them up at startup or later via hotplug.

I am using cgminer 2.10.4 for Litecoin mining. win7x64. AMD 7970. various versions of Catalyst (12.10, ... , 13.1, 13.2)

On https://github.com/litecoin-project/litecoin/wiki/Mining-hardware-comparison there's a 7970 with 682 kHash/s
clock: 1000MHz, mem clock: 1600MHz
command line args are: --shaders 2048 --thread-concurrency 8192 -I 13 -g 2 -w 256

I'm not getting more than 550 kHash/s with the exact same settings.

Is 682 a typo (-> 582) - or is it really possible?