(OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64

[mitty]

@cchan: I can't open your image (very likely that my work blocks it, as their Internet connection is quite awful), so without seeing it; 1. Have you been mining for at least a few minutes?  282 MH/s isn't much and it's possible that a share simply wasn't submitted yet.  2. Are shared being accepted?  I'd assume not if u=0.  3. Try mining on a different pool and see if your results are different.  Sorry I can't be of much help without seeing the pic :/

As for a problem of my own...
Does anyone mining with BFL singles repeatedly get "comms error" after mining for a few hours? 

My mining rig consists of 22 BFL singles connected to a Micro-ITX Intel Atom based host running Ubuntu. (11.04 I believe, but I'd need to double check)
I have 3 USB hubs attached directly to the system, and 1 hub connected to the first port of each system-connected hub. (so 6 hubs in total; need room for expansion )
All hubs are these: http://www.amazon.com/7-Port-USB-2-0-Hub-Black/dp/B000KUQ8FG

All BFLs are attached to the 3 system-connected hubs, and 1 of the daisy-chained hubs.  The 2 other daisy chained hubs don't have any attached devices.

All hubs are powered. (with the power connector hooked up)

The "comms error" affected unit changes but it always seems to be a unit attached to the daisy chained hub, and starts any time from minutes to days after I start bfgminer.  Restarting bfgminer seems to fix the problem.

The USB cables on the affected units do seem very loose but simply restarting bfgminer seems to fix the problem, so I'm not sure whether it's a hardware or software issue.  I ordered more USB cables to be safe, but in the meantime I want to make sure the issue isn't in software and find a fix if it is.

I searched and it looks like people were having this issue when using a raspi host due to USB problems on the pi, but I didn't see anything about issues on Atom machines.

Any help/advice would be appreciated.

[Luke-Jr]

what's my problem, avg = 282.1, but u = 0, seems not mining.
thanks.
http://p13.freep.cn/p.aspx?u=v20_p13_photo_1303231936187532_0.jpg

Looks like a broken driver. If you could post the card & driver/OpenCL versions that don't work, that could help for information collecting.

[jddebug]

@cchan: I can't open your image (very likely that my work blocks it, as their Internet connection is quite awful), so without seeing it; 1. Have you been mining for at least a few minutes?  282 MH/s isn't much and it's possible that a share simply wasn't submitted yet.  2. Are shared being accepted?  I'd assume not if u=0.  3. Try mining on a different pool and see if your results are different.  Sorry I can't be of much help without seeing the pic :/

As for a problem of my own...
Does anyone mining with BFL singles repeatedly get "comms error" after mining for a few hours? 

My mining rig consists of 22 BFL singles connected to a Micro-ITX Intel Atom based host running Ubuntu. (11.04 I believe, but I'd need to double check)
I have 3 USB hubs attached directly to the system, and 1 hub connected to the first port of each system-connected hub. (so 6 hubs in total; need room for expansion )
All hubs are these: http://www.amazon.com/7-Port-USB-2-0-Hub-Black/dp/B000KUQ8FG

All BFLs are attached to the 3 system-connected hubs, and 1 of the daisy-chained hubs.  The 2 other daisy chained hubs don't have any attached devices.

All hubs are powered. (with the power connector hooked up)

The "comms error" affected unit changes but it always seems to be a unit attached to the daisy chained hub, and starts any time from minutes to days after I start bfgminer.  Restarting bfgminer seems to fix the problem.

The USB cables on the affected units do seem very loose but simply restarting bfgminer seems to fix the problem, so I'm not sure whether it's a hardware or software issue.  I ordered more USB cables to be safe, but in the meantime I want to make sure the issue isn't in software and find a fix if it is.

I searched and it looks like people were having this issue when using a raspi host due to USB problems on the pi, but I didn't see anything about issues on Atom machines.

Any help/advice would be appreciated.

Honestly, you are probably having usb issues. I have netbooks setup to run my mini rigs. If I add a hub between the netbook and the mini rigs (They contain hubs too) then I get problems. I found I had to have a separate netbook for EACH mini rig. You may need a few more host computers to run things so you can remove a hub from the string (computer ---> Hub --> Hub --> singles)

[Luke-Jr]

USB only supports/allows chaining hubs up to 5 deep. Often, your motherboard has at least one hub builtin (so 4 left). Most "USB hub" products with more than 3-4 ports are really just multiple 4 port hubs internally - so count as 2-3 each. On top of that, "USB hub" products are 99% garbage quality. Adding unreliable USB cables on top of that doesn't help either.

[mitty]

USB only supports/allows chaining hubs up to 5 deep. Often, your motherboard has at least one hub builtin (so 4 left). Most "USB hub" products with more than 3-4 ports are really just multiple 4 port hubs internally - so count as 2-3 each. On top of that, "USB hub" products are 99% garbage quality. Adding unreliable USB cables on top of that doesn't help either.

Thanks for the info.  I tried using that 12 port hub on Amazon that has a ton of reviews and found it to work fine until I got rid of my x6500's and it immediately started disconnecting after ~10 minutes of running.  It's too bad that USB hubs are so unreliable.. guess it's time for another mining host. :/ (unless there's some mythical high quality usb hub that can be chained)

Either way, thanks again and I appreciate all the work you put into bfgminer... it really is a great program.

[Luke-Jr]

USB only supports/allows chaining hubs up to 5 deep. Often, your motherboard has at least one hub builtin (so 4 left). Most "USB hub" products with more than 3-4 ports are really just multiple 4 port hubs internally - so count as 2-3 each. On top of that, "USB hub" products are 99% garbage quality. Adding unreliable USB cables on top of that doesn't help either.

Thanks for the info.  I tried using that 12 port hub on Amazon that has a ton of reviews and found it to work fine until I got rid of my x6500's and it immediately started disconnecting after ~10 minutes of running.  It's too bad that USB hubs are so unreliable.. guess it's time for another mining host. :/ (unless there's some mythical high quality usb hub that can be chained)

Sadly, even if you find a model that works well, these manufs like to swap the internals out with no model number changes, so you can't be sure you're buying the same thing

Edit: With that in mind, a Satechi UH-12P I bought used has been working fine, though it's not perfect (it's missing some desirable features).

[mitty]

USB only supports/allows chaining hubs up to 5 deep. Often, your motherboard has at least one hub builtin (so 4 left). Most "USB hub" products with more than 3-4 ports are really just multiple 4 port hubs internally - so count as 2-3 each. On top of that, "USB hub" products are 99% garbage quality. Adding unreliable USB cables on top of that doesn't help either.

Thanks for the info.  I tried using that 12 port hub on Amazon that has a ton of reviews and found it to work fine until I got rid of my x6500's and it immediately started disconnecting after ~10 minutes of running.  It's too bad that USB hubs are so unreliable.. guess it's time for another mining host. :/ (unless there's some mythical high quality usb hub that can be chained)

Sadly, even if you find a model that works well, these manufs like to swap the internals out with no model number changes, so you can't be sure you're buying the same thing

Edit: With that in mind, a Satechi UH-12P I bought used has been working fine, though it's not perfect (it's missing some desirable features).

I had bought that one and it ran my BFLs for 10 minutes then they all started timing out.  I switched to different hubs and they seemed to work fine up until this new problem, so maybe I just got a defective one?

[Luke-Jr]

USB only supports/allows chaining hubs up to 5 deep. Often, your motherboard has at least one hub builtin (so 4 left). Most "USB hub" products with more than 3-4 ports are really just multiple 4 port hubs internally - so count as 2-3 each. On top of that, "USB hub" products are 99% garbage quality. Adding unreliable USB cables on top of that doesn't help either.

Thanks for the info.  I tried using that 12 port hub on Amazon that has a ton of reviews and found it to work fine until I got rid of my x6500's and it immediately started disconnecting after ~10 minutes of running.  It's too bad that USB hubs are so unreliable.. guess it's time for another mining host. :/ (unless there's some mythical high quality usb hub that can be chained)

Sadly, even if you find a model that works well, these manufs like to swap the internals out with no model number changes, so you can't be sure you're buying the same thing

Edit: With that in mind, a Satechi UH-12P I bought used has been working fine, though it's not perfect (it's missing some desirable features).

I had bought that one and it ran my BFLs for 10 minutes then they all started timing out.  I switched to different hubs and they seemed to work fine up until this new problem, so maybe I just got a defective one?

Pretty sure the guy I bought it from ran it full of X6500s. I have a wide variety of devices on it now, maybe half of which are miners.

Do you run Linux? It might be useful to post what lsusb -vv shows for yours and compare it to mine.

[mitty]

USB only supports/allows chaining hubs up to 5 deep. Often, your motherboard has at least one hub builtin (so 4 left). Most "USB hub" products with more than 3-4 ports are really just multiple 4 port hubs internally - so count as 2-3 each. On top of that, "USB hub" products are 99% garbage quality. Adding unreliable USB cables on top of that doesn't help either.

Thanks for the info.  I tried using that 12 port hub on Amazon that has a ton of reviews and found it to work fine until I got rid of my x6500's and it immediately started disconnecting after ~10 minutes of running.  It's too bad that USB hubs are so unreliable.. guess it's time for another mining host. :/ (unless there's some mythical high quality usb hub that can be chained)

Sadly, even if you find a model that works well, these manufs like to swap the internals out with no model number changes, so you can't be sure you're buying the same thing

Edit: With that in mind, a Satechi UH-12P I bought used has been working fine, though it's not perfect (it's missing some desirable features).

I had bought that one and it ran my BFLs for 10 minutes then they all started timing out.  I switched to different hubs and they seemed to work fine up until this new problem, so maybe I just got a defective one?

Pretty sure the guy I bought it from ran it full of X6500s. I have a wide variety of devices on it now, maybe half of which are miners.

Do you run Linux? It might be useful to post what lsusb -vv shows for yours and compare it to mine.

Oh I already returned it to amazon and got a refund, sorry. (I do run Linux on my miner but I'm at work right now either way)
I had 3 x6500's and 6 BFLs attached to the 12 port hub and it worked fine, but it started giving me problems as soon as I disconnected the x6500s which I thought was really strange.  I might try buying 4 of those and attaching them all directly to my system so I can put up to 48 devices without buying another host though, if you seem to think they work fine.  

[Luke-Jr]

USB only supports/allows chaining hubs up to 5 deep. Often, your motherboard has at least one hub builtin (so 4 left). Most "USB hub" products with more than 3-4 ports are really just multiple 4 port hubs internally - so count as 2-3 each. On top of that, "USB hub" products are 99% garbage quality. Adding unreliable USB cables on top of that doesn't help either.

Thanks for the info.  I tried using that 12 port hub on Amazon that has a ton of reviews and found it to work fine until I got rid of my x6500's and it immediately started disconnecting after ~10 minutes of running.  It's too bad that USB hubs are so unreliable.. guess it's time for another mining host. :/ (unless there's some mythical high quality usb hub that can be chained)

Sadly, even if you find a model that works well, these manufs like to swap the internals out with no model number changes, so you can't be sure you're buying the same thing

Edit: With that in mind, a Satechi UH-12P I bought used has been working fine, though it's not perfect (it's missing some desirable features).

I had bought that one and it ran my BFLs for 10 minutes then they all started timing out.  I switched to different hubs and they seemed to work fine up until this new problem, so maybe I just got a defective one?

Pretty sure the guy I bought it from ran it full of X6500s. I have a wide variety of devices on it now, maybe half of which are miners.

Do you run Linux? It might be useful to post what lsusb -vv shows for yours and compare it to mine.

Oh I already returned it to amazon and got a refund, sorry. (I do run Linux on my miner but I'm at work right now either way)
I had 3 x6500's and 6 BFLs attached to the 12 port hub and it worked fine, but it started giving me problems as soon as I disconnected the x6500s which I thought was really strange.  I might try buying 4 of those and attaching them all directly to my system so I can put up to 48 devices without buying another host though, if you seem to think they work fine.

X6500 is a lot more "chatty" on USB, so maybe it's some kind of problem with power savings (X6500s preventing that from being active).

My hub has:

• Yubikey
• ZTEX 1.15x
• ModMiner
• Icarus
• BitForce Single (FPGA)
• (empty)
• X6500
• (empty)
• eZ430-Chronos-915 wireless programmer
• Samsung ML-2510 laser printer
• ZTEX 1.15y

As I mentioned, USB hub companies like to swap out the internals without changing model numbers, so there's basically no way to predict if you'd be buying the same hub I have.

[Aseras]

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

Luke, is there any way to run this without reflashing the firmware?
Is there a change log ( for the avalon build ) of what makes this different or better than the cgminer build in NEXT?

[Luke-Jr]

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

Luke, is there any way to run this without reflashing the firmware?

Not quite so easily. Due to the ridiculously small amount of flash, you can't install packages.
midnightmagic was successful at extracting the binaries/libraries and putting them in tmpfs to run, but that will be lost on reboot.

Is there a change log ( for the avalon build ) of what makes this different or better than the cgminer build in NEXT?

Not sure what "NEXT" is.. the Avalon driver in BFGMiner is basically a clean merge of xiangfu's codebase, so the differences are mostly the usual between cg and BFG: many more bugs fixed, reliable/working GBT support, more updated FPGA drivers, etc
There isn't really any good summary of these differences, but I did start a wiki page comparison of mining software that people can contribute things to.

Note that bfgminer does not have a web interface on OpenWrt yet, so you would be giving that up for now.
On the other hand, the build includes GNU Screen and the ncurses interfaces.

[Aseras]

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

tried it, bricks avalon. failsafe works. recovered to stock firmware.

[kano]

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

tried it, bricks avalon. failsafe works. recovered to stock firmware.

I guess the wiki should be updated to warn people that bfgminer bricks their avalon ...
But then again, why would untested code even be listed on the bitcoin wiki ...

[nathanrees19]

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

tried it, bricks avalon. failsafe works. recovered to stock firmware.

[nathanrees19]

I have no way to test this

http://lmgtfy.com/?q=buy+wr703n

[Luke-Jr]

I have no way to test this

http://lmgtfy.com/?q=buy+wr703n

WR703N != Avalon

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

tried it, bricks avalon. failsafe works. recovered to stock firmware.

Thanks for testing! Can you elaborate on specifically how it is bricked? Were you able to communicate with it at all?
Failsafe is actually using the firmware, so if that works it suggests some kind of config conflict..

[kano]

Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover! I have no way to test this, so try it at your own risk. It should be possible to enable network recovery in U-Boot, but I cannot provide instructions for this yet. That being said, it is based very closely off the original Avalon firmware and driver code, so I don't expect any problems.

There is no web interface or init scripts for BFGMiner at this time, so you will need to use SSH to run it. It is, however, compiled with the usual Text-User-Interface (TUI) and include GNU "Screen".

Edit: OpenWrt trunk (r35828) config used to build this

tried it, bricks avalon. failsafe works. recovered to stock firmware.

I guess the wiki should be updated to warn people that bfgminer bricks their avalon ...
But then again, why would untested code even be listed on the bitcoin wiki ...

Oh right ... I forgot ... in this thread ...
https://bitcointalk.org/index.php?topic=78192.40

So everyone can expect this also with his BFL ASIC code also - written without testing ... expect it to brick your BFL ASIC also - so don't use it.

[nathanrees19]

WR703N != Avalon

WR703N ∈ Avalon

[Aseras]

No network at all. Nothing. Put a network tester on it. Nothing. No dhcp/bootp not activity at all. No response to any of the common ip addresses.

Recovery doesn't need a serial port.

To recover an Avalon.

Shut unit off. Setup a pc. Get a http server running on it. Put known good firmware in root directory of webpage. Setup PC on ip 192.168.1.5. Start a ping to 192.168.1.1 plug cable between pc and Avalon. Power up Avalon. Watch blue led on wrt. When it blinks after 10 seconds or so hold down reset button for 1-2 seconds. PC should be able to telnet and ping to 192.168.1.1

Telnet to device. It's in limp mode.
cd /tmp
wget http://192.168.1.5/firmware.bin
mtd -r write firmware.bin firmware
It will reboot Avalon when done.
Setup as clean Avalon. Avalon up will be back to 192.168.0.100

Connect to default webpage and restore backup settings or reconfigure.