sidehack
Legendary
 Offline
Activity: 3318
Merit: 1848
Curmudgeonly hardware guy
|
 |
December 12, 2017, 05:03:25 PM |
|
If you're not using cgminer with VH's driver from the first post of this thread, the 2Pac stick won't work. I don't know what compatibility requirements there are between cgminer and your work source, but first make sure you're using the right cgminer.
|
|
|
|
|
|
|
|
|
|
|
You can see the statistics of your reports to moderators on the "Report to moderator" pages.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
bitcointhor
Newbie
Offline
Activity: 3
Merit: 0
|
|
December 12, 2017, 11:11:00 PM |
|
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
|
|
|
|
|
Biodom
Legendary
Offline
Activity: 3752
Merit: 3869
|
|
December 13, 2017, 12:13:19 AM |
|
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
Do you have any logs to post? Which hub? Apart from this, maybe use an Arctic fan (or any other fan pretty much) and point it to sticks. Second, separate the sticks, if possible (have a slot in between). |
|
|
|
|
NoComply
Newbie
Offline
Activity: 43
Merit: 0
|
|
December 13, 2017, 12:17:10 AM |
|
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I get lockups with my zero on the odd occasion, I've never really found a solution. Running cgminer with the real-quiet and net-delay switches helped a lot though. Other than that, I've read suggestions that it could be: the pi hitting a ram limit, possibly a usb library hiccup, maybe sd card quality, but none seemed definitive. There's some old (different hw) discussion here which might shed some light, or maybe one of this thread's veterans might be able to chime in with something more concrete that I might have missed in this thread. |
|
|
|
|
DKirk
Newbie
Offline
Activity: 61
Merit: 0
|
|
December 13, 2017, 12:21:06 AM |
|
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem. I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time. |
|
|
|
|
|
vh (OP)
|
|
December 13, 2017, 01:13:11 AM
Last edit: December 13, 2017, 01:32:41 AM by vh |
|
OS X El Capitan (10.11.6) /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew doctor
brew tap vthoang/cgminer
brew install cgminer
#if no errors: $ cgminer -n
[2017-12-12 17:08:23.377] USB all: found 8 devices - listing known devices
.USB dev 0: Bus 20 Device 24 ID: 10c4:ea60
Manufacturer: 'GekkoScience'
Product: '2Pac BM1384 Bitcoin Miner'
[2017-12-12 17:08:23.378] 1 known USB devices
cgminer -o stratum+tcp://pool.ckpool.org:3333 -u 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr -p x --suggest-diff 32
 |
