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

[techman05]

Hello,

I've updated cgminer to the latest one and now none of my bfl miners work. I get usb errors on all of them.  I'm running it on windows 7. Works fine on 3.4.3.. Any idea what may be wrong?

May not be related but if we changing lib do we have newer winusb to install now?

[-ck]

Yay windows. At this rate I'll inadvertently completely deprecate windows support 

Gonna have to think on this. The rewrite started out trying to fix windows but instead linux keeps getting better and windows and osx worse.

[streetuff]

Yay windows. At this rate I'll inadvertently completely deprecate windows support 

Gonna have to think on this. The rewrite started out trying to fix windows but instead linux keeps getting better and windows and osx worse.

+1

[TR4L]

Yay windows. At this rate I'll inadvertently completely deprecate windows support 

Gonna have to think on this. The rewrite started out trying to fix windows but instead linux keeps getting better and windows and osx worse.

Are you also dropping scrypt mining?

[-ck]

Yay windows. At this rate I'll inadvertently completely deprecate windows support 

Gonna have to think on this. The rewrite started out trying to fix windows but instead linux keeps getting better and windows and osx worse.

Are you also dropping scrypt mining?

I didn't say I was intentionally doing anything. However, since you asked, scrypt mining is being deprecated at some stage in the future. While there is still incentive for me to maintain it I will do so, but if it becomes a support maintenance burden and there is no incentive for me to maintain it, I will deprecate it. For the time being it is not like that. If scrypt has suddenly stopped working then it is almost certainly the same old problem of having done a system upgrade between versions and that is what has broken scrypt since the cgminer code for it has not changed in many many versions. If you have an older version of cgminer that is still working despite the system upgrade, that is normal - because cgminer caches the old kernel binary (as a .bin file) and the system upgrade can't affect it.

[-ck]

Yay windows. At this rate I'll inadvertently completely deprecate windows support 

Gonna have to think on this. The rewrite started out trying to fix windows but instead linux keeps getting better and windows and osx worse.

+1

LOL, you want me to deprecate support for other OSes? I've gotta admit, I say that jokingly almost every single day. The reality is that 85% of my downloads from my site are for the windows binaries though. Let's call 3.5.1 the  last stable version for windows for the time being.

[-ck]

Hello,

I've updated cgminer to the latest one and now none of my bfl miners work. I get usb errors on all of them.  I'm running it on windows 7. Works fine on 3.4.3.. Any idea what may be wrong?

May not be related but if we changing lib do we have newer winusb to install now?

No, this issue is all in the libusb library built within cgminer.

[-ck]

3.6.2 won't even run on Win7:
[2013-10-16 07:08:27] BAS 1 usb write err:(-5) LIBUSB_ERROR_NOT_FOUND
[2013-10-16 07:08:27] BAS1: RequestQueJob failed (err=-5 amt=0)

Works for me.

Totally utterly bizarre. Fine for one person and a completely random error from another. Yay libusb.

The only other ace I have up my sleeve is to go back to the libusb previously used and implement garbage collection to recover the lost memory that it leaks. This will make the binary a heck of a lot larger and probably impossible to run/build on small embedded hardware, so it will have to be for the non-linux versions only. Nothing's impossible, but this is starting to grate more than just a little 

[ksenter]

Just fyi, the temp version that you put up a link to after 3.6.1 has been running fine for me for almost two days.  I haven't tried 3.6.2 yet.  I'll do that tonight.

[-ck]

Just fyi, the temp version that you put up a link to after 3.6.1 has been running fine for me for almost two days.  I haven't tried 3.6.2 yet.  I'll do that tonight.

See that's odd, cos 3.6.2 should be the same as the temp version, but if you find something different on going to 3.6.2 it may point to a particular problem that isn't related to the libusbx merge. Thanks.

[Askit2]

On the newest CGMiner 3.6.1 I have an issue on Linux. This problem is on a Raspberry Pi. It wasn't noticeable until I added more jalapeno's.
What happens is this. After running for a while it appears Linux runs out of USB devices. I know the problem is actually my USB devices errors.

The reason this seems like a problem is that when it runs out of devices in 22K shares or so 4 devices will not be working. It happens one at a time until it runs out completely. When it runs out the devices will be back to their initial numbering ex BAJ 7 and zombie. the only fix seems to be to quit cgminer so that it will start over. The hashrate is very low. I assume given enough other errors I would lose all 9.

