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

Nice work guys.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-cwa16.exe
http://ck.kolivas.org/apps/cgminer/temp/cgminer-chop1.exe

LOL, sweet.

Sorry if you'd like to have the good news to a minimum but I just got 2 more eroupters and other than having to unplug and replug in they were recognized they were recognized without a full pc restart after it installing drivers with the new zadig. I was so happy I didn't have to unplug every device to get it to start seeing the new devices.

I don't expect to test the driver unplug method again unless I find a great deal on a hub to expand my small herd of eroupters but I just thought I'd mention I noticed it with 3.6.6 played nicer than previous version with zadig and WinUSB.

Try redownloading, kano fixed that seconds after the first time I uploaded it. The WTF is something I put there myself.

Yep, The error will always be logged at level ASSERT with the call stack.

log.wtf: What a Terrible Failure: Report an exception that should never happen.
http://developer.android.com/reference/android/util/Log.html#wtf%28java.lang.String,%20java.lang.Throwable%29

No go, I get;  WTF RDLOCK ERROR ON LOCK!  errno=0 in driver -- klondike.c klondike_get_replies<> :971

Same here, so far - no anomalies after almost two hours. I haven't tried pps32 yet.

Edit: Spoke too soon, AMU7 went zombie about 3 hours in. I'll switch to pps32 now.

Edit: pps32 failed early. I watched an LED stay on and saw the hashrate for AMU12 creep down to zero after only about 8 minutes. Replugged it and it got reassigned to AMU13 and the hashrate crept back up. The run continues.

Edit: AMU10 went zombie under pps32 after about 1.5 hours. Replugged OK and it got reassigned to AMU14.

Edit: After 3.3 hours total (unattended for a while) I found AMU9 had gone zombie and AMU7 had gone to zero. I'll keep the run going.

Two test runs with cgminer-pps32:

1st run: Within 10 minutes, the LED for AMU27 came on steadily and the hash rate slowly decreased down towards zero, then jumped up and started decreasing again. The LED was lit all the time.  Soon after, a different AMU (AMU16) was reported as zombie. Test stopped.

Restarted the 3 10-port hubs (off/on). Didn't touch the 4-port hub as there were no errors relating to it (normally I restart them all just to be sure).

2nd run: Only 30 devices initially detected on-screen, but all 34 devices initially observed "flashing" processing shares.  Missing devices detected one-by-one and appeared in the on-screen list, but the process took probably a minute or so?  However, the first zombie appeared after about 5 minutes, so I stopped the test.

Logfiles (without --debug):
 https://dl.dropboxusercontent.com/u/44240170/logfile-pps32-1.txt
 https://dl.dropboxusercontent.com/u/44240170/logfile-pps32-2.txt

So, "chop10" still looks the most promising from an end-user point of view, but for mining stability it doesn't appear to match 3.3.1, unless the test was just very unlucky of course.

So I have tested the 3 builds below, and out of the three, chop10 seems the most promising.  I stop testing usually as soon as a zombie appears, since I can run version 3.3.1 for days on end without problems.

cgminer-cwa8
One AMU LED came on after 30 seconds into the test.  It stayed on for about 2-3 seconds then went off again. I don't know the AMU number, but no messages appeared on screen and it seems to have recovered OK. No zombie. However, the first zombie appeared after 3 minutes (AMU33), followed by loads of LIBUSB_ERROR_TIMEOUTs from AMU0.  Curious as to why AMU0 should be the one to give continuous timeouts when it seems to be working OK?

cgminer-chop8
A zombie (AMU24) appeared after 11 minutes,  followed by an error timeout from AMU23 then loads of repeated timeouts from AMU0.

cgminer-chop10
First zombie after an hour and 10 minutes:
 AMU 13:                 | ZOMBIE/332.2Mh/s | A:330 R:0 HW:10 WU: 4.4/m
Followed by continuous timeouts from AMU 0.

Instead of stopping the test, I unplugged the zombie AMU (AMU13?) and observed that timeouts from AMU 0 stopped, then I replugged (AMU13?) in at 11:33 and it started working as AMU34.  Returning later, there were 2 zombies reported, but one of those was in the same position as AMU34 - which was AMU13 - and no mention of AMU34 in the table. Is this to be expected, or something strange? Full info in logfile.

Logfiles here (without --debug) if required:
 https://dl.dropboxusercontent.com/u/44240170/logfile-cwa8.txt
 https://dl.dropboxusercontent.com/u/44240170/logfile-chop8.txt
 https://dl.dropboxusercontent.com/u/44240170/logfile-chop10.txt

Ah, now I see we have another candidate!  On to try cgminer-pps32 next... 

Hrm..

I have a new lead...

http://ck.kolivas.org/apps/cgminer/temp/cgminer-pps32.exe

Chop8 test results: elapsed time 9.5 hours, mainly unattended, led to three failures. Two are zombies and the third reports a zero hash rate and has the LED on solidly. The former "suspect" AMU was not one of the three. Neither was its former location on the hub.

I'll test chop10 shortly.

I'm in the process of completely reworking my mining rig and space for the the winter.  Once I get my configuration stabilized I'll be chiming back in.

For the time being I've been using 3.4.3 fairly reliably.  It will have a problem once in a great while, but never a zombie since I got my hubs daisy chained to their liking.  The new 49 port hub seems reliable too, but I'm not up to the 40's yet, baby steps.
Thanks,
Sam

Here's an updated build (untested) containing the latest klondike support  build into the windows binary (do not use --enable-klondike16, that's a BUILD option, not a RUN option)

http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe

Oh don't worry, I'm sticking around!  I admire your dogged determination ckolivas, and I think/hope that I would be the same if it were my software under test.  I'll try the remaining 3 builds today and post back.  There's one advantage if you can call it that, in running 34 erupters - any faults show up quite quickly      Later...

I would only use the following.  -0 http://stratum.btcguild.com:3333 -u username - p password
--enable-klondike16 is only for when building the cgminer. I would make sure you use a version that its enabled on. Not sure what version it starts on but hopefully that helps. Also --usb KLN:3 would only be if you wanted to limit it to Klondike boards and 3 of them. I suppose you want to limit it to 3 Klondike boards.

Any update for the settings in cgminer for Klondike K16 mining unit? Some of the guys have got them running in Ubuntu but I'm running Win7. I've tried yet I'm missing something.
I tried: -0 http://stratum.btcguild.com:3333 -u username - p x -- usb KLN: 3 --enable-klondike16

I'm more worried about losing my valuable victims testers before we resolve anything.

Unofficial Mac binaries for 3.6.6 now posted.

cgminer for Mac OS X 3.6.6 (direct download link)
http://spaceman.ca/cgminer (website)

I haven't yet heard if this fixed BFL Jalapeños on Mac OS X 10.9, still awaiting feedback from Mac users.