So, latest test results. Nothing to very hopeful, at least to my untrained eye: Started cgminer-lt @10:21, zombie at 11:01. Test ended Started cgminer-nt @11:06, zombie at 12:07. Test ended Started cgminer-et at 12:11. First zombie AMU29 appeared at 12:18 just as I started uploading to Flickr aagin (coincidence?). The offending AMU was replugged at 12:22 and started working again as AMU 34. Two AMU LEDs came on full and 2 zombies appeared in the display at 12:25, AMU 14&16, but AMU 16 started working again. Tis behaviour is new, perhaps? It was removed from the table and reappeared as AMU 35. AMU 14 was still reported as zombie, but there was no corresponding "NO_DEVICE" in the logfile for either of these two. Strange? I tried re-plugging AMU 14 @12:30 but it did not get recognised again (LED came back full on and the zombie remained in the display table). Test ended...  Edit to add logfile links: https://dl.dropboxusercontent.com/u/44240170/logfile-lt.txt https://dl.dropboxusercontent.com/u/44240170/logfile-nt.txt https://dl.dropboxusercontent.com/u/44240170/logfile-et.txtEdit: Just noticed the 3.7.1 release. I'll give it a try. You never know! Thanks for that. 3.7.1 is closest to -et in behaviour. |
|
|
|
It seems no one is interested in external binaries any more, but just in case they are, here is a binary for the knc devices based off the latest cgminer 3.7.0 code. There are no performance advantages for knc devices but there are networking and work scheduling fixes for people that have had issues (eg difficulty connecting to eligius or system stopping work entirely). As per previously, you'll have to ssh into and copy the binary to your device to run it. http://ck.kolivas.org/apps/cgminer/kncminer/cgminerBugfix update to 3.7.1. Same download location. |
|
|
|
|
New version: 3.7.2, 5th November 2013
In the interests of not leaving a relatively unstable release out there, here's a pure bugfix release.
Human readable changelog:
- Fix for crashes on startup and hotplug.
- Fix for hangs doing no further work after a block change.
- Fix yet again scrypt showing a block solve with every highish diff share.
- Try to find a compromise between the various ends of the windows+AMU timeout issue spectrum.
- Write errors will cause a device failure, allowing cgminer to attempt to hotplug them again.
- Icarus based devices will hopefully align on the display with others.
- Fix for short periods of no/idled work on avalon devices due to async restarts with block changes.
- Fix for diff shown on big endian machines
- Fix for building with curses disabled.
- Other low level clean ups.
Full changelog:
- Clean up completely on avalon shutdown.
- Use cgsem timed waits in avalon driver to not miss any queued wake ups to
account for async messages coming during a flush work.
- Statline before is too long on icarus that doesn't have monitoring.
- Different windows+usb combinations respond with varying levels of reliability
wrt timeouts so use a nominal extra 40ms before cancelling transfers that fail
to time out on their own.
- Do all hotplug_process under the write mining_thr_lock
- Fix for opt_worktime on big endian machines.
- Correct set_blockdiff for big endian machines.
- Make sure cgpu exists in the restart threads loop in cases of hotplug etc.
- Treat usb write timeout errors as unrecoverable.
- Transfer errors are filtered out in usbutils now so no need to look for them
in NODEV checks.
- Remove now unused entries from struct cg_usb_device
- Do not double up with checking for end of timeout measurements in usb
read/write.
- Do get_work in fill_queue without holding other locks.
- Initialise usb after all the locks and conditionals are initialised.
- Use only a trylock in flush queue to prevent deadlocks.
- Add a wr_trylock wrapper for pthread rw lock write trylock.
- Scale diff for scrypt when testing for block solves.
- Fix for non curses build.
|
|
|
|
if (cgpu && cgpu->deven == DEV_ENABLED) cgpu->drv->flush_work(cgpu); flush work is not initialized in this case  Updated git. The mining thread shouldn't appear with read lock held so see if that code suffices. |
|
|
|
I have noticed that 3.7 problems during start are caused by
Make calls to flush queue and flush work asynchronous wrt to the main…comit
What happens is that flush_queue is using qlock which might be not initialized from hotplug when there are more USB miners connected
Simple if(cgpu) check is solving that issue for me
That's a very insightful observation, thanks, will investigate further. 10X Con but after your latest changes (rev 6bc691adb26cad59f0598882cb85488f3f5edbe6 1 parent 42b3cf1 ckolivas authored 18 minutes ago ) it is still not working What works for me is: for (i = 0; i < mining_threads; i++) {
cgpu = mining_thr[i]->cgpu;
mining_thr[i]->work_restart = true;
if (cgpu && cgpu->deven == DEV_ENABLED) {
flush_queue(cgpu);
cgpu->drv->flush_work(cgpu);
}
}
Oh I see, thanks. |
|
|
|
HI
I use cgminer 3.7 and the message :
KnC spi: Can not open SPI device /dev/spidev1.0: No such file or directory
I don't use KNC Miner. How can I disable that ?
OS : Archlinux
Thank you
did you compile from scratch? Hi, No I installed cgminer from repo pacman -S cgminer In that case then whoever is maintaining the arch package is enabling things in the default build that {s}he shouldn't. |
|
|
|
Might want to update the subject to reflect new version?
Thanks. Maybe I was subconsciously anticipating the need to go to 3.7.1 soon  |
|
|
|
I know I haven't said it for at least 1-2 versions, but thank you again for your continued commitment to CGMINER. It only seems to get better and better over time.
It's a pity you didn't write a secret "send 0.1% to the author" into cgminer.. you'd be filthy rich by now from all of us mining with it. In all seriousness, perhaps you should put in a command-line switch.. don't make it default, but make it explicit, like --donate-author %
I'd like to add my thanks also, I've had increases in MHSav with every upgrade on my POS avalon. I've been running 3.6.6 for a couple of days, best yet other than the minor OOM issue which I'm assuming is from the itty bitty memory in the wr703. 3.7.0 wouldn't start up though: In any case thanks for your dedicated work, I also think you should add the --donate-author% switch. Thanks. Later avalon firmware set the --lowmem option. I wonder if your particular firmware isn't setting it? If not, try adding it to the extra options anyway. I see you're building firmware yourself which is pretty brave, as I've not been able to generate good firmware in a while myself since breaking my wrt(and replacing it I've not been able to get it stable). A segmentation fault should be an obvious crash in the code though, but unless you can go digging around creating a debug build, I can't really do much about it. In all honesty I give up and plug the usb cable from my avalon into my pc every time I try to build firmware as I don't have time to work on the wrt any more. As for the donation option, believe it or not at the moment I'm too busy to add more features, even if it means that feature would give me donations. I am trying freaking hard to stabilise the code currently, and even though bug reports continue, most of the changes are necessary to do away with legacy issues in cgminer that won't stand the test of time, and changes for upcoming hardware that are essential. EDIT: If I get time I'll try building a binary for the wrt and test it myself but it's quite far down the priority list sorry. |
|
|
|
Did you commit the fix? I cannot find it in the commit history.
I have tried the latest master (tag v3.7.0) from the git repo, and the bug is still there.
Well, no one confirmed whether I had fixed it or not, so I had to run blind. Therefore the bug is still there. Sorry for the misunderstanding. When I posted my report, it was referred to the latest git master (that's why I suggested users to revert to v3.6.6 instead of just pulling the latest commits). Since no related commit appeared after my post, I thought you were working on a fix and you still had to push it to the git repo. My bad, I should probably have been more explicit. Try latest git then please. |
|
|
|
No point testing any of those earlier ones. Yours looks more resistant to being fixed than aigeezer's too. You have lots of problems... and I have nothing new for you to test at this time.
Well I could suggest going back to the code in 3.5.1 - which seems to work flawlessly for me - but I'm not good at dodging flying objects...!!! Seriously, I do appreciate all the time and effort you've been putting into this, and if a solution is not forthcoming, then I can happily stay with 3.5.1 or even 3.3.1 for my particular setup. Last run of 3.7.0 produced one zombie after 2 hours. I came back after 4 hours, so just the one. Logfile here if required: https://dl.dropboxusercontent.com/u/44240170/logfile-3.7.0.txtEdited to correct formatting. No, there are too many changes post 3.5.1 that everything else depends on. In the same way new versions come out for other reasons and need bugfixes, the solution is to fix the current behaviour, not go to the old behaviour. EDIT: What's interesting is that the pattern is the same every time in your logs. One device disappears and then another has timeouts forever more. However it also seems to keep hashing fine based on the fact that your summary shows the hashrate is the same for AMU0 as the rest. EDIT2: Here're the next tests (note this is specifically for your issue now since last report aigeezer's was working) http://ck.kolivas.org/apps/cgminer/temp/cgminer-lt.exehttp://ck.kolivas.org/apps/cgminer/temp/cgminer-nt.exehttp://ck.kolivas.org/apps/cgminer/temp/cgminer-et.exe |
|
|
|
I have noticed that 3.7 problems during start are caused by
Make calls to flush queue and flush work asynchronous wrt to the main…comit
What happens is that flush_queue is using qlock which might be not initialized from hotplug when there are more USB miners connected
Simple if(cgpu) check is solving that issue for me
That's a very insightful observation, thanks, will investigate further. |
|
|
|
HI
I use cgminer 3.7 and the message :
KnC spi: Can not open SPI device /dev/spidev1.0: No such file or directory
I don't use KNC Miner. How can I disable that ?
OS : Archlinux
Thank you
You built it yourself with knc support. Don't do that. |
|
|
|
[snip comments about 'waiting for pool issue'] On further investigation, I've found how this can happen, and have committed a fix for this into git so it should go into the next version. The actual issue goes back quite a way so backtracking versions will not avoid it.
Thanks, heard more comments about people running into it over the weekend from KNC users, who, of course in 0.98 firmware, went to cgminer 3.6.6. by the way, is this the fix: - Use a non blocking connect with a 1 second select timeout when initiating
stratum to allow us to iterate over all IPs returned by getaddrinfo in round
robin DNS pools.
I know I haven't said it for at least 1-2 versions, but thank you again for your continued commitment to CGMINER. It only seems to get better and better over time. It's a pity you didn't write a secret "send 0.1% to the author" into cgminer.. you'd be filthy rich by now from all of us mining with it. In all seriousness, perhaps you should put in a command-line switch.. don't make it default, but make it explicit, like --donate-author % Thanks. No that wasn't the change and it looks like I didn't fix it anyway and it's a separate issue based on post release bug reports. More coming soon... |
|
|
|
Is there anyway to change the layout. Currently my 18 erupters show up like this: (Marked and pasted from the command prompt; no formatting changes made, except for adding a '.' in the brackets to avoid a forum post formatting issue) But all 18 are crunching away: (5s):5.942G (avg):5.883Gh/s | A:252 R:0 HW:4 WU:76.0/m I assume you're on windows if you can't resize your command prompt window. There is compact mode which summarises them only, and you can change your command prompt window by right clicking on the window frame and choosing settings and change the default to more rows. |
|
|
|
The latest cgminer doesn't work at all (not even for block erupters, and yes, tried without them plugged in also) it just says "failed to initialise" / "you need to install a WinUSB driver for - BF1"
I have tried versions 3.7, 3.6.6, 3.5 and 3.4.3, to no avail
Well the instructions are pretty clear. Cgminer won't work till you install a winusb driver for any USB devices. The instructions are plastered all over the README and ASIC-README files. |
|
|
|
Thank you for the generous comments in the changelog *blush* Ran 3.5.1 overnight, no problems. Skipped "lol", "lmfao" etc as suggested and started 3.7.0 this morning, without logging. Unfortunately got a zombie after no more than a minute. Re-plugged it and went off for breakfast. Came back to find a new zombie. I've now made a clean start with 3.7.0 with logging. Broadband has been up and down, which it has coped with, so I'll just let it run and see what happens. I assume it's of no benefit to go back and test "lol" etc.? No point testing any of those earlier ones. Yours looks more resistant to being fixed than aigeezer's too. You have lots of problems... and I have nothing new for you to test at this time. |
|
|
|
It seems no one is interested in external binaries any more, but just in case they are, here is a binary for the knc devices based off the latest cgminer 3.7.0 code. There are no performance advantages for knc devices but there are networking and work scheduling fixes for people that have had issues (eg difficulty connecting to eligius or system stopping work entirely). As per previously, you'll have to ssh into and copy the binary to your device to run it. http://ck.kolivas.org/apps/cgminer/kncminer/cgminer |
|
|
|
Did you commit the fix? I cannot find it in the commit history.
I have tried the latest master (tag v3.7.0) from the git repo, and the bug is still there.
Well, no one confirmed whether I had fixed it or not, so I had to run blind. Therefore the bug is still there. Sorry for the misunderstanding. When I posted my report, it was referred to the latest git master (that's why I suggested users to revert to v3.6.6 instead of just pulling the latest commits). Since no related commit appeared after my post, I thought you were working on a fix and you still had to push it to the git repo. My bad, I should probably have been more explicit. In that case I suggest scrypt miners stick to 3.6.6 (not 3.6.6-1 or later). |
|
|
|
Did you commit the fix? I cannot find it in the commit history.
I have tried the latest master (tag v3.7.0) from the git repo, and the bug is still there.
Well, no one confirmed whether I had fixed it or not, so I had to run blind. Therefore the bug is still there. |
|
|
|
|
Show Posts
