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

Yes that's common as the failure is at the usb hub level, not at the device level. cgminer tries to reset devices that stop responding but what really needs to be reset is the hub. I guess I could potentially look at the parent device and try to send it a reset but then that would be the wrong thing to do if the device was at fault and not the hub. The errors we get back at the software level are not entirely helpful to distinguish the two.

With my Chilis I find that they tend to go out in groups as well. I need to start logging to confirm, but they'll run for a week or more without issue and then 4 seem to go out at the same time.

Thank you both!  I was walking in dentist do I didn't get to finish my post till now.

New project tonight before I go wire the car some more!

Yup these units all have the USB port still.  And awesome news!  I have a BB Black that will be here Tuesday.  Though I built a i5 4670k with 16 gigs to be my R&D box.  I have Ubuntu server but was going to switch to Arch because this thing was built to be headless after OS install.  I'll have to try it out tonight and see if I can get it to work.

Going to use the BB Black on a few other projects.  The PI is nice but you are right the USB faults blow!

So when I get home I will read a few of the threads.  When it plugs in the system should detect the Avalon control unit and its two blades.  It will still control the fans and such (water cooling hopefully in next week).  Then just setup cgminer for Avalon support as always, etc.  If so will this be viable at with 7 boxes at 1.5 TH/s?  Of course each would be on powered USB hubs connected to the Asus Premium mobo.

If you and anyone else would think this would work I would love you very very long time lol!!

Sure you can run any USB device that cgminer supports off any device that you can build cgminer for (even with windows). I ran the avalon for 3 months off my regular PC rig's USB when I broke my tp link router. Open it up, pull the usb cable out and plug in a (printer type) usb cable that goes to your pc. It's actually more reliable that way too since the tplink is so woefully low power.

Thanks. Could be, for sure. It happens on several hubs, but they are all the same kind (Anker). I'm running Win 7 so can't do the lsusb check. Another Win7 tester was getting cluster USB AMU zombies a while back but I haven't seen him post of late.

If the Avalon clones have a USB port you can mine through like the originals, then just plug them in to a hub and run them off a BeagleBone Black.  I'm suggesting the Black because it's USB is much more stable than the RaspPi's USB, and the 2GB flash on the BBB is much more stable than the SD cards on the Pi.

I'm running Debian on my BeagleBone Black, with cgminer or bfgminer (your choice), Apache, php, which I can access using the normal miner.php page.  I've got about 100Gh going through it, soon to be 150GH.  I use bfgminer as I also use it as a getwork proxy.

ckolivas I know you don't manage the TP-Link hardware and software but I do know you have done the builds to update CGminer (Much much love man on that one).  Have you heard of anyone dropping the TP-Link and using another piece of hardware like a PI or a BB Black to run CGMiner?  I am trying to find a solution to monitor 7 Avalon 2 clones remotely and the TP-Link WRT Ports are very limited.  My shop I host from is 15 minutes away but I would like to be able to set it up where I can just login remotely and see how things are going.

I know there are solutions like CGRemote but it has to be run locally on the network and I can't broadcast it where I can pick it up at home.  Any idea from anyone else that has tried something would be awesome!

Thanks!

Seems like your hub is the one to blame. Lsusb -v?

Using 3.10.0 for about 3 hours now and I just got a cluster of four AMU zombies. No big deal, but I should probably have mentioned that for the last few versions, on the rare occasions that I still get zombies, they almost always come in clusters of four.

Confirmed building on a Beaglebone as well:

That will fail when linking as shown in netfun2000's dump. Adding --enable-bitfury to the configure command will workaround the bug and build successfully.
It would seem that without --enable-bitfury, there is some partial libbitfury leakage into the build process.

Unofficial Mac binaries have been updated for v3.10.0 and are available here.

These are universal precompiled binaries that support Mac OS X 10.5.8 through 10.9+.

ROTFL - thanks for it. I don't have an ice one. Maybe they should put a text on it "just look, don't touch" 

Will consider when I get back from holiday thanks. It's a one line change if you wish to alter it for your build in driver-bitfury.c line 417. When I almost burnt myself on one, I did think whoever called the devices I received "ice" was seriously smoking something.

