OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[kano]

Okay I have a laptop with a usb3.0 port and it's all running fine. That's good but now I have doubts that a pi will work...

Unfortunately, the Raspberry Pi is known not to work well with USB 3.0 hubs. I believe it's a hardware limitation of the Pi, not an issue with any particular software or drivers.

My RPi works fine with a USB3.0 hub with 3 AMUs

Maybe some USB3.0 hubs have problems?

However, Rasbian has a bad version of libusb in it - if you have that - yes it will screw up.

If you use RPi Arch http://www.kano-kun.net/?p=87 the libusb problem is gone.
Minepeon also uses Arch: https://asktom.cf/index.php?topic=137934.0

Edit: and of course as I've posted in here many times over the last week - libusb verisons are screwed for AMU/ICA
Here's something like how to rebuild for windows and linux (though it's not the final version of the doc)
https://dpaste.de/a5TvN/

Oh, maybe that's been the problem. I remember there being a lot of angst about RPis and USB 3.0 early on, but maybe nobody had tried Arch at that point.

Updated version of that rebuild info is now in the main README with 3.3.2
My Arch binary in https://github.com/kanoi/cgminer-binaries is statically linked with the working libusb also.

[-Redacted-]

Would static linking a fixed libusb also work for producing a Raspian version?   I'm, umm, not particularly fond of the Arch distro...

[-ck]

OK it's missing Avalon - that's the problem
you need --enable-avalon when you configure it.
Do you build it or someone else?

Ah, I see. I just downloaded 3.3.2 (Windows) from here and thought this would be working out of the box.
So I guess I have to build it again with the avalon option enabled?

Previously no one in their right mind would have run a full avalon device on windows so I wasn't including the avalon driver, but the bitburner devices are a little different. So I've uploaded a new binary with the avalon driver built in (includes a last minute bugfix that also would only affect windows users).

[-ck]

Tried the new version with my GPU/usb erupter mix.  Didn't recognize the GPU and the "-I" switch. Command worked before new version.

BTW running 5870 with 2.4 sdk cat is at 11.12


*update*
tried the new version with my 7970 and the same issue

As my build environment had to be rebuilt from scratch when I returned from overseas, I was missing some stuff which accidentally built the windows binary without GPU support. I've reuploaded a new binary which should work now.

[Mattzz]

Would it be possible that this could get CUDA support in the future.
Just wondering if its been planned or something as I am using cudaminer currently and it brings my
660 ti upto 200kh/s (I think thats right) on ltc and this has a few features I would love
to be able to have but alas are not available in cudaminer

[-ck]

Would it be possible that this could get CUDA support in the future.
Just wondering if its been planned or something as I am using cudaminer currently and it brings my
660 ti upto 200kh/s (I think thats right) on ltc and this has a few features I would love
to be able to have but alas are not available in cudaminer

No, no one could afford to pay me to do that.

[crazyates]

Would it be possible that this could get CUDA support in the future.
Just wondering if its been planned or something as I am using cudaminer currently and it brings my
660 ti upto 200kh/s (I think thats right) on ltc and this has a few features I would love
to be able to have but alas are not available in cudaminer

No, no one could afford to pay me to do that.

[juhakall]

I tried building the newest git version, and noticed that my linux scrypt miners no longer worked properly. Hashrates were minimal because intensity was only 8. cgminer was complaining about the config being broken, and after starting with -T I saw the error was "Invalid config option --intensity: Invalid value passed to set intensity". This was introduced in commit 2b171f7fae19a451abefd5189ecad64fbd08d8a0, everything still works fine with commit cb6d62de08995cb3ce2ae906dfa629f42d382c21. I'm using intensity 17 on the linux rigs, I don't have the problem on my Windows rigs with a lower intensity.

[-ck]

I tried building the newest git version, and noticed that my linux scrypt miners no longer worked properly. Hashrates were minimal because intensity was only 8. cgminer was complaining about the config being broken, and after starting with -T I saw the error was "Invalid config option --intensity: Invalid value passed to set intensity". This was introduced in commit 2b171f7fae19a451abefd5189ecad64fbd08d8a0, everything still works fine with commit cb6d62de08995cb3ce2ae906dfa629f42d382c21. I'm using intensity 17 on the linux rigs, I don't have the problem on my Windows rigs with a lower intensity.

Try telling it --scrypt before setting the intensity?

[juhakall]

I tried building the newest git version, and noticed that my linux scrypt miners no longer worked properly. Hashrates were minimal because intensity was only 8. cgminer was complaining about the config being broken, and after starting with -T I saw the error was "Invalid config option --intensity: Invalid value passed to set intensity". This was introduced in commit 2b171f7fae19a451abefd5189ecad64fbd08d8a0, everything still works fine with commit cb6d62de08995cb3ce2ae906dfa629f42d382c21. I'm using intensity 17 on the linux rigs, I don't have the problem on my Windows rigs with a lower intensity.

Try telling it --scrypt before setting the intensity?

Nope, that didn't help. The windows rigs also have intensity set before scrypt in the config, and it works.

EDIT: --scrypt on the command line makes it works on linux too, though. So you seem to be on the right track. The intensity sanity check just doesn't detect that scrypt is being enabled from the config on linux.

[pluMmet]

Okay 3.3.2 on windows and still slow...



I'm not sure what to do here?

after few minutes everything is sick and back to square 1

NM- Switched to usb2.0 port of laptop and it's all running great

Next step pi

[Polyatomic]

Okay 3.3.2 on windows and still slow...


I'm not sure what to do here?

after few minutes everything is sick and back to square 1

Check all your peripherals , USB hub/s , USB cables , power supply etc . Its probably not the miner client. Try swapping out a USB cable or try just one erupter and see if u can get just one to mine at 335 Mh/s.

[Nemo1024]

I tried building the newest git version, and noticed that my linux scrypt miners no longer worked properly. Hashrates were minimal because intensity was only 8. cgminer was complaining about the config being broken, and after starting with -T I saw the error was "Invalid config option --intensity: Invalid value passed to set intensity". This was introduced in commit 2b171f7fae19a451abefd5189ecad64fbd08d8a0, everything still works fine with commit cb6d62de08995cb3ce2ae906dfa629f42d382c21. I'm using intensity 17 on the linux rigs, I don't have the problem on my Windows rigs with a lower intensity.

Try telling it --scrypt before setting the intensity?

I noticed this bug as well. It brought 3 of my rigs down once I updated to 3.3.2 They all had -I before --scrypt.

This is a bug and should be fixed. Parameter order should not affect validation.

[Newar]

New release: 3.3.2, 10th August 2013

Cairnsmore1 (yeah. I know...):

I have hold off to upgrade to 3.x from 2.11.3, but today the temptation was too big ;-)

Upgrading etc. all went fine on Ubuntu 12.04.2, worked through the READMEs, did the libusb-1.0.16-rc10, disconnect USB, removed all --scan serial (ttyUSB*) from config file, restart everything, reconnect USB, did NOT issue the modprobe command...

Out of the 6x CM1s, cgminer only detects CMR0, 1 and 2. I let them run for a while with no problems, but of course I'm missing the rest of the boards.

Anyone tried the latest version with CM1s? Any other pointers?

[os2sam]

I noticed this bug as well. It brought 3 of my rigs down one I updated to 3.3.2 They all had -I before --scrypt.
This is a bug and should be fixed. Parameter order should not affect validation.

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

[Nemo1024]

I noticed this bug as well. It brought 3 of my rigs down one I updated to 3.3.2 They all had -I before --scrypt.
This is a bug and should be fixed. Parameter order should not affect validation.

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

Well, in my SW development practice this is called a "regression" as it broke prior existing behaviour. Good enough reason for me to call it a bug.

[ak49er]

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

I call bullshit on pretty much everything in this post.  But a fix may not be the highest priority so at least a note as to the behavior would be useful.

[juhakall]

I noticed this bug as well. It brought 3 of my rigs down one I updated to 3.3.2 They all had -I before --scrypt.
This is a bug and should be fixed. Parameter order should not affect validation.

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

Well, in my SW development practice this is called a "regression" as it broke prior existing behaviour. Good enough reason for me to call it a bug.

Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file.

[-ck]

It's not that big a deal, I only just heard of it and I'll fix it next version. Let the discussion go.

[os2sam]

Well that may make sense if it were a scrypt miner.  But it is not it's a Bitcoin mining program which has graciously added scrypt support.

So this is not a bug.

Maybe clarification in the Scrypt Readme, if its not already there, would be in order.
Sam

I call bullshit on pretty much everything in this post.  But a fix may not be the highest priority so at least a note as to the behavior would be useful.

OK, fine,  I'm just expressing my opinion a bit and attempting to apply common sense.

It would just seem to make sense to me to tell the the mining software what type of mining I want it to do before telling it how I want it to mine that specific coin.

The previous posters remark about regression is very valid too, it seems to me.
Later,
Sam