Author

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

legendary
Activity: 952
Merit: 1000
Maybe this is a linux question, and less of a CGMiner question, but 2.11.0 can't see my Single without running it as root. I had to install libusb-1.0 just to update to 2.11.0, and when I first tried, it came up with that All devices disabled, cannot mine! Running as root works fine, tho. I feel like there's a simple fix, but I just don't know what it is.

Have you tried this by chance?

Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL FPGA, but
cgminer can't mine on them
A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices:
 sudo ls -las /dev/ttyUSB*
will give output like:
 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0
This means your account must have the group 'dialout' or root priviledges
To permanently give your account the 'dialout' group:
 sudo usermod -G dialout -a `whoami`
Then logout and back in again

I'm not running a standard 64bit or even x86 linux, but rather Linaro 12.11 for ARM devices. I don't see any /dev/ttyUSB* devices, and adding my user to dialout group did nothing. Any other thoughts?
hero member
Activity: 626
Merit: 500
Mining since May 2011.
Maybe this is a linux question, and less of a CGMiner question, but 2.11.0 can't see my Single without running it as root. I had to install libusb-1.0 just to update to 2.11.0, and when I first tried, it came up with that All devices disabled, cannot mine! Running as root works fine, tho. I feel like there's a simple fix, but I just don't know what it is.

Have you tried this by chance?

Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL FPGA, but
cgminer can't mine on them
A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices:
 sudo ls -las /dev/ttyUSB*
will give output like:
 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0
This means your account must have the group 'dialout' or root priviledges
To permanently give your account the 'dialout' group:
 sudo usermod -G dialout -a `whoami`
Then logout and back in again
legendary
Activity: 952
Merit: 1000
Maybe this is a linux question, and less of a CGMiner question, but 2.11.0 can't see my Single without running it as root. I had to install libusb-1.0 just to update to 2.11.0, and when I first tried, it came up with that All devices disabled, cannot mine! Running as root works fine, tho. I feel like there's a simple fix, but I just don't know what it is.
hero member
Activity: 924
Merit: 1000
Watch out for the "Neg-Rep-Dogie-Police".....
 Grin Grin Happy Birthday!!  Grin Grin

And many thanks for all your hard work making cgminer the best of the rest.


Kano, thanks once again for the updated Xubuntu binary - you're the man.

Peace.
legendary
Activity: 2688
Merit: 1240
A "devs" via API now only delivers my ICA boards, not my ZTEX ones...

I've got Icarus (Cairnsmore and Icarus) Boards as well as ZTEX Boards connected to one linux 64 machine.

Before 2.11.0 all boards could be read out via API command "devs". Now only the Icarus Boards are returned.

Thanks

oc
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
2.11.0a 2.11.0 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.0a
chmod +x cgminer-2.11.0a
md5sum cgminer-2.11.0a

daebbc19805506e313ca3c54ee98b548  cgminer-2.11.0a

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

57e8305cf0de03f8d487496a56f2e3bb  cgminer-2.11.0a

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 for a while without any problems.

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 cores 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

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
hero member
Activity: 700
Merit: 500
Geez man...is that a clown wig inside the cake ?  Shocked
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
Go Con, it's your birthday, etc.   Grin

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
hero member
Activity: 700
Merit: 500
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New version: 2.11.0, 2nd March 2013 Happy birthday to me

New unstable version preparing for ASIC hardware. This version is being released to fix any bugs found in the USB and hotplug code prior to it being needed by real ASIC hardware. I had one last go at improving the OpenCL kernels for GPU mining since this code will soon become of historical interest only except in the case of scrypt.

IF YOU ARE ON WINDOWS YOU NEED A NEW AND DIFFERENT USB DRIVER
From FPGA readme:
Quote
For ModMinerQuad (MMQ) and BitForce (BFL)
-----------------------------------------

...

The best solution for this is to use a tool called Zadig to set the driver:
 http://sourceforge.net/projects/libwdi/files/zadig/

This allows you set the driver for the device to be WinUSB which is usually
required to make it work if you're having problems

Human readable changelog:

