Search content
Sort by
Showing 11 of 11 results by fawasme
My X10 is doing something really strange.
All lights are ok, but the 3rd BLKU (number 2) it is not accepting jobs, while the other 2 are working just fine. CPU Count looks fine, Hasharate on Baikals Page looks fine, but of course on Zpool is only 6 or 7 GHZ instead of about 10.
Tried reflashing 1.2 Pizero Image, no results, tried different algos, different pools, same thing.
Any suggestions?
I do attach somewhat of my screenshot:
Name ID Algo Temp Total Chips Clock Hashrate 5s Hashrate av Accepted Rejected HW Errors Utility Last Share Time Identify
BKLU 0 Quarkcoin 39 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 38183 173 [0.45%] 0 [0.00%] 412.9646 02:39:12
BKLU 1 Quarkcoin 38 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 38192 182 [0.47%] 0 [0.00%] 413.062 02:39:12
BKLU 2 Quarkcoin 37 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 27 0 [0.00%] 0 [0.00%] 0.292 02:10:14
3 devsTotals 10.14 Gh/s 10.14 Gh/s 76402 355 [0.46%] 0 [0.00%] 826.3186
All lights are ok, but the 3rd BLKU (number 2) it is not accepting jobs, while the other 2 are working just fine. CPU Count looks fine, Hasharate on Baikals Page looks fine, but of course on Zpool is only 6 or 7 GHZ instead of about 10.
Tried reflashing 1.2 Pizero Image, no results, tried different algos, different pools, same thing.
Any suggestions?
I do attach somewhat of my screenshot:
Name ID Algo Temp Total Chips Clock Hashrate 5s Hashrate av Accepted Rejected HW Errors Utility Last Share Time Identify
BKLU 0 Quarkcoin 39 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 38183 173 [0.45%] 0 [0.00%] 412.9646 02:39:12
BKLU 1 Quarkcoin 38 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 38192 182 [0.47%] 0 [0.00%] 413.062 02:39:12
BKLU 2 Quarkcoin 37 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 27 0 [0.00%] 0 [0.00%] 0.292 02:10:14
3 devsTotals 10.14 Gh/s 10.14 Gh/s 76402 355 [0.46%] 0 [0.00%] 826.3186
Try to set difficulty on the pool in the password, d=20.
Thanks for your reply. No difference in seeting diff......Its kind of weird that the "Last Share Time" in the status page keeps showing 20:00:00 while the other BLKU ID show the proper time.....look
Devices
Name ID Algo Temp Total Chips Clock Hashrate 5s Hashrate av Accepted Rejected HW Errors Utility Last Share Time Identify
BKLU 0 Quarkcoin 41 °C 64 300MHz 3.379 Gh/s 3.408 Gh/s 12 0 [0.00%] 0 [0.00%] 3.4171 14:25:04
BKLU 1 Quarkcoin 41 °C 64 300MHz 3.379 Gh/s 3.405 Gh/s 9 0 [0.00%] 0 [0.00%] 2.5628 14:24:49
BKLU 2 Quarkcoin 40 °C 64 300MHz 3.379 Gh/s 3.405 Gh/s 0 0 [%] 0 [%] 0 20:00:00
3 devsTotals 10.14 Gh/s 10.22 Gh/s 21 0 [0.00%] 0 [0.00%] 5.9799
My X10 is doing something really strange.
All lights are ok, but the 3rd BLKU (number 2) it is not accepting jobs, while the other 2 are working just fine. CPU Count looks fine, Hasharate on Baikals Page looks fine, but of course on Zpool is only 6 or 7 GHZ instead of about 10.
Tried reflashing 1.2 Pizero Image, no results, tried different algos, different pools, same thing.
Any suggestions?
I do attach somewhat of my screenshot:
Name ID Algo Temp Total Chips Clock Hashrate 5s Hashrate av Accepted Rejected HW Errors Utility Last Share Time Identify
BKLU 0 Quarkcoin 39 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 38183 173 [0.45%] 0 [0.00%] 412.9646 02:39:12
BKLU 1 Quarkcoin 38 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 38192 182 [0.47%] 0 [0.00%] 413.062 02:39:12
BKLU 2 Quarkcoin 37 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 27 0 [0.00%] 0 [0.00%] 0.292 02:10:14
3 devsTotals 10.14 Gh/s 10.14 Gh/s 76402 355 [0.46%] 0 [0.00%] 826.3186
All lights are ok, but the 3rd BLKU (number 2) it is not accepting jobs, while the other 2 are working just fine. CPU Count looks fine, Hasharate on Baikals Page looks fine, but of course on Zpool is only 6 or 7 GHZ instead of about 10.
Tried reflashing 1.2 Pizero Image, no results, tried different algos, different pools, same thing.
Any suggestions?
I do attach somewhat of my screenshot:
Name ID Algo Temp Total Chips Clock Hashrate 5s Hashrate av Accepted Rejected HW Errors Utility Last Share Time Identify
BKLU 0 Quarkcoin 39 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 38183 173 [0.45%] 0 [0.00%] 412.9646 02:39:12
BKLU 1 Quarkcoin 38 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 38192 182 [0.47%] 0 [0.00%] 413.062 02:39:12
BKLU 2 Quarkcoin 37 °C 64 300MHz 3.379 Gh/s 3.380 Gh/s 27 0 [0.00%] 0 [0.00%] 0.292 02:10:14
3 devsTotals 10.14 Gh/s 10.14 Gh/s 76402 355 [0.46%] 0 [0.00%] 826.3186
OMGGGG BAIKALSS X10 ARE MAKING MOOOOONEEEY$$$$$$$$$ AND OTHER NEW ALGOS WILL KEEP THEM MAKING IT. MOST IMPORTANT, THEY JUST KEEP COOL, AND SILENT, AS ANY OTHER PC IN THE HOUSE....NOBODY KNOW YOU HAVE A DEVICE THAT IS MAKING YOUR LIFE EASIER, AS LONG AS YOU CAN MAKE THE MONEY TO PAY FOR IT! :-) THANK YOU BAIKAL!
GUYS PLEASE BEWARE!!!
I try to be as safe as I can while networking. But there is some "mofo", called "abbik84.x10", who is using the fact that people are updating Baikals, and he is getting into them, (cause password comes back to baikal, and root password too), it happened to me in a matter of 5 minutes or less. Got into my X10, (of course I had DMZ on my router on it and all that), but I just didnt have the chance to configure it again and this MOFO changed the root password, and made me impossible to configure back my X10, even though I was able to login and modify pools, but on Status page, his account will keep showing up on MPhub. I mean, I swear I cleared Browser Cache, went to different PC, went to Linux and checked again, and he will just keep mining in my X10.
Please confirm anybody who experienced something similar, I though for a while it was a Baikal´s tester username or something like that....
Of course I formatted, disabled DMZ and all that configured everything and Im back mining, but JUST BEWARE!!!
Cheers mates!, and stop arguing about how to make free money and get ur arse working!
I try to be as safe as I can while networking. But there is some "mofo", called "abbik84.x10", who is using the fact that people are updating Baikals, and he is getting into them, (cause password comes back to baikal, and root password too), it happened to me in a matter of 5 minutes or less. Got into my X10, (of course I had DMZ on my router on it and all that), but I just didnt have the chance to configure it again and this MOFO changed the root password, and made me impossible to configure back my X10, even though I was able to login and modify pools, but on Status page, his account will keep showing up on MPhub. I mean, I swear I cleared Browser Cache, went to different PC, went to Linux and checked again, and he will just keep mining in my X10.
Please confirm anybody who experienced something similar, I though for a while it was a Baikal´s tester username or something like that....
Of course I formatted, disabled DMZ and all that configured everything and Im back mining, but JUST BEWARE!!!
Cheers mates!, and stop arguing about how to make free money and get ur arse working!
I was having lots of problems too, always offline and found this on reddit: e1.verge-electrum.com (ssl, port 50003)
works
WORKED!!!works
Re: Baikal X10 ⚡OVERCLOCK⚡ Claim reward 0.2 BTC for TUTORIAL HOW TO :)⚡⚡⚡⚡
Hey guys,
two things to say,
We need to work on two things, overclocking to 420MHz and to recover the data of the two algorithms. missing:
1) Will upload to Mega the recovered data so you can see for yourself what you can work with..
2) Will it help (overclocking) this info found in the SD Image?
root@Baikal:/sys/bus/cpu/devices/cpu0/cpufreq# ls
affected_cpus cpuinfo_transition_latency scaling_governor
boot_lock dvfs_debug scaling_max_freq
cpuinfo_boot_freq related_cpus scaling_min_freq
cpuinfo_cur_freq scaling_available_governors scaling_setspeed
cpuinfo_max_freq scaling_cur_freq stats
cpuinfo_min_freq scaling_driver
---------------------------------
GNU nano 2.5.3 File: cpuinfo_cur_freq
816000
--
Also while messing with the terminal, an auto generated mail went to the root folder saying
Subject: *** SECURITY information for baikal ***
baikal : Feb 10 07:34:20 : www-data : user NOT in sudoers ; TTY=unknown ;$
From www-data@baikal Fri Feb 10 07:35:24 2017
Return-Path:
Received: from baikal (baikal [127.0.0.1])
by baikal (8.15.2/8.15.2/Debian-3) with ESMTP id v1A7ZOC3017405
for ; Fri, 10 Feb 2017 07:35:24 GMT
Received: (from www-data@localhost)
by baikal (8.15.2/8.15.2/Submit) id v1A7ZOLM017255;
Fri, 10 Feb 2017 07:35:24 GMT
Date: Fri, 10 Feb 2017 07:35:24 GMT
Message-Id: <201702100735.v1A7ZOLM017255@baikal>
To: root@baikal
From: www-data@baikal
Auto-Submitted: auto-generated
Subject: *** SECURITY information for baikal ***
baikal : Feb 10 07:34:24 : www-data : user NOT in sudoers ; TTY=unknown ;$
two things to say,
We need to work on two things, overclocking to 420MHz and to recover the data of the two algorithms. missing:
1) Will upload to Mega the recovered data so you can see for yourself what you can work with..
2) Will it help (overclocking) this info found in the SD Image?
root@Baikal:/sys/bus/cpu/devices/cpu0/cpufreq# ls
affected_cpus cpuinfo_transition_latency scaling_governor
boot_lock dvfs_debug scaling_max_freq
cpuinfo_boot_freq related_cpus scaling_min_freq
cpuinfo_cur_freq scaling_available_governors scaling_setspeed
cpuinfo_max_freq scaling_cur_freq stats
cpuinfo_min_freq scaling_driver
---------------------------------
GNU nano 2.5.3 File: cpuinfo_cur_freq
816000
--
Also while messing with the terminal, an auto generated mail went to the root folder saying
Subject: *** SECURITY information for baikal ***
baikal : Feb 10 07:34:20 : www-data : user NOT in sudoers ; TTY=unknown ;$
From www-data@baikal Fri Feb 10 07:35:24 2017
Return-Path:
Received: from baikal (baikal [127.0.0.1])
by baikal (8.15.2/8.15.2/Debian-3) with ESMTP id v1A7ZOC3017405
for ; Fri, 10 Feb 2017 07:35:24 GMT
Received: (from www-data@localhost)
by baikal (8.15.2/8.15.2/Submit) id v1A7ZOLM017255;
Fri, 10 Feb 2017 07:35:24 GMT
Date: Fri, 10 Feb 2017 07:35:24 GMT
Message-Id: <201702100735.v1A7ZOLM017255@baikal>
To: root@baikal
From: www-data@baikal
Auto-Submitted: auto-generated
Subject: *** SECURITY information for baikal ***
baikal : Feb 10 07:34:24 : www-data : user NOT in sudoers ; TTY=unknown ;$
Hi
Im having problems with minningpoolhub, someone could give and example of workers in minningpoolhub, im thinking im not creating the workers properly, all of them have the status dead and false
Im having problems with minningpoolhub, someone could give and example of workers in minningpoolhub, im thinking im not creating the workers properly, all of them have the status dead and false
I Had the same problem, it is not a configuration issue, its just that everytime you go into algoswitching, all other pool configs are stablished as false, happened to me...it is like that.
try to set the ports on same coins but non-.algoswitch with the same config and see the difference.
I shows as dead, but still swtiches to other coins or algos...it works..
Re: Baikal X10 ⚡OVERCLOCK⚡ Claim reward 0.2 BTC for TUTORIAL HOW TO :)⚡⚡⚡⚡
By the way, while looking at some TAR Files recovered, I do see a lot "fakeroot" mentions, and a "ustar" mention, maybe the wanna play us with some fakeroot login through terminal....
I am not a programmer but just saying...
I am not a programmer but just saying...
Re: Baikal X10 ⚡OVERCLOCK⚡ Claim reward 0.2 BTC for TUTORIAL HOW TO :)⚡⚡⚡⚡
Will try to reocover more files. In the other hand, I was messing around the terminal of the X10, went in root mode to some folders inside where they code a lot about the clockrate of each of the three cards, will post about it later on guys.
I do believe Baikal will not help us to make more money, but if we get together we can make this machine a BEAST mining any algo at diffrerent clockrates!
Keep it up guys...very nice work! will help for sure...lets try to get this more private.
I do believe Baikal will not help us to make more money, but if we get together we can make this machine a BEAST mining any algo at diffrerent clockrates!
Keep it up guys...very nice work! will help for sure...lets try to get this more private.
Member CNoteFan found some interesting information at https://bitcointalk.org/index.php?topic=2790982.msg32982356#msg32982356
Looking at part of the deleted code:
It list blake256r8, VANILLA, blake256r14, blake2b, LBRY, PASCAL but blanks out the following:
case ALGO_X11:
case ALGO_X11GOST:
case ALGO_SKEINCOIN:
case ALGO_MYRIAD_GROESTL:
case ALGO_QUARK:
case ALGO_QUBIT:
case ALGO_GROESTL:
case ALGO_SKEIN2:
case ALGO_NIST:
case ALGO_CRYPTONIGHT:
case ALGO_CRYPTONIGHT_LITE:
case ALGO_BLAKE:
case ALGO_VELTOR:
So I am guessing that source code is for the Baikal Giant B. In other words, they already know their list of ALGO but keeping hush. As you can see the Baikal Giant N algo is on the list too. Guess that gives a more confident reason that the 2 missing algo is NIST and GROESTL and most likely mining themselves.
Now the question is, if they would of been able to not blank anything out and turn it into one super 15+ algo miner. Then again, they won't sell as much and would profit more by breaking it down into multiple miners. Just a theory, I could be all wrong...
Looking at part of the deleted code:
Code:
switch (baikal->algorithm.type) {
case ALGO_BLAKECOIN: // blake256r8
case ALGO_VANILLA:
if (work->pool->algorithm.calc_midstate) { // use midstate
msg.data[0] += 1;
memcpy(&msg.data[10], work->midstate, 32);
memcpy(&msg.data[42], &work->data[64], 16);
be32enc_vect((uint32_t *)&msg.data[42], (const uint32_t *)&msg.data[42], 4);
*((uint32_t *)&msg.data[58]) = 0x00000080;
*((uint32_t *)&msg.data[94]) = 0x01000000;
*((uint32_t *)&msg.data[102]) = 0x80020000;
msg.len = 106;
}
else {
memcpy(&msg.data[10], work->data, 80);
be32enc_vect((uint32_t *)&msg.data[10], (const uint32_t *)&msg.data[10], 20);
msg.len = 90;
}
break;
case ALGO_DECRED: // blake256r14
if (work->pool->algorithm.calc_midstate) { // use midstate
msg.data[0] += 1;
memcpy(&msg.data[10], work->midstate, 32);
memcpy(&msg.data[42], &work->data[128], 52);
*((uint32_t *)&msg.data[94]) = 0x01000080UL;
*((uint32_t *)&msg.data[98]) = 0x00000000UL;
*((uint32_t *)&msg.data[102]) = 0xa0050000UL;
msg.len = 106;
}
else {
memcpy(&msg.data[10], work->data, 180);
msg.len = 190;
}
break;
case ALGO_SIA: // blake2b
memcpy(&msg.data[10], work->data, 80);
be32enc_vect((uint32_t *)&msg.data[10], (const uint32_t *)&msg.data[10], 20);
msg.len = 90;
break;
case ALGO_LBRY: // lbry-all
memcpy(&msg.data[10], work->data, 112);
be32enc_vect((uint32_t *)&msg.data[10], (const uint32_t *)&msg.data[10], 27);
msg.len = 122;
break;
case ALGO_PASCAL: // lbry-sha
memcpy(&msg.data[10], work->data, 200);
msg.len = 210;
break;
case ALGO_X11:
case ALGO_X11GOST:
case ALGO_SKEINCOIN:
case ALGO_MYRIAD_GROESTL:
case ALGO_QUARK:
case ALGO_QUBIT:
case ALGO_GROESTL:
case ALGO_SKEIN2:
case ALGO_NIST:
case ALGO_CRYPTONIGHT:
case ALGO_CRYPTONIGHT_LITE:
case ALGO_BLAKE:
case ALGO_VELTOR:
case ALGO_BLAKECOIN: // blake256r8
case ALGO_VANILLA:
if (work->pool->algorithm.calc_midstate) { // use midstate
msg.data[0] += 1;
memcpy(&msg.data[10], work->midstate, 32);
memcpy(&msg.data[42], &work->data[64], 16);
be32enc_vect((uint32_t *)&msg.data[42], (const uint32_t *)&msg.data[42], 4);
*((uint32_t *)&msg.data[58]) = 0x00000080;
*((uint32_t *)&msg.data[94]) = 0x01000000;
*((uint32_t *)&msg.data[102]) = 0x80020000;
msg.len = 106;
}
else {
memcpy(&msg.data[10], work->data, 80);
be32enc_vect((uint32_t *)&msg.data[10], (const uint32_t *)&msg.data[10], 20);
msg.len = 90;
}
break;
case ALGO_DECRED: // blake256r14
if (work->pool->algorithm.calc_midstate) { // use midstate
msg.data[0] += 1;
memcpy(&msg.data[10], work->midstate, 32);
memcpy(&msg.data[42], &work->data[128], 52);
*((uint32_t *)&msg.data[94]) = 0x01000080UL;
*((uint32_t *)&msg.data[98]) = 0x00000000UL;
*((uint32_t *)&msg.data[102]) = 0xa0050000UL;
msg.len = 106;
}
else {
memcpy(&msg.data[10], work->data, 180);
msg.len = 190;
}
break;
case ALGO_SIA: // blake2b
memcpy(&msg.data[10], work->data, 80);
be32enc_vect((uint32_t *)&msg.data[10], (const uint32_t *)&msg.data[10], 20);
msg.len = 90;
break;
case ALGO_LBRY: // lbry-all
memcpy(&msg.data[10], work->data, 112);
be32enc_vect((uint32_t *)&msg.data[10], (const uint32_t *)&msg.data[10], 27);
msg.len = 122;
break;
case ALGO_PASCAL: // lbry-sha
memcpy(&msg.data[10], work->data, 200);
msg.len = 210;
break;
case ALGO_X11:
case ALGO_X11GOST:
case ALGO_SKEINCOIN:
case ALGO_MYRIAD_GROESTL:
case ALGO_QUARK:
case ALGO_QUBIT:
case ALGO_GROESTL:
case ALGO_SKEIN2:
case ALGO_NIST:
case ALGO_CRYPTONIGHT:
case ALGO_CRYPTONIGHT_LITE:
case ALGO_BLAKE:
case ALGO_VELTOR:
It list blake256r8, VANILLA, blake256r14, blake2b, LBRY, PASCAL but blanks out the following:
case ALGO_X11:
case ALGO_X11GOST:
case ALGO_SKEINCOIN:
case ALGO_MYRIAD_GROESTL:
case ALGO_QUARK:
case ALGO_QUBIT:
case ALGO_GROESTL:
case ALGO_SKEIN2:
case ALGO_NIST:
case ALGO_CRYPTONIGHT:
case ALGO_CRYPTONIGHT_LITE:
case ALGO_BLAKE:
case ALGO_VELTOR:
So I am guessing that source code is for the Baikal Giant B. In other words, they already know their list of ALGO but keeping hush. As you can see the Baikal Giant N algo is on the list too. Guess that gives a more confident reason that the 2 missing algo is NIST and GROESTL and most likely mining themselves.
Now the question is, if they would of been able to not blank anything out and turn it into one super 15+ algo miner. Then again, they won't sell as much and would profit more by breaking it down into multiple miners. Just a theory, I could be all wrong...
Well, I think I will do whatever I can to modify my Baikal X10 to mine whatever I want so I can get back the 10k USD I spent on it, damn.....I getting nuts trying to recover my money!.
For anyone having troubles with their Giant X10, could you try logging into it (default user:pass is baikal:baikal) and running this command:
This command will list the USB devices attached to the OrangePi and then filter those results to only show lines with "0483" (STMicroelectronics' USB vendor ID). The expected result is this (where things should be working properly):
But if you get this:
Then the STM32 microcontroller may need to be reset (it is stuck in firmware download mode). If this is the case, issue these two commands:
The first command sets the PA10 pin to 0 (off) on the OrangePi, which is connected to the STM32's reset pin, which in turn holds it in a reset state (it needs to be at 0v to reset). The second command de-asserts (sets to 1 in this case) the reset pin allowing the STM32 to begin normal operations. These steps fixed the issue with a Giant X10 I looked at. These commands may need to be run again after reboot, so you may want to write a script in your favorite language to do this at boot or to do a periodic check.
If you get "permission denied" (or something like that, I don't remember the exact message ATM) when trying those commands, try this first:
Or simply log in as root:baikal instead.
Please do a quick Google search of these commands first to know that they're actually doing what I've explained above. You should default to not trusting random internet stranger's instructions if you're not familiar with what you're doing. Hopefully this helps someone solve their miner issues. Please post if you tried these steps and it solved the issue for you so I know if this is a common problem or if I'm the only one who had trouble with it. Happy mining!
[/size]
Code:
lsusb | grep 0483
This command will list the USB devices attached to the OrangePi and then filter those results to only show lines with "0483" (STMicroelectronics' USB vendor ID). The expected result is this (where things should be working properly):
Code:
Bus 007 Device 003: ID 0483:5740 STMicroelectronics STM32F407
But if you get this:
Code:
Bus 007 Device 002: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
Then the STM32 microcontroller may need to be reset (it is stuck in firmware download mode). If this is the case, issue these two commands:
Code:
echo 0 > /sys/class/gpio_sw/PA10/data
echo 1 > /sys/class/gpio_sw/PA10/data
echo 1 > /sys/class/gpio_sw/PA10/data
The first command sets the PA10 pin to 0 (off) on the OrangePi, which is connected to the STM32's reset pin, which in turn holds it in a reset state (it needs to be at 0v to reset). The second command de-asserts (sets to 1 in this case) the reset pin allowing the STM32 to begin normal operations. These steps fixed the issue with a Giant X10 I looked at. These commands may need to be run again after reboot, so you may want to write a script in your favorite language to do this at boot or to do a periodic check.
If you get "permission denied" (or something like that, I don't remember the exact message ATM) when trying those commands, try this first:
Code:
su
(then type "baikal" again for the password to elevate your terminal to root level)Or simply log in as root:baikal instead.
Please do a quick Google search of these commands first to know that they're actually doing what I've explained above. You should default to not trusting random internet stranger's instructions if you're not familiar with what you're doing. Hopefully this helps someone solve their miner issues. Please post if you tried these steps and it solved the issue for you so I know if this is a common problem or if I'm the only one who had trouble with it. Happy mining!
[/size]
Thank you so much for this! It resurrected 2 of my miners.
1)On the Giant X10 Has anyone experienced problems with the Scrypta Page under MINER Settings not loading?. I dont get it to work anymore, tried to restore backups over and over with no result.
2)Has anyone tried through terminal to disable the led blinking lights during nightime? is it possible?.
3) XVG vs. Digibyte-Multialgo on Mininpoolhub? what are you guys making more profit from?
Thanks people!!