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

Hi guys, i'm running CGMiner under Windows 7.
I have 1 Bitburner Fury and 6 USB Erupter
With command i must use to tell CGMiner to use Only Bitburner Fury or Only 6 Usb Erupter?

Thank you 

3.8.0. working fine for me on Xubuntu 12.04 64bit

Less HW errors too 

3.8.0 doesn't return anything for me - I get:

[2013-11-10 09:31:14] FAIL: USB get_lock not found (4:1)
[2013-11-10 09:31:14] FAIL: USB remove not already in use (4:1)

I get this on both an win7 box and a win8 box on both usb2 and usb3 ports. (the 4:1 reference changes with the port used) I suspect it has to do with the usb driver (zadiag), but not sure.

3.7.2 does the same sometimes, though I haven't checked all combos of it yet.

Currently sticking with 3.6.5 for my BEs

Hmmn, 3.8.0 won't work for me. Nothing initializes correctly and various error messages scroll by. The BFL unit fan stays at idle and the AMU LEDs stay on - no hashing by anything. I'll look more deeply when I get a chance - the problem may be on my end. Meanwhile, I'm back to 3.7.2 "ymmv" version, which is working well (3 day run before I took it down to try 3.8.0).

Of possible significance, I've done all my prior testing using the cgminer-nogpu executables so this is the first time I've run cgminer.exe directly.

Much better than 3.7.2, it ran strong for 4 minutes before the usb errors this time.   

Don't know if you or anyone else is testing on avalon but wondering if you're seeing the same or if it's an issue with my tplink or controller.   

http://pastebin.com/bGQt7c38

New release: Version 3.8.1, 10th November 2013

GPU mining in any form is gone. Long live GPU mining (see previous post). New hardware support in this release and massive change with removal of GPU mining, but only bugfixes to the remainder of the code so to existing users this should be a safe upgrade, in keeping with even number releases sounding more stable.


Human readable changelog:

- Remove all GPU code.
- Driver for Black Arrow Bitfury hardware (for use on RPi)
- Updates to make USB writes more reliable. Should help more on windows than anywhere else.
- Slight improvements to the blue and redfury drivers will decrease duplicates at startup, lost work across block changes, and will now show hardware errors - NOTE the hardware errors are not more than before, they simply weren't being reported before.
- Numerous tweaks to improve Avalon behaviour (possibly still problematic on wrt hardware but works better on PC).
- Fixes to prevent Avalons from hanging rarely on block change.
- Low level clean ups, bugfixes and preparation for more driver code.


Full changelog:

- api update version to 2.0 and remove GPU form API-README
- Remove now unused scrypt files.
- api.c remove all GPU/gpu references and correct code as required
- Rudimentary removal of GPU OpenCL and Scrypt features from api.c
- Reorder configure alphabetically for devices to compile and fail if no support
is selected to be compiled in.
- BaB update/format some comments
- BlackArrowBitfury early GPIO V1 driver
- Fine tune the reading of results in bitfury driver to not lose any across work
restarts or corrupt due to store results not parsed during restart.
- Send a zero length packet at the end of every usb transfer on windows in case
libusb internally has batched them into one maxpacket sized.
- Framework for ntime rolling, keep looking for OP_USB_INIT replies when other
packets received
- Configure source for a new BaB driver
- sha2 allow external access to some macros and the K array
- Fixed a math issue when reporting fan speed on the status line.
- Use the main hashlist to store work done in the bitfury driver and remove work
from the list by time, thereby fixing the duplicates at startup. Count hardware
errors for when no match occurs.
- Add a get and queue helper work function.
- Remove GPU mining code.
- Use libusb's own zero length packet support unless we have to emulate it on
windows since only libusb knows for sure if it's needed.
- Unlock the avalon qlock while sending tasks to not hold the lock for an
extended period.
- Sleep in avalon send task on return to the function to allow other code to
work during the sleep period.
- Send zero length packets when terminating a usb write aligned to
maxpacketsize.
- Do the driver flush in avalon code lockless since it can lead to deadlocks.
- Reset the work_restart bool after the scanwork loop in case the driver flushes
work synchronously.
- Only check for the stratum clean message if we have had a valid message.
- Get rid of the stage thread since all work can be asynchronously added now via
hash_push anyway.
- Remove the now incorrect faq entry regarding scrypt difficulty.
- Check for fatal read errors and break out of the read loop in avalon.
- Send errors are basically fatal in avalon driver so break out of the send
tasks loop.
- Make the avalon driver return -1 for hash count when usb fails, allowing the
main loop code to send it the shutdown flag.
- Break out of the hash work loops when a failure is detected instead of
dropping into mt disable.
- Use usbutils' own ftdi parser for avalon and the ftdir's own latency for
managing timeouts since we can wait on reads with completely asynchronous
reads+writes.
- Use usbutils' own cps function for slowing rate of usb writes on avalon.
- Fix build for no libcurl
- Check length before submitting sync transfers

1.Read the readme about copying the udev rules file.
2. Upgrade to 3.7.2 since this is a bug in 3.6.6.

Hi,

I just started using CGMiner with 2 BFL 50GH units and BTC Guild. I have 2 questions:

1. Using Ubuntu and can only run using sudo cgminer. I changed the permissions on the USB devices, but that did not help. The USB ports work fine otherwise. Any ideas on how to fix this?

2. It stops after 8 hours, with a message about waiting for the pool. Is there a setting I need to change? What could cause this?

Thank you.

... people must be pressing F5 lots on this forum ...

Yes I was about to edit and add ...

If on the other hand it is indeed returning mostly rubbish results, it will affect the calculations of the hash rate also.
The good old saying: garbage in garbage out.
Yes the driver is not designed to correct the 'garbage in'

Aside: I do have a long standing TODO: comment in the code ...
https://github.com/ckolivas/cgminer/blob/master/driver-icarus.c#L1204
and the line after it.
But that is to do with timing mode also.

Hmm, I'm not using any timing options. I just use --usb BAS:0 in my Erupter instance so that it doesn't try to capture the Jalapeno.

I did find this earlier and it has seemed to resolve the behavior.

Thanks,
Sam


Edit: overnight I had two more BE's start reporting GHs range.  So I dropped my erupter count down to 35 on the 49 port hub.  So I'm not sure that the above has anything to do with my problem.

TL;DR - Don't use a timing option any more.

I have heard of issues with USB3 and libusb but this is the first before and after type report like this so it could be helpful for us to find out why. If you're building it yourself from git, can you do a bisect to find when it started? Here is how to do it from 3.6.4 to 3.7.2:

Then it will find halfway points between them and you can rebuild it each time to and report back to git

If it doesn't detect the devices
or
if it does.

If for some reason one of the steps along the way doesn't build or crashes  or hangs or something else due to being in a dodgy commit, just skip it with

When it's all over git should report to you something like "The first offending commit is XXXX" and you can report that one back to me here. Once it's over you can reset your git tree back to normal with

This happens when you use the timing option (short or long) and the documentation reference in FPGA-README is:

'short' or 'long' mode should only be used on a computer that has enough CPU available to run
cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
Any CPU delays while calculating the hash time will affect the result
'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
corrects itself

It normally takes a 335MH device ~12.8 seconds to check all nonces in a single work item. The BEs use the icarus protocol which means as soon as they find a result, they report it back and then stop working. This can happen anywhere between zero and 12.8 seconds. The driver then gives it more work and the cycle starts all over again. If you can imagine the device coming back with a "result" in say .1 second and does this every time, the driver probably thinks it's running at a terrahash. However if it's a wrong result most of the time, it's meaningless. The driver shouldn't really be reporting it back as 1TH then so it's a mistake in the calculation in the driver. Kano might want to chime in since he wrote most of the driver.

Hi,
i've a problem and i hope i'll be able to explain.

- Windows 7
- Bitburner fury running with Zadig Driver
- If i Plug the Usb Hub with USB Asic Erupter the Bitburner stops to work and i must reinstall all drivers.

There's a way to run Bitburner Fury + Usb Asic Erupter at the same time?

Thank you so much.

Any support for hashbusters nano in the pipe? Then I could get rid of the virtualbox. Cheers.

I have a USB driver question (not a complaint).

Have you changed any USB driver components between 3.6.4 and 3.7.2?

Because all of a sudden, I cannot for the life of me get CGminer 3.7.2 to work with my USB block erupters at all, while going thru Anker USB hubs (I have two hubs, none of them wants to work with CGminer 3.7.2).

If I reboot, and start up CGminer 3.6.4, same machine, different CGminers in different directories, 3.6.4 works fine.

I start up 3.7.2, no AMUs get recognized thru the hub. The only way they get recognized by CGminer 3.7.2 is if I plug them into the computer's usb ports directly.

The Anker hubs are USB 3.0 hubs, so it seems like there is some kind of issue when going from USB 2.0 to USB 3.0., either with CGminer or the Anker hubs.

This is a pure Linux Mint 14 machine, AMD processor, with the each version of CGminer compiled using --enable-icarus --enable-klondike --no-gpu --disable-opencl

I don't remember what the flags were for each compile (I think I have them written down somewhere), but the earlier version had a different set...I'm guessing that's important? (I think I loaded libtool, libncurses-dev yasm curl , for the 3.6.4 compilation, but not for the 3.7.2 compilation).

The 3.7.2 compile I just did

cd cgminer
chmod +x ./autogen.sh
./autogen.sh
./configure --enable-icarus --enable-klondike --no-gpu --disable-opencl
make

Version 3.6.4 used to also recognized Klondikes going thru the Anker hub, but it does not anymore under 3.7.2. Both icarus and klondikes work fine when plugged directly into the usb ports under 3.6.4.

Weird, isn't it?  

Any thoughts would be greatly appreciated. Thank you for all your work on this.

I have two block erupters that are producing about a Ths for me.  That would be great if weren't a Ths of Hardware errors.  I have seen others report very high hash rates for BE's but I don't remember what the consensus was.  Is this a BE, Hub or CGMiner issue?  Any insight would be appreciated.
Sam

Con, I will try to filter out bugs and report the ones which are related to your code only