allinvain
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 30, 2012, 03:20:17 PM |
|
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).
|
|
|
|
allinvain
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 31, 2012, 12:21:52 AM |
|
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
|
|
December 31, 2012, 12:47:58 AM |
|
Shit it's still doing it.. This sucks.. Can you post a closeup picture of your PI, so I can see the components...
|
BTC:1PCTzvkZUFuUF7DA6aMEVjBUUp35wN5JtF
|
|
|
Bigal
|
|
December 31, 2012, 01:24:14 AM |
|
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 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
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
December 31, 2012, 01:57:42 AM |
|
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
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 31, 2012, 04:34:11 AM |
|
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 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
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 31, 2012, 04:42:48 AM |
|
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/Linux2.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
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 31, 2012, 05:34:24 AM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
December 31, 2012, 07:03:13 AM |
|
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
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 31, 2012, 08:27:48 AM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
December 31, 2012, 08:46:40 AM |
|
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
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 31, 2012, 11:32:57 AM |
|
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: 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.
|
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
December 31, 2012, 11:45:02 AM |
|
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: 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
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 31, 2012, 12:39:45 PM |
|
Well, bummer, system rebooted even with bfgminer 2.10.2 after 9 hours of uptime
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
December 31, 2012, 01:29:18 PM |
|
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).
|
|
|
|
|
allinvain
Legendary
Offline
Activity: 3080
Merit: 1080
|
|
December 31, 2012, 02:07:43 PM |
|
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
Sr. Member
Offline
Activity: 410
Merit: 252
Watercooling the world of mining
|
|
January 03, 2013, 06:49:54 PM |
|
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
|
|
January 03, 2013, 07:19:42 PM |
|
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!
|
|
|
|
|