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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
New version: 3.6.2, 17th October 2013
New release, 2 new library versions. Finally gave up and moved to libusbx which works less bad on windows with the asynchronous code cgminer uses. Also a new jansson in tree full build.
Human readable changelog:
- New version of jansson has some minor bugfixes, but more importantly now is built properly from within the build tree such that changes to configuration will rebuild it. Alas this makes ./configure now take even longer.
- Change from libusb-1.0.16-rc10 to libusbx-1.0.17. libusb on windows with asynchronous transfers had memory leaks galore and eventually would fail. libusbx does not have this problem, but some people are reporting write timeout issues with it on prolonged use. Linux has no such issues.
- Updates to the way usb work is "scheduled" which might help decrease the risk of timeouts on windows.
- Fixes to the shutdown routine that would get stuck waiting for usb transfers that would never be able to complete.
- Changed the driver model in icarus devices to a slightly lower overhead newer code.
- BF1s weren't showing any WU when hashing, this has been fixed.
- Some earlier BFL SC minirigs were not being properly detected due to inconsistencies in the firmware responses.
- Workarounds to the ./autogen stage of building when people build from git. Note this still does not fully work on macosx but 'autoreconf -fi' should be enough to have the same effect for now.
Full changelog:
- Remove unused components of jansson
- Remove unused parts of libusb
- Work around older libtoolize that fails without top ltmain.sh not being
present during autogen
- Fix open coded use of autoreconf in autogen
- Update jansson to only build parts we require and suited to our build
environment.
- Initial import of jansson-2.5
- Prevent further USB transfers from occurring once the shutdown signal has been
sent to prevent transfers getting stuck and libusb failing to shut down.
- Make the USB polling thread poll every second to potentially aid longer
timeout transfers.
- Set device_diff on work in get_work to not be missed with drivers that use
get_work directly.
- Convert icarus driver to hash_driver_work model.
- bflsc - also allow ' 0' in DEVICES IN CHAIN
- bflsc - allow a 0 in DEVICES IN CHAIN
- Add needed EXTRA_DIST for libusbx.
- Update libusbx configure.ac changes.
- Revert libusb Makefile changes from going to libusbx.
- Fix trivial libusbx warnings.
- Convert libusb-1.0.16-rc10 to libusbx-1.0.17
|
|
|
|
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 [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. 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. |
|
|
|
Sorry for bumping old topics but I have similar question. Can I open 2 CGminer and have one of them GPU-thread 1 and the other GPU-thread 2?
Thanks
Yes |
|
|
|
Won't really help. The debug version only does something if it crashes.
Oh. Thought you have some other trickery in there :/ I wish. The debug builds in there are based on 3.6.1 currently so they will likely have the memory leak bug inherent in the included libusb. That said, sometimes strangely issues go away on debug builds due to a bug showing up only with optimisations enabled (debug builds have no compiler optimisations). |
|
|
|
linux/win/osx/mip/r-pi 3.6.1 + RK3066 (ug802 etc android linux stick versions...) I have been running for a week with 3.5 without errors on UG802 mkII with very low overhead under 2.5% CPU I am going to make UG802 my main mining platform because it only chews around 6 W and also serves multiple other purposes like web/development & backup server. New RK3188 is on the way and might give this newest version a shot too. Wondering should I upgrade to latest because 3.5 seems robust as a rock on rk3066. I'll put some beer pizza money on the way when my wallet updates. Thanks to BFL don't expect to get drunk overfed though. Great work! Probably wait. There will likely be a 3.6.2 just around the corner, though so far 3.6.1 is kicking goals on linux. |
|
|
|
ok thanks for the help  i would read the readme file but i dint understand about 90% of it as its not the best layout in the world and not the best version of English... after reading the ASICS part i decided its simpler and easier to ask Feel free to rewrite it. At least it IS all documented. If it were 3 lines of useless crap you'd understand it but be able to do nothing. Mining is non-trivial and I wish people wouldn't complain about too much documentation. Not the best version of English? Sigh... |
|
|
|
I replaced cgminer-nogpu.exe with the one in the above temp folder. I get ever increasing lines of: AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT Odd. What hardware are you using? I got this after a couple of hours too. Win cgminer-nogpu 3.6.1, with 1 BFL SC 60GHz Now trying the debug version you put up. Won't really help. The debug version only does something if it crashes. |
|
|
|
Should 3.6.1 be working? I've had it on for maybe 1 Minute with no errors showing on windows 7.
I'm using block eroupters if that makes any difference.
Current one runs out of memory eventually on windows. The binaries in temp/ are currently the best 3.6.1 working ones for windows. yeah it just hit. it was running fine since this morning and now I got it. Only difference I did was running bitcoin-qt ver 8.5. Does whats happening with the version of lib mean you found its peak  . Nah, just that it found a bug in it. |
|
|
|
I replaced cgminer-nogpu.exe with the one in the above temp folder. I get ever increasing lines of: AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT Odd. What hardware are you using? |
|
|
|
Btw, it ran all night. So far so good.
In that case it's definitely better. We may have to finally move libusb to libusbx then. |
|
|
|
Should 3.6.1 be working? I've had it on for maybe 1 Minute with no errors showing on windows 7.
I'm using block eroupters if that makes any difference.
Current one runs out of memory eventually on windows. The binaries in temp/ are currently the best 3.6.1 working ones for windows. |
|
|
|
wouldn't see so bad to report if git hub had report bugs option for cgminer on. then all the things you find wouldn't get buried over. This post is at least 600 pages deep   . People were using it for support instead of bug reporting. |
|
|
|
Updated my cgminer, Got it on a different hub with just one BE right now. It's running smooth so far, I'll check it in 30 minutes and add another BE. This version of CGminer may have fixed the timeout issues I had before. I may try this on my tablet later on and see if that fixes I had on that too. Very promising.
Update: Added another BE, Spat out LIBUSB errors after a while. Fun.
Which libusb errors? |
|
|
|
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)
That's the one I got too. M Did either of you try the experimental binaries I listed above? 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/ |
|
|
|
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
Well that's nice 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.
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/ |
|
|
|
With this new feature in 3.5.1: - If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.
Is there a way to adjust the switch back timing? When mining Altcoins on a multi coin pool like Middlecoin or Hashcows, 5 minutes is way too long since fail-over gets triggered upon switch of coin. So if the pool is mining a certain most profitable scrypt coin for a round of 10 minutes only, then half that is lost because of this new feature! The ideal would be to set it down to 1 minute or even just 30 seconds. Repeating this since it's a feature carried over into 3.6.1. Any chance we can adjust the switchback time from failover? Sorry but code designed just for altcoin mining takes absolutely last priority. |
|
|
|
|
Show Posts