|
|
|
bitcointhor
Newbie
Offline
Activity: 3
Merit: 0
|
|
December 13, 2017, 03:13:06 AM |
|
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem. I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time. Yes, this is pretty much exactly what is happening to me. Did you happen to be watching the hashrate at the time? I'm not sure how to troubleshoot it or where to start. |
|
|
|
|
smsscott
Newbie
Offline
Activity: 5
Merit: 0
|
|
December 13, 2017, 08:26:32 AM |
|
i installed cgminer on a Pi as per first post with gekko 2 PAC i can not figure out how to start mining.
my old command that i used now does not do anything
sudo ./git/vthoang/cgminer --bmsc-options 115200:0.57 -o stratum+tcp://stratum.slushpool.com:3333-u smsscott.pi -p sailing --bmsc-voltage 0800 --bmsc-freq 1286
./cgminer -o stratum+tcp://stratum.slushpool.com:3333 -u smsscott.pi -p sailing –bxm-bits=56
cgminer -o stratum+tcp://stratum.slushpool.com:3333 -u smsscott.pi -p sailing
git/vthoang/cgminer/cgminer.c -o stratum+tcp://stratum.slushpool.com:3333 -u smsscott.pi -p sailing
none of these will start cgminer what do i have wrong....?
i am new to Pi and mining i had installed cgminer with out the gekko support and could not enable 2 PAC stick it was in cgminer directory not like this one which is in the
"git/vthoang/cgminer" directory...? not cgminer directory like before
can anyone help me please....?
|
|
|
|
|
sidehack
Legendary
Offline
Activity: 3318
Merit: 1848
Curmudgeonly hardware guy
|
|
December 13, 2017, 01:17:21 PM |
|
as per first post
Are you sure about this part? Because everything you just said doesn't make sense with the info given in the first post. There are sample command lines given in the first post, complete with options for adjusting frequency and stuff. |
|
|
|
DKirk
Newbie
Offline
Activity: 61
Merit: 0
|
|
December 13, 2017, 01:21:35 PM |
|
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem. I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time. Yes, this is pretty much exactly what is happening to me. Did you happen to be watching the hashrate at the time? I'm not sure how to troubleshoot it or where to start. All I remember seeing is one stick registering as "SICK" and the others slowly reducing their hashrate. I remember seeing two around 800 MH/s and I think another was 200... Another odd thing is that after I stopped cgminer and attempted to restart the Pi using sudo reboot, it didn't restart. Once again I had to pull the plug and do a hard restart then as always everything started working again no problem. I wish I could figure it out but I just don't know enough yet to narrow it down further. I did re-flash the raspian image about a month ago to see if it would help but that didn't do anything. |
|
|
|
|
bitcointhor
Newbie
Offline
Activity: 3
Merit: 0
|
|
December 13, 2017, 04:28:40 PM |
|
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem. I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time. Yes, this is pretty much exactly what is happening to me. Did you happen to be watching the hashrate at the time? I'm not sure how to troubleshoot it or where to start. All I remember seeing is one stick registering as "SICK" and the others slowly reducing their hashrate. I remember seeing two around 800 MH/s and I think another was 200... Another odd thing is that after I stopped cgminer and attempted to restart the Pi using sudo reboot, it didn't restart. Once again I had to pull the plug and do a hard restart then as always everything started working again no problem. I wish I could figure it out but I just don't know enough yet to narrow it down further. I did re-flash the raspian image about a month ago to see if it would help but that didn't do anything. I pulled up the info in /var/log/syslog and it shows this.... Dec 12 22:17:58 rPints snmpd[417]: Connection from UDP: [192.168.0.138]:46897->[192.168.0.121]:161
Dec 12 22:17:58 rPints snmpd[417]: Connection from UDP: [192.168.0.138]:49198->[192.168.0.121]:161
Dec 12 22:18:01 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:06 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:11 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:16 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:21 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:26 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:31 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:36 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:41 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:46 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Dec 12 22:17:12 rPints systemd-modules-load[117]: Inserted module 'i2c_dev'
Dec 12 22:17:12 rPints fake-hwclock[107]: Wed 13 Dec 06:17:01 UTC 2017
Dec 12 22:17:12 rPints systemd-fsck[111]: e2fsck 1.43.4 (31-Jan-2017)
Dec 12 22:17:12 rPints systemd-fsck[111]: Superblock last mount time (Tue Dec 12 13:17:01 2017,
Dec 12 22:17:12 rPints kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Dec 12 22:17:12 rPints kernel: [ 0.000000] Linux version 4.9.60-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #1048 SMP Fri Nov 3 16:05:21 GMT 2017
Dec 12 22:17:12 rPints kernel: [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d at which point i stopped responding to snmp/ping. this morning i did a hard reset/unplug and the next entries are.... Dec 12 22:17:33 rPints vncserver-x11[431]: AgentInitCheck: agent comms failure
Dec 12 22:17:38 rPints vncserver-x11[431]: AgentInitCheck: no response from agent
Dec 13 06:58:39 rPints systemd[1]: Time has been changed
Dec 13 06:58:39 rPints systemd[557]: Time has been changed I am guessing that there was something that caused the crash, and it rebooted. But then there are no entries from after the reboot until after I hard reset this morning. |
|
|
|
|
|
vh (OP)
|
|
December 14, 2017, 01:59:06 AM |
|
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem. I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time. Yes, this is pretty much exactly what is happening to me. Did you happen to be watching the hashrate at the time? I'm not sure how to troubleshoot it or where to start. All I remember seeing is one stick registering as "SICK" and the others slowly reducing their hashrate. I remember seeing two around 800 MH/s and I think another was 200... Another odd thing is that after I stopped cgminer and attempted to restart the Pi using sudo reboot, it didn't restart. Once again I had to pull the plug and do a hard restart then as always everything started working again no problem. I wish I could figure it out but I just don't know enough yet to narrow it down further. I did re-flash the raspian image about a month ago to see if it would help but that didn't do anything. Something worth reviewing and trying out if the kernel is going down: https://bitcointalk.org/index.php?topic=494625.msg5932931#msg5932931 |
|
|
|
smsscott
Newbie
Offline
Activity: 5
Merit: 0
|
|
December 14, 2017, 04:44:38 AM |
|
i have installed cgminer on RPi as per first post
cgminer starts but it does not detect my gekko 2 PAC sticks either 3 in a hub or just one alone in RPi
what could i be missing
any sugestions
|
|
|
|
|
Biodom
Legendary
Offline
Activity: 3752
Merit: 3869
|
|
December 14, 2017, 05:19:12 AM |
|
i have installed cgminer on RPi as per first post
cgminer starts but it does not detect my gekko 2 PAC sticks either 3 in a hub or just one alone in RPi
what could i be missing
any sugestions
how about one in a hub? have one in a hub, everything connected, then restart the pi, then start the cgminer. |
|
|
|
|
smsscott
Newbie
Offline
Activity: 5
Merit: 0
|
|
December 14, 2017, 05:39:35 AM |
|
i have installed cgminer on RPi as per first post
cgminer starts but it does not detect my gekko 2 PAC sticks either 3 in a hub or just one alone in RPi
what could i be missing
any sugestions
how about one in a hub? have one in a hub, everything connected, then restart the pi, then start the cgminer. [2017-12-13 21:37:04.857] Started cgminer 4.10.0 [2017-12-13 21:37:04.857] Loaded configuration file /home/pi/.cgminer/cgminer.c onf [2017-12-13 21:37:05.024] No devices detected! [2017-12-13 21:37:05.024] Waiting for USB hotplug devices or press q to quit [2017-12-13 21:37:05.024] Probing for an alive pool [2017-12-13 21:37:06.993] Pool 0 difficulty changed to 2048 [2017-12-13 21:37:07.036] Pool 1 difficulty changed to 2048 [2017-12-13 21:37:08.026] Network diff set to 1.59T |
|
|
|
|
|
vh (OP)
|
|
December 14, 2017, 05:54:03 AM |
|
Let's see what's connected: sudo cat /sys/kernel/debug/usb/devices | grep -E "^([TSPD]:.*|)$"
|
|
|
|
hercthx
Newbie
Offline
Activity: 52
Merit: 0
|
|
December 15, 2017, 05:26:48 PM
Last edit: December 15, 2017, 05:43:54 PM by hercthx |
|
https://i.imgur.com/X8LLLZF.jpgRunning an experiment, Trying with initial settings of 250Mhz*1.40v and changing to 225Mhz*1.46v to see if I can get better stability out of the 2pacs. So far temp with addition fan cooling and 5C ART has not changed, 45C probe reading at the heat-sink from 2pac at centre of array, 61C-65C IR reading from the 2pac boards outer row. I have noticed as well initial WU is down by 40 per 2pac. average per 2pac at 250/1.40 was 383, on restart at 225/1.46 showing 340, expecting that number to rise over the next few hours though. I'm wondering if anyone else has tried this, and what where your results?
|
|
|
|
|
|
vh (OP)
|
|
December 15, 2017, 05:48:34 PM |
|
...
I have noticed as well initial WU is down by 40 per 2pac. average per 2pac at 250/1.40 was 383, on restart at 225/1.46 showing 340, expecting that number to rise over the next few hours though.
I'm wondering if anyone else has tried this, and what where your results?
That appears in range. WU change is proportional to freq. About a 10% change in each there. more details: https://bitcointalk.org/index.php?topic=1764803.msg18329715#msg18329715 |
|
|
|
hercthx
Newbie
Offline
Activity: 52
Merit: 0
|
|
December 15, 2017, 05:53:26 PM |
|
...
I have noticed as well initial WU is down by 40 per 2pac. average per 2pac at 250/1.40 was 383, on restart at 225/1.46 showing 340, expecting that number to rise over the next few hours though.
I'm wondering if anyone else has tried this, and what where your results?
That appears in range. WU change is proportional to freq. About a 10% change in each there. more details: https://bitcointalk.org/index.php?topic=1764803.msg18329715#msg18329715Ahh, I see, so a lower freq at a higher voltage will not necessarily return a more stable workload, rather less work overall yeah? |
|
|
|
|
sidehack
Legendary
Offline
Activity: 3318
Merit: 1848
Curmudgeonly hardware guy
|
|
December 15, 2017, 06:11:14 PM |
|
Voltage has nothing to do with the workload, just the hardware's stability. In general, the higher the voltage at a given frequency, the more stable it'll be (until heat or junction breakdowns become an issue).
The amount of work done is proportional to the operating frequency. I see about WU 1.53/MHz with a 2-chip stick, so 225MHz should run about 344 - plus or minus, because USB traffic and pool latency and whatever.
|
|
|
|
|