- Huge updates to USB code including direct USB and hotplug changes by Kano, including updates to various FPGA driver modules to suit the new code.
- New OpenCL GPU kernels for poclbm, diablo and scrypt! First speed up in a long time (but absolutely miniscule). As always, any faster kernel tends to bring out hardware instability if you've overclocked your GPUs to within an inch of their stability.
- Resume support for stratum. Currently only one pool supports it but hopefully others will follow suit.
- Try to not lose stratum shares across pool switches.
- Fix for scrypt kernels with thread concurrency set to >9999
- Lots of minor bugfixes and improvements.
- Lots of infrastructure added to allow for queueing devices in the future (i.e. BFL asics if/when they appear) but not currently used.


Full changelog:

- Update kernel file names signifying changes.
- Update a pool's last work time when the work is popped as well as staged.
- API always report failed send() replies
- Update diff stale: total and pools when stratum throws away shares
- Keep stratum connections open for 2 minutes after the last work item was
staged to allow stray shares to be submitted on pool switching.
- Try to extract the sessionid associated with mining.notify on 3rd level array
and submit it along with the userid to support mining resume, failing gracefully
and restarting if the pool rejects it.
- Speed up watchdog interval and therefore display updates to 2 seconds.
- Update copyright dates.
- Cope with misread sessionid on stratum for now.
- Use constants from the array of __constants throughout the diablo kernel.
- Create a __constant array for use within diablo kernel.
- Fix --benchmark generating valid work for cgminer.
- Use the sessionid as passed on stratum connect to attempt to resume a
connection once and then clear it if it fails, to use a new connection.
- Move to storing the nonce1 in the work struct instead of the sessionid for the
now defunct first draft mining.resume protocol.
- Use global constant arrays for all other constants used in scrypt kernel.
- Use global __constants for sha functions in scrypt kernel.
- Use constants for endian swap macros.
- Revise scrypt kernel copyright notice.
- Separate out additions in scrypt kernel.
- Reuse some Vals[] variables that can be assigned to constants earlier in the
poclbm kernel, making for fewer ops.
- Put all constants used in poclbm kernel into __const memory array to speed up
concurrent reads on the wavefront.
- BFL stop 1st init command if no device
- Add a get_queued function for devices to use to retrieve work items from the
queued hashtable.
- Bugfix: Duplicate stratum sessionid when copying work, to avoid double-free
- Bugfix: Missing pool_no parameter to applog for no-stratum-sessionid debug
message
- Add the choice of hash loop to the device driver, defaulting to hash_sole_work
if none is specified.
- Add comments.
- Add a driver specific flush_work for queued devices that may have work items
already queued to abort working on them on the device and discard them.
- Flush queued work on a restart from the hash database and discard the work
structs.
- Create a central point for removal of work items completed by queued device
drivers.
- Create a fill_queue function that creates hashtables of as many work items as
is required by the device driver till it flags the queue full.
- Create the hash queued work variant for use with devices that are fast enough
to require a queue.
- Update copyright year.
- Fix tv_lastupdate being made into tv_end and update the hashmeter on cycle,
not opt_log_interval.
- Fix tv_lastupdate being made into tv_end and update the hashmeter on cycle,
not opt_log_interval.
- Only continue submitting shares with mining.resume support on stratum when the
session id matches.
- Provide support for mining.resume with stratum, currently re-authorising after
successful resumption pending finalising of the protocol process.
- Provide basic framework for restarting stratum depending on whether resume
support exists or not.
- Abstract out the setting up of the stratum curl socket.
- Free sessionid in clean_work and remove redundant setting of strings to NULL
since the whole work struct is zeroed.
- Only clear stratum shares mandatorily on stratum dropouts when the pool does
not support resume.
- Try resubmitting stratum shares every 5 seconds for up to 2 minutes if the
pool session id exists and matches on failure to submit.
- Do as much outside of mutex locking of sshare_lock as possible.
- Remove last reference to struct work used outside the sshare_lock in
submit_work_thread
- Unlock the sshare_lock in submit_work_thread when all references to work and
sshare are complete.
- Add timestamps to stratum_share structs as they're generated and copy the
stratum sessionid if it exists to stratum work generated.
- Store session id for stratum if the pool supports it for future mining.resume
support.
- API.java allow partial reads
- debug_cb buffer type warning
- MMQ rewrite the last of the old scanhash loop and drastically reduce CPU
- hash_sole_work can be static
- Make the numbuf larger to accept larger scrypt parameters.
- Keep the unique id of each work item across copy_work to prevent multiple work
items having the same id.
- Abstract out the main hashing loop to allow us to use a separate loop for
devices that are fast enough to require queued work.
- Provide a noop thread_enable function for drivers that don't support it.
- Provide a noop thread_shutdown function for drivers that don't support it.
- Provide a noop hw_error function for drivers that don't support it.
- Provide a noop prepare_work for drivers that don't support it.
- Provide a noop thread_init for drivers that don't support it.
- Provide a noop can_limit_work for devices that don't support it.
- Provide a noop thread_prepare function for drivers that don't use
thread_prepare.
- Use blank_get_statline_before for GPU devices that don't support adl
monitoring.
- Provide a noop get_stats function for drivers that don't support it.
- Provide a blank get_statline for drivers that don't support it.
- Provide a blank get_statline_before function for drivers that don't have one.
- Fill drivers missing reinit_device with a noop version.
- add 'count' to cumstomsummarypage 'calc'
- hotplug use get_thread() where appropriate
- convert sleep(const) to nmsleep()
- remove empty #ifdef
- call a separate get_devices() with locking, as required
- usbutils - avoid free cgusb twice
- usbutils hotplug v0.1
- Report USB nodev as ZOMBIE on the screen
- Change file modes.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Is there a way to make the timeout for pools that are down quicker? Only on startup, When I shut my primary pool down, the cgminer process hangs for 2-30 seconds before it gives up and drops to pool 2/backup. In older versions it was instant. In 2.10.x it just sits there.
That's cause it's checking all 3 protocols and has to give all of them a reasonable timeout duration... Kind of a catch 22 problem. I want to shorten it next version but some pools really need up to 60 seconds to connect.
hero member
Activity: 658
Merit: 500
Is there a way to make the timeout for pools that are down quicker? Only on startup, When I shut my primary pool down, the cgminer process hangs for 2-30 seconds before it gives up and drops to pool 2/backup. In older versions it was instant. In 2.10.x it just sits there.
sr. member
Activity: 470
Merit: 250
It's not enabled...

