May be just a wierd 2 bugs but I found that if I incorrectly forgot to save my shortcut right it opens to older folder versions I set and saves config there even though I'm opening 3.6.4. My second I found because cgminer doesn't like strange characters and won't open if they are in the config file. I was trying to set up bit minter as an alternative to another pool and since bit minter looks like it uses tcp instead of http they both get printed at front and leave just as" http://tcp://mint.bitminter.com:3333" plus a few starlike characters in between the protocols the first time it saved. Future bug fixes maybe? Um, you do not use tcp by itself anywhere. You're probably thinking of stratum+tcp:// and http:// is implicitly tcp, so your syntax is wrong. |
|
|
|
3.6.4 seems really stable and works great thanks a lot for your hard work
Great thanks for the feedback  When reporting back feedback like this can you please give a quick summary of what OS and mining hardware you're all using as well? |
|
|
|
On 3.5.1 I can run it without killing it as often as 20 minutes and all I get for errors are the following. [2013-10-19 03:19:15] Accepted 03db0146 Diff 66/32 BAJ 0 pool 2
[2013-10-19 03:19:19] BAJ 6 usb read error: LIBUSB_ERROR_IO
[2013-10-19 03:19:19] BAJ6: QueJobStatus failed (err=-1 amt=0)
[2013-10-19 03:19:20] BAJ6: incorrect result count 1 (OK:QUEUED0x00) will try 3
(OK:QUEUED0x0aINPROCESS:10x0aCOUNT:10x0aBAA5E374CDE767253D2FE7708327EEAF699F92D
2D92550EC4A4DADEB4962B59A,543E943752624E7819100AB6,1,3351D8020x0aOK0x0a0x00)
Hmm ok you did get IO errors previously as well. The difference is the newer version made them seen as fatal. Well I'll try to emulate the old behaviour and maybe even try resubmitting the transfers to even improve on the old behaviour. I've updated git master to emulate the old behaviour for now where the errors were non fatal. EDIT: BTW IO errors still suggest there is something hardware wrong in your setup, dodgy cable, connection etc., even if it works most of the time. |
|
|
|
No errors in the new version for me Great Well after this frantic pace of development, I'm going to take a little breather and concentrate on some other areas. I think the code is quite stable but needs a lot more people testing it, so I will leave the "stable version for windows/osx" recommendation at 3.5.1. There will be some downtime on my server this weekend so grab your downloads now even if you don't plan to move to the new version immediately. |
|
|
|
I don't see why people give a shit if their _daily_ income has only a 1% variation. Jesus Christ, do you all have mining hardware setups whos output exactly match the cost of your daily heroin fix or something?  There are very few small to medium size businesses that have variation against expected within 1% even on a timescale of months. I mean, sure, if the bandwidth isn't a concern and the pool doesn't care to charge people based on their actual load, then by all means, why not lower. But caring about a daily 1% variation is just further confirmation to me that y'all are crazy. Wait wait wait, you're calling people who spend $5000 on a money making machine that in its entire lifetime will never make $3000 or so crazy? You're crazy. |
|
|
|
I notice 3.6.4 came out while I slept. I have some logging that I did on 3.6.3 because having cron kill cgminer off every 20 minutes seemed excessive even for a raspberry pi. First I have 509 lines of cgminer trying to figure out what device its talking to. All 509 lines precede probing for an alive pool. I have 9 devices. Each check goes like this As I see it that means the device ID didn't match up to the expected id. The non matching ones should be a keyboard or one of 4 hubs. Next we have some accepted work like this. That will be unlikely to have more then things I don't understand. I assume by err 0 there is no error. Then this happens. [2013-10-18 01:49:54] BAJ 4 usb read err:(1) **UNKNOWN**
[2013-10-18 01:49:56] BAJ 5 usb read err:(1) **UNKNOWN**
[2013-10-18 01:49:59] BAS 0 usb read err:(1) **UNKNOWN**
As errors still happen on 3.6.4 built from git I don't think the bug is smashed. Though it seems I can now restart every 30 minutes instead of 20 so it is a bit better. 1. Normal for lots of looking for new devices to occur. The more usb things you have plugged in and the more drivers you compile in, the more looking will occur. 2. All looks fine. 3. Error 1 is a failed transfer - I plan to add more informational output than just unknown in the future. There is no way to recover from that and it suggests a communication problem. Meaning... I'm not sure this is a code problem? |
|
|
|
That's a good point, but bear in mind I'm being paid professional rates from the other manufacturers in the still-in-design phase who will then be supplying me with prototypes and finally real hardware which really puts to shame the "offer hardware and code after the fact" approach.
\em crossing fingers that's Cointerra. From another thread: For what it's worth, CoinTerra have been talking to me about their MCU protocol and I have been working on a preliminary driver model for them, so they have most definitely not disappeared. I suspect they're approaching the communication via forum aspect differently to other manufacturers.
|
|
|
|
I will be testing v0.9.6 soon. However My 3rd Jupiter restarted cgminer 6hrs into my test. I took steps to swap out the intake fans on Jupiter 3 as it performances similar to Jupiter 1. I hope this will solve the cgminer reset.
Do you have a Jupiter 2 then as well? Why did I suddenly think of 'Lost in Space'? |
|
|
|
That's nice to see their sauce at last. Furthermore, KFC have finally decided to engage us (well just me) and are sending me a unit. Unfortunately for KFC users, I am currently being paid by other manufacturers to work on their drivers, so modifying the KFC driver will go lower priority than those other manufacturers, but I will get around to it eventually. [sic]
In hope it pushes the priority a little I'd like to mention that buyers of KFC's 'ultimate boxes' will donate for improvements made on KFC sauce  That's a good point, but bear in mind I'm being paid professional rates from the other manufacturers in the still-in-design phase who will then be supplying me with prototypes and finally real hardware which really puts to shame the "offer hardware and code after the fact" approach. |
|
|
|
3.6.4 works great on Macs again, thank you!  There are two minor bugs, but they don't affect mining. The first one occurs during building, where I must now explicitly use "--disable-adl" whereas I didn't need to in 3.6.3. ADL isn't used on the Mac, so it's no loss, but since it is a non-default option it's a caveat Mac users will need to remember if they want to successfully build it for 3.6.4. Here is readout from make: In file included from ./sha2.h:36,
from cgminer.c:52:
./miner.h:127:30: error: ADL_SDK/adl_sdk.h: No such file or directory
In file included from ./sha2.h:36,
from cgminer.c:52:
./miner.h:288: error: expected specifier-qualifier-list before ‘ADLTemperature’
cgminer.c: In function ‘write_config’:
cgminer.c:4393: error: ‘struct gpu_adl’ has no member named ‘overtemp’
cgminer.c:4396: error: ‘struct gpu_adl’ has no member named ‘targettemp’
make[2]: *** [cgminer-cgminer.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2 Again, using "--disable-adl" solves it. The other bug(?) occurs when quitting cgminer, the following messages are output. [2013-10-18 11:27:04] Received kill message
[2013-10-18 11:27:05] AMU0: Comms error (rerr=-4 amt=0)
[2013-10-18 11:27:05] Thread 2 failure, exiting
[2013-10-18 11:27:05] Failed to read errno=0 in usbutils.c usb_resource_thread():3737
[2013-10-18 11:27:05] Shutdown signal received. The "usbutils.c" error (4th line down) I think is atypical. Neither of these affect usability of the program. Thanks for the great update! Great, thanks for confirming testing and providing builds. The failed to read message is fine on shutdown. The reason is macosx doesn't support unnamed semaphores and I built a custom structure and set of functions to imitate them on OSX. During shut down the structures are being torn down so don't work at some stage and that's what you're seeing. See: http://ck-hack.blogspot.com/2013/09/unnamed-semaphores-and-pososx.htmlNot sure about the ADL issue. Weird since I didn't really touch that code between .3 and .4 (Try 'autoreconf -fi' first if you're building from git) |
|
|
|
Raspberry Pi still crashes after some minutes.
Nothing in logs, just a complete freeze.
hmmm. got 27 block errupters running on raspi with 3.6.4.... works pretty nice here! -> http://imgur.com/a/j5vTtSweet |
|
|
|
|
New version: 3.6.4 - 18th October 2013
Thank you for your patience through this rough ride of changes in 3.6. Hopefully we're close to a stable release on all OSes now. There are actually some other bugfixes in this one besides more libusb massaging.
Human readable changelog:
- Found the source of the memory leak on windows AND the source of the too many files open error on OSX. Both have been rectified, and fully asynchronous transfers are used on all OSes.
- Fixed numerous causes of problems on shutdown.
- Fixed some BFLSC parameters not being read properly.
- Fixed the problem of lost communications and lots of errors on devices on shutdown and possibly unsuccessful shutdown/reset.
- Fixed a bug where bogus work was being generated at extreme hashrates.
- Decreased the overhead in generating more work for queued devices (eg BFLSC).
- Fixes to klondike driver
Full changelog:
- Fixing the memory leak for remaining semaphores means we can go back to using
async transfers on other OSes with our own timeout management again.
- Use the forcelog function on shutdown to cope with indeterminate console lock
states due to killing of threads.
- Add a forcelog variant of applog which invalidates any console lock to force
output.
- Send pthread_cancel to failed completion_timeout that has timed out.
- Simplify queued hashtable by storing unqueued work separately in a single
pointer.
- bflsc use getinfo chip parallelization if it is present
- bflsc - fix brackets so [Chips] isn't always null
- Remove unused variables.
- Use cgcompletion timeouts for the unreliable shutdown functions on kill_work.
- Fix cgcompletion return code and free on successful completion.
- Provide a cg_completion_timeout helper function for unreliable functions that
takes arbitrary functions and parameters and reliably returns.
- Perform sync transfers on shutdown to allow final transfers to complete.
- Destroy cgsems used after transfers to not leave open files on osx.
- klondike rewrite work control
- allow __work_complete() access
- miner.h allow devices to tv_stamp work
|
|
|
|
just saw this right now at kncminers homepage: That's nice to see their sauce at last. Furthermore, KFC have finally decided to engage us (well just me) and are sending me a unit. Unfortunately for KFC users, I am currently being paid by other manufacturers to work on their drivers, so modifying the KFC driver will go lower priority than those other manufacturers, but I will get around to it eventually. [sic] |
|
|
|
They all seemed to come back up when I replugged them. I was hoping you found a way to catch it and stop calling the device when it thought I was out of memory and clean the memory out. I'm going to run it for a few hours and see what happens. I hope nothings going bad   .... The idea is that it isn't supposed to run out of memory instead. |
|
|
|
Hey, 3.6.3 just had a memory error again  . I was able to close cgminer by pressing q but still ended up closing and moving back to 3.5.1  It ran for what seemed all night and then I had to close it for whatever reason and I saw the no memory flickering in my screen  . I hope you can eventually find a work around or permanent fix for this and make it "pretty" again  [without requiring the need to dump windows]. Woah woah, believe it or not this is good news (I think). I have an idea, and will post some experimental exes again shortly. They're up in the usual place: http://ck.kolivas.org/apps/cgminer/temp/Just died about now. 5-6 devices showed as sick and one as zombie. cgminer had a caption trying to restart. Apparently it didn't. I did try to back run to 3.5.1 and now it doesn't recognize 2 devices saying incorrect driver. I'm going to pull them in the morning and pop them back in then restart. Thanks for testing. I'm going to be brave and say this is unrelated since it's a totally different type of failure, suggestive of hardware failure, perhaps usb perhaps heat. Once you get them going again could you please retry the experimental exe you downloaded? |
|
|
|
I just need the no-gpu file I use right?
I let you know in the morning if I don't awake to errors. At least the eroupters go bright green when then poop out.
Yes, just replace the exe you normally use with the equivalent one from in there. Thanks. |
|
|
|
Hey, 3.6.3 just had a memory error again . I was able to close cgminer by pressing q but still ended up closing and moving back to 3.5.1 It ran for what seemed all night and then I had to close it for whatever reason and I saw the no memory flickering in my screen . I hope you can eventually find a work around or permanent fix for this and make it "pretty" again [without requiring the need to dump windows]. Woah woah, believe it or not this is good news (I think). I have an idea, and will post some experimental exes again shortly. They're up in the usual place: http://ck.kolivas.org/apps/cgminer/temp/ |
|
|
|
Hey, 3.6.3 just had a memory error again . I was able to close cgminer by pressing q but still ended up closing and moving back to 3.5.1 It ran for what seemed all night and then I had to close it for whatever reason and I saw the no memory flickering in my screen . I hope you can eventually find a work around or permanent fix for this and make it "pretty" again [without requiring the need to dump windows]. Woah woah, believe it or not this is good news (I think). I have an idea, and will post some experimental exes again shortly. |
|
|
|
I've tried on my Mac build environments and while I can compile and launch cgminer just fine, as well as GPU mine, when attempting to use a USB-based Block Erupter I get the following message and cgminer subsequently quits. Failed pipe errno=24 in usbutils.c init_usb_transfer():2215 It looks as though it is perhaps able to do a brief moment (before the first poll?(?)) of hashing, as sometimes I get an accepted share out from it and sometimes not, as shown on the "Summary of runtime statistics" output after cgminer quits. The last successful version for me on Mac is 3.5.1. I've tested 3.6.1 and 3.6.2 and both generate the error. cgminer is built entirely from the included source, no other libs used. Using "--usb-dump 0" and "--verbose" provides no additional details. Please let me know if I can help further! Thanks for the new version! I'm getting this same error on Mac in the latest cgminer version though, 3.6.3. I may try to play around with shoehorning in other libusb versions to see if I can get one working that way. Ok I think I know what this is and it's not libusb. Will work on it. EDIT: Try latest git please. |
|
|
|
[2013-10-17 10:02:15] BAJ33: QueFlush failed no data returned (err=0 amt=0)
[2013-10-17 10:02:15] Thread 33 failure, exiting
[2013-10-17 10:02:15] BAJ2: QueFlush failed no data returned (err=0 amt=0)
[2013-10-17 10:02:15] BAJ0: RequestResults failed no data returned (err=0 amt=
0)
[2013-10-17 10:02:15] Thread 2 failure, exiting
[2013-10-17 10:02:15] BAJ7: QueFlush failed no data returned (err=0 amt=0)
[2013-10-17 10:02:15] Thread 7 failure, exiting
[2013-10-17 10:02:15] BAJ1: QueFlush failed no data returned (err=0 amt=0)
got same error as version 3.61 with win 8
Is this on shutdown? If so, I know about it thanks. EDIT: If you're building from git, try latest git master. |
|
|
|
|
Show Posts
