Linux mining distro for the Raspberry PI - MinePeon

[stellan0r]

Yes, either that or cough up extra cash. Sometime I order from Ebay, if I am prepared to wait ~3 weeks to receive the goods (they need to clear customs). And on a couple of occasions I had to document that the goods I purchased really cost as little as they did (2 more weeks were added to processing time on top).

I'm pretty sure we could find a way to deal with that problem

[1715027045]

1715027045

[1715027045]

1715027045

[1715027045]

1715027045

[ct1aic]

At the start of the "donation period", today @ 12:00:

Status
Pools
No pools loaded
Devices
No devices running

Ok, going back to a older version.

[stellan0r]

Ok, going back to a older version.

would you mind to tell us (me  ) what you did change after going back to the older version (0.2.2?)

upgrade cgminer? install that usb lcd screen driver?

Thanks

[ct1aic]

Ok, going back to a older version.

would you mind to tell us (me   ) what you did change after going back to the older version (0.2.2?)

upgrade cgminer? install that usb lcd screen driver?

Thanks

The only update I did after storing MinePeon 0.2.3a image in the SD, was the cgminer update to version 3.4.0. Nothing more. I'm still in that version, as I'm still at work (but I have access to the RPI @ home).

[stellan0r]

ah ok thought you are going back from 0.2.3a to 0.2.2

[Scorpia]

At the start of the "donation period", today @ 12:00:

Status
Pools
No pools loaded
Devices
No devices running

Ok, going back to a older version.

it looks like it did the donations and then restarted. did it restart properly?

but maybe im reading the graph wrong.

Also after switching hubs my 2 Rpi's are still up. one is over 24 hours and the other is over 22hours.
im going to move the 2 hubs to one Rpi. and then see how it goes.

[ct1aic]

At the start of the "donation period", today @ 12:00:

Status
Pools
No pools loaded
Devices
No devices running

Ok, going back to a older version.

it looks like it did the donations and then restarted. did it restart properly?

but maybe im reading the graph wrong.

Also after switching hubs my 2 Rpi's are still up. one is over 24 hours and the other is over 22hours.
im going to move the 2 hubs to one Rpi. and then see how it goes.

At 12:17, more or less, I detected that message... "No pools loaded...No devices running".

[Scorpia]

I really think there is an Issue with the new Arch and certain Hubs, Am short on ports until my new hubs arrive.
I will be able to runs some test and experiments once I have the new hubs.

Edit: I now have most of my set up on the good hubs running on 0.2.3(a)
the bad hub works perfect, running 7 erupters on 0.2.2 (completely unstable on 0.2.3a, and destabilizes the other hubs)

Glad I brought that second PI  

do you get some sort of crash message on the screen before the system reboots?
when mine reboots it seems to crash with some sort of message on the screen and then does a reboot.

Ill try and get a picture of the error message.

ok now im confused.

After running 2 different Rpi' with single 4 port hubs with 3 erupters each for 24 Hours+, 1 on lan and one on wlan. I thought it was stable.

So I tried to get back to one Pi.
I disconnected one hub and connected it to the other Pi. and within 2 mins crashed again. no matter how I connect the 2 hubs to either PI I cannot get the 2 hubs stable for more than a minute or 2.

both Rpi's are running off separate power supplies, 2 different brands with 2 different USB cables.
So now im confused. but I did manage to get a picture of the crash message. hopefully that can shed some light on it. I will try and upload it soon.

Keeping in mind this was running ok on 0.2.2

anyone have any thoughts?

ok here is the error message

https://plus.google.com/u/0/photos?pid=5915321738049808162&oid=105344068676932042280

I hope you can see the picture on that link.

[southerngentuk]

I had similar, before 0.2.3 was released I would pull and update arch and pyusb.
Everything would go ok and look good until a reboot then it would go all screwy.

I am sure a resent change in Arch or pyusb has created an incompatibility with some hubs.

[dave111223]

0.2.3a is really unstable running 31 USB block erupters for me it crashes after about 2 minutes (HW errors build over until whole board is litup and miner unresponsive).

Like the new slick web interface though.

Rolled back to 0.2.2 everything working again.

[southerngentuk]

0.2.3a is really unstable running 31 USB block erupters for me it crashes after about 2 minutes (HW errors build over until whole board is litup and miner unresponsive).

Like the new slick web interface though.

Rolled back to 0.2.2 everything working again.

Would you share what hubs you are using and maybe swap them about a bit if you have more than one type..and some spare time.

[btc-buddha]

So far so good on this new version 0.2.3a.  Excellent work on the Advanced interface.  I'm successfully running 10 Block Interrupters on a two D-Link H7 hubs (5 on each) with a fan blowing cool mountain air across makeshift aluminum tape heat-sinks that definitely help them keep cool to the touch.

I wonder if we could maybe standardize the timezone to be UTC? 

Thanks for all that you do,
Bitcoin Buddha   

[ct1aic]

0.2.3a is really unstable running 31 USB block erupters for me it crashes after about 2 minutes (HW errors build over until whole board is litup and miner unresponsive).

Like the new slick web interface though.

Rolled back to 0.2.2 everything working again.

Same to me. RPI crashed @ 01:02:06, after several problems accessing the 18 USB Block Erupters:

cgminer version 3.4.0 - Started: [2013-08-23 19:34:23]
--------------------------------------------------------------------------------
 (5s):6.108G (avg):6.039Gh/s | A:27464  R:23  HW:302  WU:84.9/m
 ST: 2  SS: 0  NB: 31  LW: 45284  GF: 0  RF: 0
 Connected to stratum.triplemining.com diff 2 with stratum as user ct1aic_RaspberryPi
 Block: 004bd716cf9301bb...  Diff:50.8M  Started: [00:57:28]  Best share: 15.1K
--------------------------------------------------------------------------------
 (P)ool management (S)ettings (D)isplay options (Q)uit
 AMU  0:                | 246.2M/335.4Mh/s | A:1475 R:0 HW:13 WU: 4.6/m
 AMU  1:                | 279.7M/335.2Mh/s | A:1490 R:0 HW:14 WU: 4.5/m
 AMU  2:                | 335.2M/335.5Mh/s | A:1499 R:0 HW:19 WU: 4.8/m
 AMU  3:                | 279.8M/335.0Mh/s | A:1518 R:2 HW:16 WU: 4.7/m
 AMU  4:                | 256.4M/335.7Mh/s | A:1544 R:0 HW:12 WU: 4.6/m
 AMU  5:                | 280.8M/335.4Mh/s | A:1502 R:2 HW:23 WU: 4.6/m
 AMU  6:                | 283.9M/335.9Mh/s | A:1664 R:0 HW:21 WU: 4.9/m
 AMU  7:                | 335.0M/335.4Mh/s | A:1492 R:0 HW:17 WU: 4.6/m
 AMU  8:                | 395.2M/336.0Mh/s | A:1543 R:2 HW:21 WU: 4.7/m
 AMU  9:                | 280.0M/336.1Mh/s | A:1656 R:0 HW:24 WU: 5.0/m
 AMU 10:                | 287.9M/335.2Mh/s | A:1458 R:0 HW:19 WU: 4.6/m
 AMU 11:                | 312.3M/335.9Mh/s | A:1528 R:4 HW:14 WU: 4.7/m
 AMU 12:                | 279.7M/335.3Mh/s | A:1480 R:0 HW:14 WU: 4.7/m
 AMU 13:                | 238.5M/335.8Mh/s | A:1474 R:2 HW:12 WU: 4.5/m
 AMU 14:                | 359.2M/336.1Mh/s | A:1520 R:6 HW:18 WU: 4.7/m
 AMU 15:                | 326.9M/335.4Mh/s | A:1585 R:2 HW:15 WU: 4.8/m
 AMU 16:                | 334.2M/335.1Mh/s | A:1504 R:2 HW:14 WU: 4.7/m
 AMU 17:                | 382.8M/335.7Mh/s | A:1532 R:0 HW:17 WU: 4.9/m
--------------------------------------------------------------------------------

 [2013-08-24 01:02:05] AMU4: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:05] AMU5: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:05] AMU3: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU1: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU12: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU6: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU17: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU13: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU16: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU8: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU14: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU0: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU9: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU7: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] AMU4: Comms error (werr=-7 amt=0)
 [2013-08-24 01:02:06] Accepted 5b19b730 Diff 2/2 AMU 10 pool 0

Luckily I had to pee and restarted the RPI @ 02:24. Since then, the MinePeon 0.2.3a is working fine.

I don't know how to do next... Trying to maintain this new version and see what happens next or going back to 0.2.2 and make all git pull's except to the Arch Linux. But don't know if that way, I still have the LCDStats python program started with the RPI.

