USB ASIC ERUPTER - Setup & Config. BCG Miner, cgminer & Hubs "Oh Pi"!

[sdz123]

So I got a kinda weird issue.

I started mining on my Raspberry Pi (O/S: Raspian) with 5 Block Eruptors on a DLink DUB-7 on August 19th using cgminer 3.3.4 and followed the included instructions on how to compile the libusb libraries myself. It worked great and it ran non-stop for a few weeks. The other day I decided to update cgminer to 3.4.2. After mining for about 20 minutes the Pi seemed to locked up. My SSH session died and I couldn't ping the Pi anymore. I figured it was just a fluke so I restarted the Pi but, again, after mining for about 20 minutes the Pi locks up.

I figured that this must have just been an issue with the newest version of cgminer so I went back to 3.3.4 with no luck. 3.3.4 now causes the Pi to lock up as well. I thought that maybe the Pi was overheating so I tried doing something else intensive; watching a 1080p movie over my LAN for 2hrs+ but it worked great and never locked up. I also tried mining just with 1 miner but the Pi still locked up.

Perhaps there is an issue with the newest packages for the Pi? How can I provide some more detailed info to see what is going on? Anything else I can try to resolve the issue?

I've also posted this issue in the cgminer thread https://bitcointalk.org/index.php?topic=28402.msg3121424#msg3121424

I'm getting the same problem here. Everything was running fine for weeks until I decided to apt-get update; apt-get upgrade the Pi and recompile from cgminer v3.3.1 to v3.4.3. I've also tried reverting to v3.3.1 and I still get a problem. This only seems leaves one of the raspbian (jessie) updates as the possible culprit.

[kano]

The network connection is USB also (on the motherboard of course)
You will most likely find in the system log a comment about the network device failing.

On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway

Sounds like Raspbian have screwed up something there with the update

The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)

[sdz123]

The network connection is USB also (on the motherboard of course)
You will most likely find in the system log a comment about the network device failing.

On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway

Sounds like Raspbian have screwed up something there with the update

The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)

Interesting. Makes sense. Could you share your cron job ? It's not ideal but should get me hashing again until Raspbian gets a fix.

The last few entires in my syslog before I have to hard reset is as follows :

Sep 20 16:00:22 raspberrypi kernel: [   59.983209] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [   59.983245] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [   59.983392] netlink: 20 bytes leftover after parsing attributes.

I have done some more testing. I can't get the RPi to loose its network connectivity and need resetting apart from when running cgminer. I've tried hammering the NIC with heavy downloading and it handles it fine. I've removed all but 3 Block Erupter USB's just in case it was a power issue but it's not. Im running a D-Link DUB-H7 with 5 Erupter's total.

I wonder whats so specific about cgminer that causes the nic to hang under the current Raspbian...

[-ck]

The network connection is USB also (on the motherboard of course)
You will most likely find in the system log a comment about the network device failing.

On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway

Sounds like Raspbian have screwed up something there with the update

The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)

Interesting. Makes sense. Could you share your cron job ? It's not ideal but should get me hashing again until Raspbian gets a fix.

The last few entires in my syslog before I have to hard reset is as follows :

Sep 20 16:00:22 raspberrypi kernel: [   59.983209] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [   59.983245] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [   59.983392] netlink: 20 bytes leftover after parsing attributes.

I have done some more testing. I can't get the RPi to loose its network connectivity and need resetting apart from when running cgminer. I've tried hammering the NIC with heavy downloading and it handles it fine. I've removed all but 3 Block Erupter USB's just in case it was a power issue but it's not. Im running a D-Link DUB-H7 with 5 Erupter's total.

I wonder whats so specific about cgminer that causes the nic to hang under the current Raspbian...

It's the combination of using other USB devices and networking, as internally the network device is effectively just another USB device.

[kano]

...
Interesting. Makes sense. Could you share your cron job ? It's not ideal but should get me hashing again until Raspbian gets a fix.
...

I have a program I wrote > 10 years ago (sem) that simply does nothing in the case (in this example) that the script tries to run twice at the same time - so this script would require a bit of work to get it going ... but anyway here's the concept:

Code:

#!/bin/bash
#
#set -x
#
sem="/root/chkpisem"
#
if [ "$1" != "boo" ] ; then
 touch "$sem"
 /root/sem -q "$sem" "$0" "boo" >> /root/chkpi.log 2>&1
 exit 0
fi
#
last="/root/lastchkpi"
#
ip1="192.168.?.?"
ip2="192.168.?.?"
ip3="192.168.?.?"
#
chk()
{
 ping -n -w 5 -c 1 "$1" 2>&1
 r="$?"

 if [ "$r" == "0" ] ; then
	echo -e "`date "+%s"`\nLast Valid Ping to $1: `date`" > "$last"
	# stop checking as soon as we find one
	exit 0
 fi
}
#
# In case of network delays during system startup
sleep 60
#
chk "$ip1" > /dev/null
chk "$ip2" > /dev/null
chk "$ip3" > /dev/null
#
now="`date "+%s"`"
lst="`head -1 "$last"`"
#
dif="`echo "$now $lst - p" | dc`"
#
# 5 minutes
if [ "$dif" -gt "299" ] ; then
 date
 echo "No ping for 5 minutes (dif=$dif) ..."
 chk "$ip1"
 chk "$ip2"
 chk "$ip3"
 echo "Shutting down ..."
 /root/cgdown
fi

And then the cgdown script - though I could update this to use Multicast - but I haven't
It just sends a 'quit' to all ports 4020 to 4049

Code:

#!/bin/bash
#
echo "`date`: CGDOWN"
#
i="4020"
while [ "$i" -lt "4050" ] ; do
 echo "127.0.0.1 $i"
 echo -n quit | nc -4 -w 1 127.0.0.1 $i
 i=$[$i+1]
done
#
echo "`date` sleep 10"
sleep 10
#
date
#
echo "shutdown -h now"
shutdown -h now

The whole process is quite slow - but the point is that rather than having to switch it off if you don't have a keyboard+screen, it will do it itself.
You could of course change it to "shutdown -r now" - though if the network didn't came back up alive it would keep doing it over and over.

There are probably better ways to do this - but this one is pretty simple

[Professor James Moriarty]

 I always wonder when was the first time someone said 'dude I bet if I move this here and buzz it here and jibrz here , I can get more hash from this thing' I mean that dude must be a little crazy in the head to jeoperdize a miner with playing , who can guarentee that it wont break

[420]

TO dispell overheating issues

i run 10 side by side very close, no fan, in 80deg ambient