Raspberry Pi / cgminer for your BFL BitForce

[allinvain]

Ok, so on to try bfgminer I go. If this fails too then it's "screw you raspberry pi" for me. I have a feeling that bfgminer won't help either as this seems like a raspberry pi issue (yes I did update the firmware).

[1715271306]

1715271306

[allinvain]

Here is what I found. With cgminer 2.10.4 the comm error shows up. With bfgminer 2.9.4 it works but I believe the system is restarting so it's causing a system crash. bfgminer 2.10.1 is misreporting the hash rate for the bfl singles (at random)

It might be time to give up and go back to windows with cgminer + mpbm (modular python bitcoin miner). Quite disappointing really
Or maybe find a low power x86 solution (atom board or something similar)

[hardcore-fs]

Shit it's still doing it..

This sucks..

Can you post a closeup picture of your PI, so I can see the components...

[Bigal]

root@raspberrypi:/opt/vc/bin# ./vcgencmd version
Nov 22 2012 18:12:01
Copyright (c) 2012 Broadcom
version 352766 (release)

I'm not sure if this is relevant but could someone else run that command and tell me what firmware version you've got?

I'm running rpi-update right now..taking a long ass time..read somewhere that it could take up to 20 min..

Maybe that will fix this issue..

This is what I get

Code:

root@raspberrypi:/opt/vc/bin# ./vcgencmd version
Dec 28 2012 11:22:54
Copyright (c) 2012 Broadcom
version 359904 (release)

what does
>uname -a
put out?
I tried the latest download and the kernel would not update (just waits forever) still the old version I think
I started from scratch with the script and updated the firmware first and it seemed to work

Should be like
pi@raspberrypi:~$ Linux raspberrypi 3.6.11+ #346 PREEMPT Fri Dec 28 00:50:33 GMT 2012 armv6l GNU/Linux

[Luke-Jr]

Here is what I found. With cgminer 2.10.4 the comm error shows up. With bfgminer 2.9.4 it works but I believe the system is restarting so it's causing a system crash. bfgminer 2.10.1 is misreporting the hash rate for the bfl singles (at random)

I've been running 2.10.0 on my pi since it was released (with MMQ), and it seems to work fine with BFL (though I only just now moved it from my development system to the pi).
I built 2.9.7, and will let that run for a bit to test. How long does it usually take to reboot your pi?
After that, I can test the latest 2.10.x, but I don't expect any change from 2.10.0...

luke-jr@raspberrypi /opt/vc/bin $ ./vcgencmd version
Nov 22 2012 18:09:58
Copyright (c) 2012 Broadcom
version 352766 (release)
luke-jr@raspberrypi /opt/vc/bin $ uname -a
Linux raspberrypi 3.2.27+ #285 PREEMPT Tue Nov 20 17:49:40 GMT 2012 armv6l GNU/Linux

[allinvain]

root@raspberrypi:/opt/vc/bin# ./vcgencmd version
Nov 22 2012 18:12:01
Copyright (c) 2012 Broadcom
version 352766 (release)

I'm not sure if this is relevant but could someone else run that command and tell me what firmware version you've got?

I'm running rpi-update right now..taking a long ass time..read somewhere that it could take up to 20 min..

Maybe that will fix this issue..

This is what I get

Code:

root@raspberrypi:/opt/vc/bin# ./vcgencmd version
Dec 28 2012 11:22:54
Copyright (c) 2012 Broadcom
version 359904 (release)

what does
>uname -a
put out?
I tried the latest download and the kernel would not update (just waits forever) still the old version I think
I started from scratch with the script and updated the firmware first and it seemed to work

Should be like
pi@raspberrypi:~$ Linux raspberrypi 3.6.11+ #346 PREEMPT Fri Dec 28 00:50:33 GMT 2012 armv6l GNU/Linux

Linux raspberrypi 3.6.11+ #346 PREEMPT Fri Dec 28 00:50:33 GMT 2012 armv6l GNU/Linux

this is what I have...exactly like yours...

root@raspberrypi:/opt/vc/bin# ./vcgencmd version
Dec 28 2012 11:22:54
Copyright (c) 2012 Broadcom
version 359904 (release)

So I guess we are both running the latest everything (firmware and OS)

There was some mention somewhere on the net of putting "dwc_otg.fiq_fix_enable=1" in /boot/cmdline.txt

I did not try this yet as supposedly now this is turned on by default? As to if this is only in certain kernel version or whatnot I'm not sure.

My cmdline.txt file has this though "dwc_otg.lpm_enable=0" which was there by default...but no mention of dwc_otg.fiq_fix"

reference for this: http://raspberrypi.stackexchange.com/questions/1886/what-kernel-parameters-are-available-for-fixing-usb-problems

[allinvain]

Here is what I found. With cgminer 2.10.4 the comm error shows up. With bfgminer 2.9.4 it works but I believe the system is restarting so it's causing a system crash. bfgminer 2.10.1 is misreporting the hash rate for the bfl singles (at random)

I've been running 2.10.0 on my pi since it was released (with MMQ), and it seems to work fine with BFL (though I only just now moved it from my development system to the pi).
I built 2.9.7, and will let that run for a bit to test. How long does it usually take to reboot your pi?
After that, I can test the latest 2.10.x, but I don't expect any change from 2.10.0...

luke-jr@raspberrypi /opt/vc/bin $ ./vcgencmd version
Nov 22 2012 18:09:58
Copyright (c) 2012 Broadcom
version 352766 (release)
luke-jr@raspberrypi /opt/vc/bin $ uname -a
Linux raspberrypi 3.2.27+ #285 PREEMPT Tue Nov 20 17:49:40 GMT 2012 armv6l GNU/Linux

2.9.7 takes about 2 hours to cause a system reboot. Digging though /var/log/messages shows this:

Dec 30 06:46:22 raspberrypi kernel: [18946.081057] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA
Dec 30 06:46:22 raspberrypi kernel: [20868.008194] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000$
Dec 30 07:36:23 raspberrypi kernel: [20868.008221] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA
Dec 30 07:36:23 raspberrypi kernel: [23869.190094] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000$
Dec 30 07:36:23 raspberrypi kernel: [23869.190144] smsc95xx 1-1.1:1.0: eth0: Error reading MII_ACCESS
Dec 30 09:53:58 raspberrypi kernel: [23869.190163] smsc95xx 1-1.1:1.0: eth0: Timed out reading MII reg 01
Dec 30 09:53:58 raspberrypi kernel: [32124.183193] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000$
Dec 30 11:30:46 raspberrypi kernel: [32124.183223] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA
Dec 30 11:30:46 raspberrypi kernel: [37932.079567] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000$
Dec 30 12:21:33 raspberrypi kernel: [37932.079597] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA
Dec 30 12:21:33 raspberrypi kernel: [40979.609688] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x0000$
Dec 30 14:23:10 raspberrypi shutdown[10330]: shutting down for system reboot
Dec 30 14:23:20 raspberrypi kernel: [40979.609716] smsc95xx 1-1.1:1.0: eth0: Error writing MII_ADDR

2.10.2 is now what I'm running (I kept on switching between the two to see which one would result in the most stable results...so far cgminer bfgminer (both version) has caused issues.

The thread starter also reported having COM errors with his BFL units with cgminer (latest build).

[allinvain]

Shit it's still doing it..

This sucks..

Can you post a closeup picture of your PI, so I can see the components...

I suppose I could. I'd have to take it out of its case and stop using it for mining for a bit, so it's a tiny bit of an inconvenience, but do you suppose you could learn something from that? Do you need _my_ pi pic or what exactly do you think you'll ascertain from a closeup pic? Damage to components?

[Luke-Jr]

Here is what I found. With cgminer 2.10.4 the comm error shows up. With bfgminer 2.9.4 it works but I believe the system is restarting so it's causing a system crash. bfgminer 2.10.1 is misreporting the hash rate for the bfl singles (at random)

I've been running 2.10.0 on my pi since it was released (with MMQ), and it seems to work fine with BFL (though I only just now moved it from my development system to the pi).
I built 2.9.7, and will let that run for a bit to test. How long does it usually take to reboot your pi?
After that, I can test the latest 2.10.x, but I don't expect any change from 2.10.0...

2.9.7 takes about 2 hours to cause a system reboot.

Hmm, well it's been 5 hours on 2.9.7 and no problems of any sort... trying BFG 2.10.2 now.

[allinvain]

Hmm, odd. I wonder why this happens only for me (as far as I know). 5 hours with 2.10.2 running without any problems...I will monitor this further.

Luke do you think that the fact that I have both Icarus and Bitforce miners is somehow relevant?

Could you also try cgminer 2.10.4 to see if you get any Comm errors from one of your Bitforce singles? That definitely happens for me with the latest cgminer build - the whole reason that caused me to look for an alternative to see if the same thing happens (ie to bfgminer).

[Luke-Jr]

Luke do you think that the fact that I have both Icarus and Bitforce miners is somehow relevant?

It shouldn't be, but I can try it I guess... Only have 1 Icarus though - what's your environment like?

Could you also try cgminer 2.10.4 to see if you get any Comm errors from one of your Bitforce singles? That definitely happens for me with the latest cgminer build - the whole reason that caused me to look for an alternative to see if the same thing happens (ie to bfgminer).

cgminer's Bitforce driver is based on bfgminer's, except they've added a bunch of bugs. I could try it next, but as long as bfgminer works, I don't see a point...

[allinvain]

Luke do you think that the fact that I have both Icarus and Bitforce miners is somehow relevant?

It shouldn't be, but I can try it I guess... Only have 1 Icarus though - what's your environment like?

4 Icarus boards and 3 BFL singles. All connected to a 10 port USB (powered) hub. USB Hub is one of those generic ones you find everywhere - got it off of ebay:

Code:

http://i.ebayimg.com/00/s/NjAwWDYwMA==/$(KGrHqN,!h0FBI9ToPqkBQVurqwerg~~60_3.JPG

Raspberry Pi is not doing anything else other than managing the fpga miners. No keyboard or mouse is attached to the Pi. USB hub is connected to the lower usb port (bottom one).

I'm running bfgminer with the following argument (all pretty standard from what I'm aware):

bfgminer -c /home/btc/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB4 -S /dev/ttyUSB5 -S /dev/ttyUSB6

Could you also try cgminer 2.10.4 to see if you get any Comm errors from one of your Bitforce singles? That definitely happens for me with the latest cgminer build - the whole reason that caused me to look for an alternative to see if the same thing happens (ie to bfgminer).

cgminer's Bitforce driver is based on bfgminer's, except they've added a bunch of bugs. I could try it next, but as long as bfgminer works, I don't see a point...
[/quote]

Surprisingly bfgminer 2.10.2 has been running for 8 hours now without any issues. Lol maybe I should just leave it alone. Still I'm really curious to at least know with a reasonable amount of certainty what was causing these instability issues for me.

Hmm, if you say there are bugs in cgminer's bitforce driver that could explain the comm errors me and the OP have been getting. However 2.9.4 causing a system reboot (or causing a system even like large cpu load or something that is causing this mining distro's watchdog daemon to reboot the system) is bizzare. I would be nice if someone else can verify my experience. Perhaps the OP will give 2.9.4 a try and see if the same thing happens for him.

[allinvain]

lol

https://bitcointalk.org/index.php?topic=123146.new;boardseen#new

*facepalm* should've waited/did some more research before buying one of these things expressly for miner management purposes.

[Luke-Jr]

Luke do you think that the fact that I have both Icarus and Bitforce miners is somehow relevant?

It shouldn't be, but I can try it I guess... Only have 1 Icarus though - what's your environment like?

4 Icarus boards and 3 BFL singles. All connected to a 10 port USB (powered) hub. USB Hub is one of those generic ones you find everywhere - got it off of ebay:

Code:

http://i.ebayimg.com/00/s/NjAwWDYwMA==/$(KGrHqN,!h0FBI9ToPqkBQVurqwerg~~60_3.JPG

My own experience with USB hubs has been that 99% of them are crap, and the remaining 1% cannot be uniquely identified before plugging them in.

I'm running bfgminer with the following argument (all pretty standard from what I'm aware):

bfgminer -c /home/btc/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB4 -S /dev/ttyUSB5 -S /dev/ttyUSB6

If you build bfgminer with libudev support (install libudev-dev and re-run configure), you can drop all the -S options and let it autodetect.

Could you also try cgminer 2.10.4 to see if you get any Comm errors from one of your Bitforce singles? That definitely happens for me with the latest cgminer build - the whole reason that caused me to look for an alternative to see if the same thing happens (ie to bfgminer).

cgminer's Bitforce driver is based on bfgminer's, except they've added a bunch of bugs. I could try it next, but as long as bfgminer works, I don't see a point...

Surprisingly bfgminer 2.10.2 has been running for 8 hours now without any issues. Lol maybe I should just leave it alone. Still I'm really curious to at least know with a reasonable amount of certainty what was causing these instability issues for me.

If 2.10.2 proves stable (give it a few days, just to be sure?), you could easily debug the problem further using git bisect in reverse: you tell it the known-working version is "bad", the known-problematic version is "good", and it will give you a series of commits between the bad and good ones (it's smart about minimizing how many of these) to test and report back on (remember to invert the bad/good, since bisect was designed for looking for regressions, not fixes); you'd also need to be careful to run autogen for each commit and note whether it builds bfgminer or cgminer. Eventually, bisect will tell you which commit fixed your problem.

Hmm, if you say there are bugs in cgminer's bitforce driver that could explain the comm errors me and the OP have been getting. However 2.9.4 causing a system reboot (or causing a system even like large cpu load or something that is causing this mining distro's watchdog daemon to reboot the system) is bizzare. I would be nice if someone else can verify my experience. Perhaps the OP will give 2.9.4 a try and see if the same thing happens for him.

Numerous fixes have been added to 2.9.x between 2.9.4 and 2.9.7, so I would focus on the latter (if not 2.10.x). In my experience, usually watchdog resets triggered by software are caused by excessive swapping - which would suggest a memory leak. I do test for memory leaks most releases, but it's possible 2.9.4 was one of the times I forgot to check before releasing.

[allinvain]

Well, bummer, system rebooted even with bfgminer 2.10.2 after 9 hours of uptime

[Luke-Jr]

Well, bummer, system rebooted even with bfgminer 2.10.2 after 9 hours of uptime

Is it possible your Pi isn't getting enough power itself? An ordinary USB charger won't have enough, it has to be able to provide 1A (on the one port, not across all N ports).

[crazydownloaded]

Well, bummer, system rebooted even with bfgminer 2.10.2 after 9 hours of uptime

My system is very stable and never reboots by itself.
I'm using those power adapters: http://www.amazon.fr/gp/product/B002SQE2FS/ref=oh_details_o05_s00_i00
On the 2 USB ports, I've:
- USB Wifi http://www.amazon.fr/gp/product/B003MTTJOY/ref=oh_details_o00_s01_i00
- USB Hub http://www.amazon.fr/gp/product/B004SOTVB8/ref=oh_details_o00_s02_i00 where my 2 BFL singles are plugged

However I do have the comm problems from time to time (yesterday > 10 hours without any, don't had any for the moment). I've added a cronjob to reboot the system every 12 hours (might decrease the interval in the future), so even if it crashes it's not that bad.

I noticed that rpi-update can only be run once, which is very strange (when I try to run it now it never finishes, hanging on "Updating firmware (this will take a few minutes)").

[allinvain]

Well time to stop using it at least temporarily until I figure out the cause. It could be the power adapter or the usb hub. Never had any problems with the usb hub though. I still suspect the actual Pi itself. I'm going to see if I can RMA it.

[O_Shovah]

Well time to stop using it at least temporarily until I figure out the cause. It could be the power adapter or the usb hub. Never had any problems with the usb hub though. I still suspect the actual Pi itself. I'm going to see if I can RMA it.

The problem of the rasberry Pi restarting randomly on its own is well known.
I experience it myself from time to time

This little board will provide some alternative to the rasberry
http://cubieboard.org/
Might be worth to have a look for you too.

[nethead]

Well time to stop using it at least temporarily until I figure out the cause. It could be the power adapter or the usb hub. Never had any problems with the usb hub though. I still suspect the actual Pi itself. I'm going to see if I can RMA it.

The problem of the rasberry Pi restarting randomly on its own is well known.
I experience it myself from time to time

This little board will provide some alternative to the rasberry
http://cubieboard.org/
Might be worth to have a look for you too.

That thing is interesting, i think more interesting than rpi!