Help me on this, Neil.

[kano]

I've sent a pull request to cardcomm with a few more updates to the LCD code:
https://github.com/cardcomm/cgminerLCDStats/pull/5

add a port option so you don't have to edit the code to change the port number
a hack to display the Avg/Block line in Red if you find a block
fix the pool selection so it always finds the correct pool to display at the top left
(it ignored non stratum pools)

[ct1aic]

I've sent a pull request to cardcomm with a few more updates to the LCD code:
https://github.com/cardcomm/cgminerLCDStats/pull/5

add a port option so you don't have to edit the code to change the port number
a hack to display the Avg/Block line in Red if you find a block
fix the pool selection so it always finds the correct pool to display at the top left
(it ignored non stratum pools)

Help... I'm a Linux retarded...

minepeon@minepeon /opt/minepeon/modules/cgminerLCDStats $ git pull https://github.com/kanoi/cgminerLCDStats master
warning: no common commits
remote: Counting objects: 237, done.
remote: Compressing objects: 100% (105/105), done.
remote: Total 237 (delta 138), reused 231 (delta 132)
Receiving objects: 100% (237/237), 1.59 MiB | 443.00 KiB/s, done.
Resolving deltas: 100% (138/138), done.
From https://github.com/kanoi/cgminerLCDStats
 * branch            master     -> FETCH_HEAD

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <minepeon@minepeon.(none)>) not allowed
minepeon@minepeon /opt/minepeon/modules/cgminerLCDStats $ git config --global user.email "bitcoin.PT@gmail.com"
minepeon@minepeon /opt/minepeon/modules/cgminerLCDStats $ git config --global user.name "Rui Costa"
minepeon@minepeon /opt/minepeon/modules/cgminerLCDStats $ git pull https://github.com/kanoi/cgminerLCDStats master
From https://github.com/kanoi/cgminerLCDStats
 * branch            master     -> FETCH_HEAD
Auto-merging README.md
CONFLICT (add/add): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
minepeon@minepeon /opt/minepeon/modules/cgminerLCDStats $

[kano]

My pull request is on cardcomm's current master
So maybe you need to update to his master first? (git pull)

[netfun2000]

going back to windows.

[southerngentuk]

I don't know how to do next... Trying to maintain this new version and see what happens next or going back to 0.2.2 and make all git pull's except to the Arch Linux. But don't know if that way, I still have the LCDStats python program started with the RPI.

Help me on this, Neil.

Go back to your last good SD card, assuming you rotate them like I do   ok probably not.
Go back to stock, live without that cute lcd for a week or so and.......
do what I did, but a second PI, update and go through hub at a time transferring to the new PI

I bet 0.05 BTC it's a hub/arch conflict   edit : or hub/pyusb


---------------------------------------
My 0.2.3a has now been up for 1d 5h, has gone through the donation window without a hitch..

The suspect hub is happily mining away 0.2.2 with 7 erupters for the same time.. ( no donation, as its goes screwy )

[ct1aic]

I don't know how to do next... Trying to maintain this new version and see what happens next or going back to 0.2.2 and make all git pull's except to the Arch Linux. But don't know if that way, I still have the LCDStats python program started with the RPI.

Help me on this, Neil.

Go back to your last good SD card, assuming you rotate them like I do   ok probably not.
Go back to stock, live without that cute lcd for a week or so and.......
do what I did, but a second PI, update and go through hub at a time transferring to the new PI

I bet 0.05 BTC it's a hub/arch conflict   edit : or hub/pyusb


---------------------------------------
My 0.2.3a has now been up for 1d 5h, has gone through the donation window without a hitch..

The suspect hub is happily mining away 0.2.2 with 7 erupters for the same time.. ( no donation, as its goes screwy )

Thanks for your help, southerngentuk.

I'm preparing a 0.2.2 MinePeon image, but with last version 3.4.0 of cgminer, LCDStats and MinePeon GUI, to see if the problem is from the newer Arch Linux.

[southerngentuk]

Thanks for your help, southerngentuk.

I'm preparing a 0.2.2 MinePeon image, but with last version 3.4.0 of cgminer, LCDStats and MinePeon GUI, to see if the problem is from the newer Arch Linux.

no worries, just be cautious of the python usb, if its not the arch its has to be that. ( disclaimer : note am a newbie to linux so probably wrong)