Try reconfiguring Xorg
sudo aticonfig --adapter=all -f --initial

Excellent, now they're both working! Only trouble is that it somehow screwed up my desktop pretty bad but I might be able to fix that... it's still usable and I'll have a look at what changes were made to the xorg.conf file. Many thanks!
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I'm trying to mine litecoins under linux with a 6950 and a 6990. The 6950 works fine but the 6990 isn't detected. I tried it with and without the crossfire cable but the result is the same:

Quote
./cgminer -n
[2013-02-28 17:53:16] This error says the device is not enabled                   

Any ideas?
It's not enabled...

Try reconfiguring Xorg
sudo aticonfig --adapter=all -f --initial
sr. member
Activity: 470
Merit: 250
I'm trying to mine litecoins under linux with a 6950 and a 6990. The 6950 works fine but the 6990 isn't detected. I tried it with and without the crossfire cable but the result is the same:

Quote
./cgminer -n
 [2013-02-28 17:53:16] CL Platform 0 vendor: Advanced Micro Devices, Inc.                   
 [2013-02-28 17:53:16] CL Platform 0 name: AMD Accelerated Parallel Processing                   
 [2013-02-28 17:53:16] CL Platform 0 version: OpenCL 1.2 AMD-APP (1113.2)                   
 [2013-02-28 17:53:16] Platform 0 devices: 1                   
 [2013-02-28 17:53:16]    0   Cayman                   
 [2013-02-28 17:53:16] Failed to ADL_Adapter_ID_Get. Error -10                   
 [2013-02-28 17:53:16] This error says the device is not enabled                   
 [2013-02-28 17:53:16] Failed to ADL_Adapter_ID_Get. Error -10                   
 [2013-02-28 17:53:16] This error says the device is not enabled                   
 [2013-02-28 17:53:16] Failed to ADL_Adapter_ID_Get. Error -10                   
 [2013-02-28 17:53:16] This error says the device is not enabled                   
 [2013-02-28 17:53:16] Failed to ADL_Adapter_ID_Get. Error -10                   
 [2013-02-28 17:53:16] This error says the device is not enabled                   
 [2013-02-28 17:53:16] GPU 0 AMD Radeon HD 6900 Series  hardware monitoring enabled                   
 [2013-02-28 17:53:16] 1 GPU devices max detected

