Hi Guys, i've jus moved my SHA mining rigs from a windows box to my RPi using Minepeon (was multimining on the box with CPU and GPUs but heat became a problem) but i'm having some issues with my USB miners - i have 23 USB ASIC miners, one Ant U1 miner and 3 chili miners, the chili miners are detected straight away and are running happily - the USB miners will not detect (the green lights stay on). The RPi is connected as below: RPi - 10 port ORICO USB 2 HUB - ORICO 10 Port USB 3 Hub - 8x USB ASIC Miner - Dodocool 10 Port USB 3 Hub - 7x USB ASIC Miner - ORICO 10 Port USB 3 Hub - 6x USB ASIC Miner & 1 Antminer U1 - 3x MrTeal Chili miners I'm gussing that the issue lies some where in the way the hubs are connected OR in the config for the bfgminer? if it makes any difference its the first version RPi (256mb RAM) Any help would be great  Try the following command and confirm that the USB3 HUB's are not detected by the RPI. That's a known problem. With the following command, you can see the Tree of the detected equipments connected to the USB ports: |
|
|
|
Last message from moriartybitcoin: Michael Moriarty
04:47 (4 hours ago)
to ct1aic
Well, I have refunded you so I would hope that you at least have the decency to post on bitcointalk that you received a refund. If not, you are simply dishonest.
My answer: ct1aic < ct1aic@gmail.com> 08:10 (1 hour ago) to Michael Hi again, Michael Moriarty. I don' t understand your last email, as yesterday, I posted at the thread, the confirmation that I already received the 0.15 BTC, including your previous email offending me and my answer to you. Regarding the TheBitcoinCard.co.uk, they did the same thing that you did... Or worst. I ordered them a bitcoin debit card (if you remember, it had a lovely design at their page, with a bitcoin at the upper left corner of the card) but what I received was a black debit Mastercard with only a design of a €, a £ and a $ symbols. I didn't realized I still had their link in my personal web page and I already deleted the affiliate link to them. Thank you for the alert. Have a great week-end. Rui Costa. |
|
|
|
scam Inbox Michael Moriarty < moriarty.bitcoin@gmail.com> 22:53 (34 minutes ago) to ct1aic I refunded your 0.15btc and also exposed your scam refund on bitcointalk. My answer: Hi and thanks for the refund you promised last 14 February. As you can read at your BitPlastic Bitcoin Forum thread, you promised at your site, a yellow BITPLA$TIC engraved Mastercard Debit card and you sent me a Bank Zachodni's Polish VISA card. Working or not, it's not the same card you were (and still are) advertising, promising a Mastercard and even including a photo of it at your site and as I remember (your comment from last 14 Feb 2014: "...No matter though, I have updated the faq to show the correct image of the card https://bitplastic.com/bitcoin-debit-card"), because of my comment at the Bitcoin Forum, you had to include that info at your site: Does the card look like the one pictured on the website?
No. The card looks like this... Imagine yourself selling a FORD car, but not telling the brand at the advertise and using a photo of a lamborghini... Is it honest? I think not. Your comment in your last email and at the Bitcoin Forum is offensive and I already reported it to the Forum Moderators. Have a good day. |
|
|
|
.... snip ....
Thats odd, it seems that there are some changes to a few files that it does not like. It can easly be fixed though, do this;- cd /opt/minepeon git checkout bin/scripts/FactoryReset.sh git bin/bitstreams/README git pull I will try to work out what I did wrong! Neil I think Neil missed the word "checkout" in the second command: cd /opt/minepeon
git checkout bin/scripts/FactoryReset.sh
git checkout bin/bitstreams/README
git pull The idea being, your git pull command is being blocked because it doesn't like something about those two files. If you check out both those files, you should be able to do a git pull successfully, until Neil can figure out and fix the real root cause. Greetings, KyrosKrane. It didn't worked, but as it's a file with no need to be there, I removed it and it worked! [minepeon@minepeon bitstreams]$ cd /opt/minepeon
[minepeon@minepeon minepeon]$ git checkout bin/scripts/FactoryReset.sh
[minepeon@minepeon minepeon]$ git checkout bin/bitstreams/README
error: pathspec 'bin/bitstreams/README' did not match any file(s) known to git.
[minepeon@minepeon minepeon]$ git pull
Updating 93b1f75..dfdac8b
error: The following untracked working tree files would be overwritten by merge:
bin/bitstreams/README
Please move or remove them before you can merge.
Aborting
[minepeon@minepeon minepeon]$ rm bin/bitstreams/README
[minepeon@minepeon minepeon]$ git pull
Updating 93b1f75..dfdac8b
Fast-forward
bin/bfgminer | Bin 628076 -> 641762 bytes
bin/bfgminer-rpc | Bin 9617 -> 9653 bytes
bin/bitforce-firmware-flash | Bin 12261 -> 12377 bytes
bin/bitstreams/README | 1 +
bin/cgminer | Bin 838358 -> 736259 bytes
bin/cgminer-gc3355 | Bin 0 -> 1514853 bytes
bin/scripts/FactoryReset.sh | 1 +
lib/libblkmaker-0.1.so.0.4.1 | Bin 12992 -> 13087 bytes
lib/libblkmaker_jansson-0.1.so.0.4.1 | Bin 12345 -> 12333 bytes
lib/libjansson.a | Bin 51296 -> 52296 bytes
lib/libjansson.so.4.5.0 | Bin 44953 -> 45142 bytes
lib/libusb-1.0.a | Bin 81526 -> 82114 bytes
lib/libusb-1.0.so.2.0.0 | Bin 74778 -> 75203 bytes
share/doc/bfgminer/AUTHORS | 3 +-
share/doc/bfgminer/README | 46 +++++++++--
share/doc/bfgminer/README.RPC | 39 ++++++++-
share/doc/bfgminer/rpc-examples/miner.php | 127 ++++++++++++++++++++++++------
17 files changed, 181 insertions(+), 36 deletions(-)
create mode 100644 bin/bitstreams/README
create mode 100755 bin/cgminer-gc3355
[minepeon@minepeon minepeon]$
|
|
|
|
|
Still waiting for the promised refund...
|
|
|
|
...
inside text of README: You must put the file fpgaminer_top_fixed7_197MHz.ncd in here for modminer to w$
Due to the pointlessness of mining BTC with FPGA, Con removed it since it was the largest file in the distribution and took up about 50% of the file space for everyone downloading cgminer but almost no one uses it - my MMQ sits with my other FPGA quietly watching my ASICs  Just get it from a release before it was removed i.e. 3.12.3 or earlier (8-Feb-2014) As you can see in my last post, it is still there... [minepeon@minepeon minepeon]$ cd bin/bitstreams
[minepeon@minepeon bitstreams]$ dir
COPYING_fpgaminer README fpgaminer_top_fixed7_197MHz.ncd
|
|
|
|
.... snip ....
Thats odd, it seems that there are some changes to a few files that it does not like. It can easly be fixed though, do this;- cd /opt/minepeon git checkout bin/scripts/FactoryReset.sh git bin/bitstreams/README git pull I will try to work out what I did wrong! Neil One of the commands was not recognized... [minepeon@minepeon ~]$ cd /opt/minepeon [minepeon@minepeon minepeon]$ git checkout bin/scripts/FactoryReset.sh [minepeon@minepeon minepeon]$ git bin/bitstreams/README
git: 'bin/bitstreams/README' is not a git command. See 'git --help'.[minepeon@minepeon minepeon]$ git pull remote: Counting objects: 27, done. remote: Compressing objects: 100% (26/26), done. remote: Total 27 (delta 6), reused 0 (delta 0) Unpacking objects: 100% (27/27), done. From https://github.com/MineForeman/minepeon-base 93b1f75..dfdac8b master -> origin/master 23c2dbe..61fee71 0.3.0 -> origin/0.3.0 Updating 93b1f75..dfdac8b error: The following untracked working tree files would be overwritten by merge: bin/bitstreams/README Please move or remove them before you can merge. Aborting [minepeon@minepeon minepeon]$ I did a dir and the file is there (as a file): [minepeon@minepeon ~]$ cd /opt/minepeon
[minepeon@minepeon minepeon]$ cd bin/bitstreams
[minepeon@minepeon bitstreams]$ dir
COPYING_fpgaminer README fpgaminer_top_fixed7_197MHz.ncd
[minepeon@minepeon bitstreams]$
inside text of README: You must put the file fpgaminer_top_fixed7_197MHz.ncd in here for modminer to w$ |
|
|
|
What did I wrong today? I'm only using your SSH menu, but option f gave me the following error in all RPI's: I am not sure, I started work on a branch for 0.3.0 yesterday and did a few miner updates to 0.2.5.6. Can you exit to shell and do a;- cd /opt/minepeon git branch -a git pull for me and tell me what it does? Neil [minepeon@minepeon ~]$ cd /opt/minepeon [minepeon@minepeon minepeon]$ git branch -a 0.2.4 0.2.4PR2 Test-Merge-0.2.4-Master * master static remotes/origin/0.2.4 remotes/origin/0.2.4PR1 remotes/origin/0.2.4PR2 remotes/origin/0.3.0 remotes/origin/AngularJS remotes/origin/BBB remotes/origin/HEAD -> origin/master remotes/origin/KnC remotes/origin/RaspberryPi-0.2.5 remotes/origin/Test-Merge-0.2.4-Master remotes/origin/donate-norestart remotes/origin/master remotes/origin/shutdown remotes/origin/static [minepeon@minepeon minepeon]$ git pull remote: Counting objects: 4, done. remote: Compressing objects: 100% (4/4), done. remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4), done. From https://github.com/MineForeman/minepeon-base 72e7d15..dfdac8b master -> origin/master Updating 93b1f75..dfdac8b error: Your local changes to the following files would be overwritten by merge: bin/scripts/FactoryReset.sh Please, commit your changes or stash them before you can merge. error: The following untracked working tree files would be overwritten by merge: bin/bitstreams/README Please move or remove them before you can merge. Aborting [minepeon@minepeon minepeon]$ |
|
|
|
|
Still waiting for the promised refund...
|
|
|
|
|
Still waiting for the promised refund...
|
|
|
|
ct1aic, Did you add those miners over time? Otherwise what is the point of buying so many usb miners, for that money you can better buy one big machine IMO. Hi, mikerbiker6. I bought the majority in pre-order, when there was almost no other miners for selling. At that time, we only had the ATI/AMD top graphic cards, with higher price and using 100 times the energy of one or 2 USB Block Erupters, to get the same hashing rate. Now, I don't have courage to stop mining with them. |
|
|
|
Thanks. New problems with 0.2.4.6 version: The defaults for miner startup settings (both BFGMiner and CGMiner) don't include the date/time code that is included in previous version and also in this new version, before selecting the defaults buttons. I have a strange reaction with one of the RPI's: I have 2 Mitsai 7 port HUB's with several USB Block Erupters and Blue Fury and also, connected to each of those HUB's 2 D-Link 7 port HUB's with a mix of USB Block Erupters and overclocked Block Erupters, with a total of 6 HUB's and 24 Block Erupters & 3 Blue Fury. All HUB's have 5 to 8 amp. 5 volts PU's. With the old version of MinePeon & BFGMiner 3.10.0, all miners are mining with no problems. But with the new version of MinePeon & BFGMiner 3.10.0, only the miners connected to the 2 Mitsai directly connected to the RPI are working with no problems. Regarding the other miners, connected to the D-Link HUB's, start working and after several seconds, light the green LED's for more or less, restart mining for some more seconds and keep repeating this behavior. UPDATE: this strange behavior is only detected with the overclocked Block Erupters and not with the others, in same HUB's. With this new image, I can't get more than 335 MH from each overclocked Block Erupter, instead of the 440 MH I got with previous version of MinePeon (with same version of BFGminer). Perhaps something with the compilation of the BFGminer? The RPI with 36 Block Erupters connected via a 49 Port USB 2.0 HUB are working fine and also the RPI with the 7 Jalapeños connected via 2 Mitsai HUB's, with this new MinePeon version. To Neil, Mariogrip and to the other guys that are working for one of the best programs I ever used, my thanks for your wonderful work.  |
|
|
|
As I can't reserve the IP address of the RPI at my Router, with this new version of MinePeon, how can I configure the ETH0 with a Static IP without reverting to dynamic IP after RPI restart? I tried ifconfig with versions 0.2.4.5 PR2 and 0.2.4.6 and there is a new in the new version (ifb1:): [minepeon@minepeon ~]$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.110 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:48:b4:83 txqueuelen 1000 (Ethernet)
RX packets 97785 bytes 7112877 (6.7 MiB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 113706 bytes 8903494 (8.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 0 (Local Loopback)
RX packets 3572 bytes 2089331 (1.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3572 bytes 2089331 (1.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[minepeon@minepeon ~]$
[minepeon@minepeon ~]$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.213 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:a3:0a:09 txqueuelen 1000 (Ethernet)
RX packets 5303 bytes 5042137 (4.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4247 bytes 1295969 (1.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ifb1: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500
ether 2a:cb:56:94:21:f6 txqueuelen 32 (Ethernet)
RX packets 4 bytes 1568 (1.5 KiB)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 0 (Local Loopback)
RX packets 438 bytes 275667 (269.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 438 bytes 275667 (269.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[minepeon@minepeon ~]$
|
|
|
|
I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.
Ok, at home, this is a big problem. My Fonera 2.0 N doesn't accept these so big mac-address's and I had to revert to the old 0.2.4.5 version. Even with no GUI is better than with no IP. I'll wait for a soluction for this problem, to try the new version again at home. At work, the DHCP server accepts this type of long mac's. That is a bit odd, MinePeon has no control over the mac address you router see's. As such, the fix needs to be in your router not your MinePeon! I will do a bit of further reading. Is your router firmware upto date? Neil Ok, then the problem must be with my Linksys router (with DD-WRT) and my Fonera router and Microsoft Windows 2010 Enterprise Server's DHCP service.  The Same RPI, with the old images and other distro's gives to those DHCP's the same 12 hexa digits, with the new 0.2.4.6 gives a 36 digits hexadecimal number... Is this the difference between IPv4 and IPv6 addressing? The IPv6 address size is 128 bits. The preferred IPv6 address representation is: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx where each x is a hexadecimal digit representing 4 bits. IPv6 addresses range from 0000:0000:0000:0000:0000:0000:0000:0000 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. 32 hexa... I get a 36 hexa digits... but a good question... |
|
|
|
I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.
Ok, at home, this is a big problem. My Fonera 2.0 N doesn't accept these so big mac-address's and I had to revert to the old 0.2.4.5 version. Even with no GUI is better than with no IP. I'll wait for a soluction for this problem, to try the new version again at home. At work, the DHCP server accepts this type of long mac's. That is a bit odd, MinePeon has no control over the mac address you router see's. As such, the fix needs to be in your router not your MinePeon! I will do a bit of further reading. Is your router firmware upto date? Neil Ok, then the problem must be with my Linksys router (with DD-WRT) and my Fonera router and Microsoft Windows 2010 Enterprise Server's DHCP service. The Same RPI, with the old images and other distro's gives to those DHCP's the same 12 hexa digits, with the new 0.2.4.6 gives a 36 digits hexadecimal number... |
|
|
|
I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.
Ok, at home, this is a big problem. My Fonera 2.0 N doesn't accept these so big mac-address's and I had to revert to the old 0.2.4.5 version. Even with no GUI is better than with no IP. I'll wait for a soluction for this problem, to try the new version again at home. At work, the DHCP server accepts this type of long mac's. |
|
|
|
|
I'm now trying the new 0.2.4.6 version of MinePeon and I'm getting back an old problem, regarding the mac-address of the RPI, that is seen by the Windows DHCP: ebe6080000010001c792bc8cb827eb621e4f instead of b827ebe60800.
Also, I love the new SSH menu, but it would be nice to have an option to see the IP address of the RPI (for instance via ifconfig).
|
|
|
|
Interesting... without the MinePeon apache GUI working, my 2 RPI's with many USB Block Erupters are much more stable and are now working without any crash from 2 days ago. Before, they were crashing 1 to 2 times a day.
99% chance that you were running 0.2.5 UNSTABLE. I have just about given up on detailed statistics on a ARM device it causes too many issues (just about, more to come). Sorry I did not get a replacement image out last night, I got home ate something and went to bed. Life is very busy at the moment and MinePeon is pushing me into 60+ hour weeks. Neil Yes, it's the 0.2.5 UNSTABLE, Neil. And never forget that this is a hobby and your health must be in first place! You need to sleep more. |
|
|
|
|
Interesting... without the MinePeon apache GUI working, my 2 RPI's with many USB Block Erupters are much more stable and are now working without any crash from 2 days ago. Before, they were crashing 1 to 2 times a day.
|
|
|
|
|
Show Posts