Please add one parameter for it. With 54 bits the nanofury runs outside usb2.0 specs. I was able to melt a psu of a cheap hub. I expect users having problems with nanofurys because the hub is to weak for 54 bits.

I think the default should be at 50 with a parameter to change it.

No there is not, as I have seen it is virtually always best to leave it at 54, so I have added no command line option for now.

I tried on debian and it worked. The nanofury are running fine. Thanks for the work :-)

I am looking for the parameter to set the speed of the nanofury. Something like the "--hexmineru-frequency" of Martos patch or the "--bitfury-osc6-bits" of bfgminer. Is there some?

./autogen.sh?

Raspberry PI Make Error:
make  all-recursive
make[1]: Entering directory `/home/minepeon/cgminer'
Making all in lib
make[2]: Entering directory `/home/minepeon/cgminer/lib'
  GEN      arg-nonnull.h
  GEN      c++defs.h
  GEN      warn-on-use.h
  GEN      signal.h
  GEN      stdint.h
  GEN      string.h
make  all-recursive
make[3]: Entering directory `/home/minepeon/cgminer/lib'
make[4]: Entering directory `/home/minepeon/cgminer/lib'
  CC       dummy.o
  AR       libgnu.a
make[4]: Leaving directory `/home/minepeon/cgminer/lib'
make[3]: Leaving directory `/home/minepeon/cgminer/lib'
make[2]: Leaving directory `/home/minepeon/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/minepeon/cgminer/compat'
Making all in jansson-2.5
make[3]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in src
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
  CC       dump.lo
  CC       error.lo
  CC       hashtable.lo
  CC       load.lo
  CC       memory.lo
  CC       pack_unpack.lo
  CC       strbuffer.lo
  CC       strconv.lo
  CC       utf.lo
  CC       value.lo
  CCLD     libjansson.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5/src'
make[5]: Entering directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/jansson-2.5'
Making all in libusb-1.0
make[3]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make  all-recursive
make[4]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
Making all in libusb
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
  CC       libusb_1_0_la-core.lo
  CC       libusb_1_0_la-descriptor.lo
  CC       libusb_1_0_la-io.lo
  CC       libusb_1_0_la-sync.lo
  CC       os/libusb_1_0_la-linux_usbfs.lo
  CC       os/libusb_1_0_la-linux_udev.lo
  CC       libusb_1_0_la-hotplug.lo
  CC       os/libusb_1_0_la-threads_posix.lo
  CCLD     libusb-1.0.la
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0/libusb'
make[5]: Entering directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[5]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[4]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Leaving directory `/home/minepeon/cgminer/compat/libusb-1.0'
make[3]: Entering directory `/home/minepeon/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/minepeon/cgminer/compat'
make[2]: Leaving directory `/home/minepeon/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/minepeon/cgminer/ccan'
  CC       opt/libccan_a-helpers.o
  CC       opt/libccan_a-opt.o
  CC       opt/libccan_a-parse.o
  CC       opt/libccan_a-usage.o
  AR       libccan.a
make[2]: Leaving directory `/home/minepeon/cgminer/ccan'
make[2]: Entering directory `/home/minepeon/cgminer'
  CC       cgminer-cgminer.o
  CC       cgminer-util.o
  CC       cgminer-sha2.o
  CC       cgminer-api.o
  CC       cgminer-logging.o
  CC       cgminer-usbutils.o
  CC       cgminer-libbitfury.o
  CC       cgminer-driver-icarus.o
  CCLD     cgminer

cgminer-libbitfury.o: In function `spi_reset':
/home/minepeon/cgminer/libbitfury.c:226: undefined reference to `mcp2210_set_gpio_settings'
/home/minepeon/cgminer/libbitfury.c:233: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:239: undefined reference to `mcp2210_set_gpio_settings'
cgminer-libbitfury.o: In function `spi_txrx':
/home/minepeon/cgminer/libbitfury.c:255: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:265: undefined reference to `mcp2210_spi_transfer'
collect2: error: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/home/minepeon/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/minepeon/cgminer'
make: *** [all] Error 2

Great work thanks Ckolivas.