Since no device was over 3% errors I would have assumed that it wouldn't get disabled as fast as it does. Most errors I notice are in response to a temp request. The reply is in process,0x(something),0x(something)(sometimes a third 0x(something) sometimes 0x00x00x00. At least that is how I remember it. I think that error was on 3.5.1. Current error looks like this

Code:

 [2013-10-16 03:33:04] BAJ 28 usb read err:(1) **UNKNOWN**
 [2013-10-16 03:33:04] BAJ28: QueJobStatus failed (err=1 amt=0)
 [2013-10-16 03:33:04] BAJ 28 failure, disabling!

I am not running the newest raspbian. I use one from 2/13. It holds up longer while mining and less frequently locks up the UI.

I have a different problem on Windows. Using a USB 2 or USB 3 hub the error rate is low. Using usb 1  hub I get devices that have accepted in the single digits like 9 to 300+ errors. I will likely pick up a USB 2.0 hub tomorrow. I see this a lot. I don't think its an error though.

Code:

USB BAJ read 2 bugger buffering 2 extra bytes

On the former issue, you've probably run out of semaphores due to the limit being lower on an RPi. Can't remember offhand how to change them but they require a few sysctl options.

On the latter, that's not a bug but just verbose information you can ignore mostly.

It doesn't seem like the windows one is just informational. It starts with CGMiner and stops when the 4 hashing units on my old usb 1 hub stop hashing. It only shows up again when those units restart for their maybe 20 seconds before they stop working again for at least an hour. If it's not important that's ok. But something else is going on and that is all I see.

As far as  the Linux issue I can just have it stop every 800 shares. Script restarts it unless it fails on quit. So far that is only 3 times in 12 hours.

EDIT: replaced usb 1 hub with usb2 hub. happily hashing away now. Win information is gone and units don't stop working after around 20 seconds.

[techman05]

Yay windows. At this rate I'll inadvertently completely deprecate windows support 

Gonna have to think on this. The rewrite started out trying to fix windows but instead linux keeps getting better and windows and osx worse.

You can do whatever if you can get a good image to use on my pi without it crashing after loading cgminer. Joke as you will if you could work around using winUSB That would get rid of your problems.

I'm still using windows and theres still other miners on windows if you find the need to kill a fork.

[techman05]

Anyone else have a random miner stop mining on 3.6.2.  I have 6 eroupters and one stopped working. I think CKolivias missed a bug somewhere. I ran it all night in 3.5.1 and didn't loose one soldier all night till I ran the new version for about half a day.


Also noting that 3.6.2 still won't close  it says "thread [2,1,5,3,4] failure exiting" when I press q to close. not sure if it has anything to do with my shown dead miner which was listed as amu 0.

BTW my total shares showed 64,000 if that's any magic number.

[dlasher]

Yay windows. At this rate I'll ...  completely deprecate windows support 

... actually expected that ages ago ...

[-ck]

Yay windows. At this rate I'll ...  completely deprecate windows support 

... actually expected that ages ago ...

Don't tempt me please it's hard enough to maintain motivation with windows support 

[os2sam]

Yay windows. At this rate I'll ...  completely deprecate windows support 

... actually expected that ages ago ...

Don't tempt me please it's hard enough to maintain motivation with windows support 

Just sent you and Kano a little M$ Windoze support motivation.

Thanks for your efforts,
Sam

[-ck]

Yay windows. At this rate I'll ...  completely deprecate windows support 

... actually expected that ages ago ...

Don't tempt me please it's hard enough to maintain motivation with windows support 

Just sent you and Kano a little M$ Windoze support motivation.

Thanks for your efforts,
Sam

Thanks man, much appreciated 

[Askit2]

3.6.2 isn't quiting on Linux. Well it quits and doesn't ever stop completely.

Code:

 cgminer version 3.6.2 - Started: [2013-10-17 00:53:31]