Any ideas?
legendary
Activity: 952
Merit: 1000
Queued work and efficiency mean pretty much nothing now, especially with stratum. It's simply a function of how often the pool is sending you a new template and there is no "standard" for that, some do 30 seconds, some 60 etc. The more often they're sending you a template, then potentially the more transactions you're supporting if the pool is adding all the latest transactions every 30 seconds instead of 60, but even that equation isn't clear with bitcoind not necessarily simply taking all transactions. The work queueing in cgminer is a fairly complex machine designed for optimally keeping devices as busy as possible, and trying to balance things between pools for whatever reason is a distant second priority. Trying to improve the latter will come at the price of the former. This will become far more acute with ASIC hashrates than it is at the moment with GPUs, and it clearly works with avalon running ~66 or 88 GH off a very low power CPU with cgminer. I doubt the equivalent of the CPU hardware in the Avalon could handle a 1.5TH minirig when they come out but a regular desktop/laptop/tablet CPU will easily do so, and cgminer is heavily multithreaded so multicore/mulithread CPUs (which are everywhere in these devices) are advantageous.

Thank you for the detailed explanation! It's not really a big concern, as I've really just been fooling around with it for the past day or two. It would be nice to have it even split to all 5 pools, but it's not a critical component.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Queued work and efficiency mean pretty much nothing now, especially with stratum. It's simply a function of how often the pool is sending you a new template and there is no "standard" for that, some do 30 seconds, some 60 etc. The more often they're sending you a template, then potentially the more transactions you're supporting if the pool is adding all the latest transactions every 30 seconds instead of 60, but even that equation isn't clear with bitcoind not necessarily simply taking all transactions. The work queueing in cgminer is a fairly complex machine designed for optimally keeping devices as busy as possible, and trying to balance things between pools for whatever reason is a distant second priority. Trying to improve the latter will come at the price of the former. This will become far more acute with ASIC hashrates than it is at the moment with GPUs, and it clearly works with avalon running ~66 or 88 GH off a very low power CPU with cgminer. I doubt the equivalent of the CPU hardware in the Avalon could handle a 1.5TH minirig when they come out but a regular desktop/laptop/tablet CPU will easily do so, and cgminer is heavily multithreaded so multicore/mulithread CPUs (which are everywhere in these devices) are advantageous.
legendary
Activity: 952
Merit: 1000
If you use miner.php, you can see how many shares you've sent to each pool really easily.

I tried balancing 3 servers (us.ozco.in, stratum.ozco.in and MtRed's stratum server) and got decent results, but my reject rate was slightly higher across the board; about 0.2% rather than 0.1%. MtRed was also getting quite a bit more shares (hence why I added 2 Ozcoin servers), probably something to do with the server only sending out new work about once a minute. I wonder if there's really any benefits to balancing DGM and PPS...
Thanks, I'll give the miner.php a try.

I've also noticed the same thing as you: Ozcoin gets far less shares than the other 4 pools. Of the 5 pools I'm testing this on, 3 of them are right around the same amount of accepted shares, Ozcoin is about 15-20% lower, and then EMC is about 15-20% higher. Ozcoin has a high Queued work count with a low efficiency %, and EMC has a high Queued work count with a high efficiency %. So this means Ozcoin is sending new work more often, and EMC is sending work less often? Yet somehow that ends up with fewer/more shares? Someone smarter than me wanna explain this?

Now this is also a single 7970 split up between 5 pools, so they're each getting a tiny little chunk.
newbie
Activity: 26
Merit: 0
Not sure if you already know this but....

in cgminer-2.10.5 the config script requires libcurl-7.18.2 but libcurl-7.25+ is actually required It looks like you missed a message or test Smiley

Jump to: