Pages:
Author

Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64 - page 3. (Read 260035 times)

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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.
legendary
Activity: 2576
Merit: 1186
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..
full member
Activity: 196
Merit: 100
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.

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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 ...
hero member
Activity: 658
Merit: 500
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.
legendary
Activity: 2576
Merit: 1186
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.
hero member
Activity: 658
Merit: 500
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?
legendary
Activity: 2576
Merit: 1186
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 Sad

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.
sr. member
Activity: 359
Merit: 250
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 Sad

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.  
legendary
Activity: 2576
Merit: 1186
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 Sad

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.
sr. member
Activity: 359
Merit: 250
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 Sad

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?
legendary
Activity: 2576
Merit: 1186
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 Sad

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).
sr. member
Activity: 359
Merit: 250
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.
legendary
Activity: 2576
Merit: 1186
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.
sr. member
Activity: 446
Merit: 250
@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 Wink )
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. Smiley

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)
legendary
Activity: 2576
Merit: 1186
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.
sr. member
Activity: 359
Merit: 250
@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 Wink )
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. Smiley
sr. member
Activity: 379
Merit: 250
legendary
Activity: 2576
Merit: 1186
Thanks, I think I got them swapped to the correct order now with --gpu-map 0:1,1:0

I am guessing the REST issue is the card shutting down due to the overclocking and/or intensity level set to 5 on a computer that I actually use constantly. Weird that it's been fine for almost a year until now.
The REST was because it saw the temperature too high and was trying to cool it off - but since it had the mapping wrong, it actually shut off the wrong card, and the overheating one never cooled...
Pages:
Jump to: