Topic: Raspberry Pi / cgminer for your BFL BitForce - page 2. (Read 20691 times)

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)").

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).

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

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.

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.

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.

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.

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.

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:
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



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.

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

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...

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).

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

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?

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).

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

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

This is what I get



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

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

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)

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).

Shit it's still doing it..

This sucks..

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

latest firmware running..let's hope this fixes it..

Some tips for you folks that are thinking of doing the same thing. First the rpi-update script passes a bunch of command argument (git, etc) with the --quiet flag. If you want to know what it's doing edit the script (rpi-update is a bash script) and remove the "--quiet" flags.

sudo apt-get update
sudo apt-get upgrade -y
sudo sync && sudo shutdown -r now
sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update

If you get an error message regarding certificates

sudo apt-get install ca-certificates

and then rerun rpi-update

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..