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

OK, that's cool.

I'm guessing you already looked in the windows-build file?

I'll just shut up now.
Good Luck,
Sam

The pre-compiled exe's work fine, but it is open source and I like to compile my own for a number of various reasons.

The precompiled Windoze binaries don't work?

Hi Guys,

I am re-compiling on Windows to get ready for some Bitfury's that should appear soon but I have run into problems with make. I can successfully compile and run cgminer versions up to 3.3.3 but after that all versions to 3.5.1 consistently fail with

"ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."

There are a number of fixes around the Interweb but I would rather use the same fix that you guys must be using to build the exe's. I am using the same versions of mingw, gtk, etc as per the windows build doc and follow the guide without problems for versions to 3.3.3, all builds are clean onto a fresh Win 7 VM.




As an aside I am also noticing differences in the dll's included in the exe distro against those required from the windows build doc, not a biggie but something that needs to be added to a tidy up list at some point.

I had a different issue with 3.6.1 that I haven't seen before.  I'm running win7-x64 with 9 BEs (no GPU) and when I got up this morning, cgminer was locked up (no errors showing in the window, and I forgot to note the run duration before windows reported the app had crashed).  I went back to 3.5.1 for now, and will try the test code when I get a chance. 

I'm also running a cpu miner in one window for SRC, and cgminer 3.3.1 to drive the GPU on a script coin (it ignores the BEs), so there may be some conflicts there (even though 3.5.1 runs without issue - well, the timeout errors, but those done seem to affect performance too much).  Also, another box running 3 BEs on 3.6.1 (win7-32) did not have the same issue.

Just an info report...

I updated those files from last night and my BFL 30gh miner has been running without the error.


WolfSkill

Hi,

I'm currently mining with a BFL Jalapeno and CGMiner, and am also waiting for some BlueFury USBs to arrive. Will I be able to run both sets of hardware on the same box with one instance of CGMiner?

Cheers

Btw, it ran all night.  So far so good.

Trying it now.  I'll let you know if it crashes.  Unless I'm asleep by then.

Edit: BTW, I just downloaded cgminer-nogpu.exe and libusb-1.0.dll and dropped them in the 3.6.1 folder.  Is that good enough, or do I need all the files?

Did either of you try the experimental binaries I listed above?

That's the one I got too.

M

In case it helps you.  I just got a LOT of this on the newest version after running for a few hours:

[2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:37] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:37] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: Error: Request temp invalid/timed out (0:-11)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestResults failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM
 [2013-10-14 20:55:38] BAL0: RequestQueJob failed (err=-11 amt=0)
 [2013-10-14 20:55:38] BAL 0 usb write err:(-11) LIBUSB_ERROR_NO_MEM

Well that's nice

And FFS LOL windows. Always with the new and exciting modes of failure. This suggests a memory leak within the windows specific part of the libusb code. Anyway now that timeouts are managed differently it means we can try libusbx instead of libusb, so I'm putting up some testing binaries that use it. Please try them, but I'm not holding much to hope.

http://ck.kolivas.org/apps/cgminer/temp/

Fair enough... better than a flat out "no" unless that's what this is.

That said, failover switchback timing doesn't just have to be an "Altcoin" issue.  That was just a symptom.  Making it defeatable so that it can use the previous behavior of switching back to primary pool once that pool is Alive would work.  Either way, just putting it out there.

Sorry but code designed just for altcoin mining takes absolutely last priority.

Repeating this since it's a feature carried over into 3.6.1.

Any chance we can adjust the switchback time from failover?

3.6.1 isn't working for me.  (win7x64 - 33 usb block erupters).   I let it run for a while, then it stopped mining, repeatedly saying something like USB write error_no_mem.

I tried to copy/paste the error but lost it.  I can get it again if need be.

M

i'm running 24 AMU's on a raspberry pi. cpu load is down to 23-25% now with 3.6.1. had about 60% cpu load on 3.5.1 :-D

+100
works fine - finds them as quick as they used to .
excellent ;-p

Ok, let's try again. 3.6.1 is up now (keeping the old announce but editing it since so little has changed). This should fix things.