--------------------------------------------------------------------------------
 (2s):43.64G (avg):45.73Gh/s | A:5756  R:0  HW:11  WU:651.9/m
 ST: 2  SS: 0  NB: 1  LW: 5819  GF: 0  RF: 0
 Connected to multiple pools with block change notify
 Block: 000902dd937a4e9a...  Diff:268M  Started: [00:53:30]  Best share: 48.3K
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BAJ  0:  max 43C 3.93V | 5.278G/5.255Gh/s | A:555 R:0 HW: 0 WU: 70.8/m
 BAJ  1:  max 41C 3.85V | 5.207G/5.172Gh/s | A:615 R:0 HW: 0 WU: 76.4/m
 BAJ  2:  max 44C 3.60V | 5.186G/4.959Gh/s | A:506 R:0 HW: 0 WU: 74.1/m
 BAJ  6:  max 45C 3.90V | 5.662G/5.411Gh/s | A:804 R:0 HW: 0 WU: 78.9/m
 BAJ  7:  max 43C 3.55V | 5.067G/5.165Gh/s | A:613 R:0 HW:11 WU: 74.5/m
 BAJ 27:  max 44C 3.99V | 5.495G/5.556Gh/s | A:333 R:0 HW: 0 WU: 82.3/m
 BAJ 29:  max 45C 4.02V | 5.071G/5.383Gh/s | A: 41 R:0 HW: 0 WU: 86.4/m
 BAJ 32:  max 44C 3.50V | 5.494G/5.481Gh/s | A:123 R:0 HW: 0 WU: 82.8/m
 BAJ 33:  max 45C 2.46V | 5.909G/5.447Gh/s | A: 65 R:0 HW: 0 WU: 78.3/m
--------------------------------------------------------------------------------
 [2013-10-17 00:53:30] Pool 2 difficulty changed to 32
0)
 [2013-10-17 01:02:15] BAJ2: RequestResults failed no data returned  (err=0 amt=
0)
 [2013-10-17 01:02:15] BAJ1: RequestResults failed no data returned  (err=0 amt=
0)
 [2013-10-17 01:02:15] BAJ6: RequestResults failed no data returned  (err=0 amt=
0)
 [2013-10-17 01:02:15] BAJ33: QueFlush failed no data returned  (err=0 amt=0)
 [2013-10-17 01:02:15] Thread 33 failure, exiting
 [2013-10-17 01:02:15] BAJ2: QueFlush failed no data returned  (err=0 amt=0)
 [2013-10-17 01:02:15] BAJ0: RequestResults failed no data returned  (err=0 amt=
0)
 [2013-10-17 01:02:15] Thread 2 failure, exiting
 [2013-10-17 01:02:15] BAJ7: QueFlush failed no data returned  (err=0 amt=0)
 [2013-10-17 01:02:15] Thread 7 failure, exiting
 [2013-10-17 01:02:15] BAJ1: QueFlush failed no data returned  (err=0 amt=0)

I am guess that it shouldn't stop on que flush. Since this happens reguardless of the zombie units I can't just stop it by asking nicely for it to stop after a number of shares.

Anything I can do to help you find the problem I will be happy to do.

[kano]

Yay windows. At this rate I'll ...  completely deprecate windows support 

... actually expected that ages ago ...

Don't tempt me please it's hard enough to maintain motivation with windows support 

Just sent you and Kano a little M$ Windoze support motivation.

Thanks for your efforts,
Sam

Oh wow! Thanks - very generous indeed
I can very well say the API still works perfectly on windows
I don't suppose you want that 5s MHs added to the summary also?
I'll do it shortly just in case

[-ck]

New version: 3.6.3 - 17th October 2013

Just because I can't stand having a release out that is causing lots of problems, here's a release capitalising on the least worst aspects of 3.6 so far (for windows). Linux users seem fine regardless of which 3.6 release they use


Human readable changelog:

- Rolled back to libusb-1.0.16-rc10 instead of libusbx. This one intrinsically had the least worst incidence of run-over timeouts but had the issue with memory leaks when they're all done manually from within cgminer on windows. So as a compromise, the linux version does all timeouts from cgminer and the other OS versions use libusb's own timeouts and try to cancel transfers if they go beyond the libusb timeouts only. This will not completely obliterate the timeout issues on windows but should ameliorate them. It also should avoid running out of memory on windows due to the intrinsic leaks. Linux users should be blissfully unaffected by any of these issues and just benefit from the better performance/lower overhead.
- Kano added the overall MHS to summary (amazing what a BTC donation can do as an incentive - people take note!)
- Reverted some other internal usb changes that were unhelpful and possibly counterproductive.


Full changelog:

- API add 'MHS %ds' to 'summary'
- Optional lock tracking and stats via the API
- Speed up polling repeat again in usb poll thread and handle async after the
message to disable polling is complete.
- Revert to using timeouts on !linux since libusb leaks memory without them.
- Revert to libusb instead of libusbx