Swedish ASIC miner company kncminer.com

[Minor Miner]

This is exactly what mine does. I even booted it off a sd card and same issue when I plug a module in. You end up shipping your whole unit back?

Still waiting (4 days) on RMA at this point.  Figure another 6 days round trip (due to weekend) even if they authorize an RMA today I am down 2.5 to 3.0 BTC and counting.

I have one dead unit also.   Just solid red light and solid green light.  Have tried their solutions (because of time difference each solution takes another whole day and of course lost whole weekend for first answer).   They have been responsive but have ignored RMA request while they suggest the SD card route that has failed.   Controller seems bad.   It is frustrating but they are trying at least.

[vesperwillow]

Starting to sound like there needs to be a dedicated KNC Problem thread, as there are many issues popping up.

[DeathAndTaxes]

This is exactly what mine does. I even booted it off a sd card and same issue when I plug a module in. You end up shipping your whole unit back?

Still waiting (4 days) on RMA at this point.  Figure another 6 days round trip (due to weekend) even if they authorize an RMA today I am down 2.5 to 3.0 BTC and counting.

I have one dead unit also.   Just solid red light and solid green light.  Have tried their solutions (because of time difference each solution takes another whole day and of course lost whole weekend for first answer).   They have been responsive but have ignored RMA request while they suggest the SD card route that has failed.   Controller seems bad.   It is frustrating but they are trying at least.

The thing that really makes me mad is it is obvious they never tested the full units.  They may have tested individual ASIC boards but they weren't tested as fully assembled units (my unit arrived w/ mining config set to "X").  Had someone tried to even turn these units on it would not have gotten past QA.  Hell just paying some guy min wage to pull units off the line which have red & green lights on simultaneously would have avoided this.  They shipped a brick, it is a complete and utter brick.  It isn't a unit that randomly crashes under some weird conditions, it isn't a unit when under load after hours one ASIC dies, it isn't a unit with excessively high hardware failures, it isn't a unit with a VRM that overheats and fails after days of high temp, no this is like putting a 10 pound brick in a box and calling it a mining rig.  It does absolutely nothing so any testing no matter how basic would have caught this issue.

Power on = does absolutely nothing.   No login, no SSH, no ability to keep settings, hell even the red & green power lights don't go off (my understanding is if red & green both stay on = your fucked signal).   No possible way that got through any "testing".  So KNC inability to even perform basic testing has now cost me ~$2,500 and counting.  When you consider how front loaded lifetime revenue is there is no chance of ever recovering that.  Hell if prior RMA hell stories are accurate I will be lucky to break even.  Also just from this thread I have now seen four similar cases so my guess is this problem is certainly not an edge case.   At this point I am considering just doing a chargeback (no not ask for a refund so they can delay their response until the chargeback window closes, just doing a chargeback so they get hit with the chargeback fee).  If I was confident KNC could fix the problem in a timely manner (like shipping a new controller 4 days ago) it might be different but despite what the shills say the reality is with KNC if you get a fully functional unit you are fine but if you don't your fucked and it looks like by luck of the draw I ended up in the second camp.

Hey KNC I KNOW YOU ARE TOO DAMN BUSY COUNTING YOUR MILLIONS TO ACTUALLY RESPOND TO THIS THREAD OR YOUR KNOW OWN CUSTOMER SUPPORT FORUM BUT ......
HERE IS A COMPLETELY GRATIS BUSINESS TIP FOR YOU, PLEASE TEST THE FUCKING UNITS BEFORE SHIPPING THEM.

[Phoenix1969]

All my machines from knc were unresponsive upon arrival...   every one.  
They were all fine, and just needed a bit of configuring...
If your miner seems unresponsive upon arrival....  
one or more of these tips may help:
check your proxy.
1.   no Http:// on stratum addresses.

2.   Check your pool sign on credentials.  
Make sure no space if you use the copy & paste...  an empty character field can be hard to catch.

3. Make sure you turn DHCP OFF the first time you get into the GUI,
and...... assign an address before restarting, or you will have to sniff all over again


good luck

[vesperwillow]

All my machines from knc were unresponsive upon arrival...   every one.  
They were all fine, and just needed a bit of configuring...
If your miner seems unresponsive upon arrival....  
one or more of these tips may help:
check your proxy.
1.   no Http:// on stratum addresses.

2.   Check your pool sign on credentials.  
Make sure no space if you use the copy & paste...  an empty character field can be hard to catch.

3. Make sure you turn DHCP OFF the first time you get into the GUI,
and...... assign an address before restarting, or you will have to sniff all over again.

good luck

Some of these units aren't even polling DHCP, and you can't reach them via SSH, telnet or anything. Keep it simple for sure, but it's clear some of the control units are simply DOA.

I'm thinking maybe something wrong with the boot media? Hard to believe the hardware itself is bad. Folks need to try to pull the control units apart and then reconnect them--might be a wonky/loose conneciton.

Had a PCI riser die on me lastnight. Ended up just needing to be resoldered.

[DeathAndTaxes]

All my machines from knc were unresponsive upon arrival...   every one.  
They were all fine, and just needed a bit of configuring...
If your miner seems unresponsive upon arrival....  
one or more of these tips may help:
check your proxy.
1.   no Http:// on stratum addresses.

2.   Check your pool sign on credentials.  
Make sure no space if you use the copy & paste...  an empty character field can be hard to catch.

3. Make sure you turn DHCP OFF the first time you get into the GUI,
and...... assign an address before restarting, or you will have to sniff all over again.

good luck

I know you are trying to help but please try to read the problem first.

None of that troubleshooting is any use.  When I (and others with the same problem) say non-responsive I mean non-responsive as in a completely bricked rig.  If you can get to the mining config or status page the rig isn't non-responsive.


As an example.  My unit has IP address of 192.168.0.190.

Going to http://192.168.0.190 gets "connection refused".
SSH to 192.168.0.190 gets "connection refused".
The unit never completes booting (red & green lights remain on).

So how exactly would I make sure the mining address is correct if the webpage is unresponsive?  In this case unresponsive isn't an exaguration.  The rig does ABSOLUTELY NOTHING as delivered.  It doesn't even finish booting (red or green light turn off).

Now if I (and others with the red & green lights of death) disconnect all ASIC boards, the rig can be accessed by the IP address (192.168.0.190 in this case).   So this isn't some user error not sure of what the IP address is.  Of course it doesn't matter.
a) any settings entered are erased when you reboot (yes all mining config info is replaced with an "X" after reboot)
and
b) connecting any mining board (tried each of the 4 individually) returns to same red & green lights of death.

Simple version:
ASIC boards connected = a complete brick, no GUI, no SSH, no completed boot cycle (red & green lights of death).
ASIC boards disconnected = GUI & SSH accessible, all settings lost when power cycled, connecting any ASIC board returns to the status above.

[vesperwillow]

My unit has IP address of 192.168.0.190.

Going to http://192.168.0.190 gets "connection refused".
SSH to 192.168.0.190 gets "connection refused".
The unit never completes booting (red & green lights remain on).

Just a thought, have you tried portscanning the unit during bootup and after it's sat awhile, to see what ports are open? If it pulled an IP, that's what I'd try.

Is there a jtag/serial connection somewhere to see output while it's booting?

[vesperwillow]

What part of unresponsive do you not understand.  I know you are trying to help but please try to read the problem first.

He doesn't have to fix these issues, KNC just sends him working equipment..

LOL..

[kendog77]

All my machines from knc were unresponsive upon arrival...   every one.  
They were all fine, and just needed a bit of configuring...
If your miner seems unresponsive upon arrival....  
one or more of these tips may help:
check your proxy.
1.   no Http:// on stratum addresses.

2.   Check your pool sign on credentials.  
Make sure no space if you use the copy & paste...  an empty character field can be hard to catch.

3. Make sure you turn DHCP OFF the first time you get into the GUI,
and...... assign an address before restarting, or you will have to sniff all over again.

good luck

I know you are trying to help but please try to read the problem first.

None of that troubleshooting is any use.  When I (and others with the same problem) say non-responsive I mean non-responsive as in a completely bricked rig.  If you can get to the mining config or status page the rig isn't non-responsive.


As an example.  My unit has IP address of 192.168.0.190.

Going to http://192.168.0.190 gets "connection refused".
SSH to 192.168.0.190 gets "connection refused".
The unit never completes booting (red & green lights remain on).

So how exactly would I make sure the mining address is correct if the webpage is unresponsive?  In this case unresponsive isn't an exaguration.  The rig does ABSOLUTELY NOTHING as delivered.  It doesn't even finish booting (red or green light turn off).

Now if I (and others with the red & green lights of death) disconnect all ASIC boards, the rig can be accessed by the IP address (192.168.0.190 in this case).   So this isn't some user error not sure of what the IP address is.  Of course it doesn't matter.
a) any settings entered are erased when you reboot (yes all mining config info is replaced with an "X" after reboot)
and
b) connecting any mining board (tried each of the 4 individually) returns to same red & green lights of death.

Simple version:
ASIC boards connected = a complete brick, no GUI, no SSH, no completed boot cycle (red & green lights of death).
ASIC boards disconnected = GUI & SSH accessible, all settings lost when power cycled, connecting any ASIC board returns to the status above.

Have you tried reflashing the SD card with the default November image?

https://www.kncminer.com/pages/troubleshooting

[paul3]

Hey KNC I KNOW YOU ARE TOO DAMN BUSY COUNTING YOUR MILLIONS TO ACTUALLY RESPOND TO THIS THREAD OR YOUR KNOW OWN CUSTOMER SUPPORT FORUM BUT ......
HERE IS A COMPLETELY GRATIS BUSINESS TIP FOR YOU, PLEASE TEST THE FUCKING UNITS BEFORE SHIPPING THEM.

+1 for that!


My nov jupiter arrived yesterday. I opened the case because I heard some sounds like the fans are not in the place they should be. Fixed the two fans that felt off during transport & checked all cable connections. After that I try to start the miner, without any problems. It was running for 4-5 hours and I decided to go sleeping. This morning the miner was down, in total it was running for 7-8 hours.

First I thought the PSU is broken, but a quick check without the miner connected showed this is not the case.

I started bugfixing:

1. Only beagleboard connected to PSU -> working
2. tested beagleboard + each hashing board seperate -> 3 working, 1 won't start (complete miner didn't start)
3. beagleboard + 3 working boards -> running, but hashing rate only 330 GH/s
4. Different combinations of the 3 running boards -> found two that reach together 330 GH/s

So now the Jupiter is only hashing with 2 boards, waiting for a reply from KNC...

[DeathAndTaxes]

My unit has IP address of 192.168.0.190.

Going to http://192.168.0.190 gets "connection refused".
SSH to 192.168.0.190 gets "connection refused".
The unit never completes booting (red & green lights remain on).

Just a thought, have you tried portscanning the unit during bootup and after it's sat awhile, to see what ports are open? If it pulled an IP, that's what I'd try.

I get no response on any port.  Yeah I am a nerd enough to try that.  My guess is that when ASICs are connected something faulty in the control board is bricking the boot cycle before it ever connects to the network.  I don't know for sure as I don't have a working unit (going on 4 days now) BUT my understanding is that the lights on the rig go from off, to both red & green on, to either only red (fault) or only green (mining).   With rigs that have this issue the boot cycle never goes past both red & green on.  You can wait minutes or hours and it will remain right there.

Is there a jtag/serial connection somewhere to see output while it's booting?

It looks like the PCB has a JTAG pinout but it is unlabeled and has no connector.  I am not going to solder my under warranty unit and make it non under warranty.  I am pretty convinced at this point it isn't a software issue.  Since the BBB is just an off the shelf controller (and it works fine disconnected from the controller motherboard) my outsider (KNC should know more but they have been silent so far) view is the controller motherboard (the custom board which only KNC can replace) is defective on some units.  Of course even basic testing before shipping would have caught this.   My unit arrived with all mining configuration set to "X".

[DeathAndTaxes]

Have you tried reflashing the SD card with the default November image?
https://www.kncminer.com/pages/troubleshooting

Yes.  Tried both using the web GUI (with ASICs disconnected) and by doing the SD card flash procedure.  Before someone else asked it was the 0.99e Nov firmware not accidentally some incompatible Oct firmware.  Same exact outcome after flashing.   No errors in flashing but all the same symptoms
a) unresponsive to GUI
b) unresponsive to SSH
c) red & green lights of death on boot.
d) (with ASICS disconnected) all config settings lost after power cycle

Trust me I had a whole weekend with a unit that could (if it would just boot) produce 350 mBTC per day.  I took the whole damn thing apart.  Even disconnected the BBB from the controller and booted that separately to see if I could determine if the BBB was defective.  I can always replace the BBB and if an ASIC is bad I can run the rig with the remaining modules but if the custom KNC controller board is bad well there is nothing I can do other than wait days (or weeks) for an RMA to be completed.

[Phoenix1969]

All my machines from knc were unresponsive upon arrival...   every one.  
They were all fine, and just needed a bit of configuring...
If your miner seems unresponsive upon arrival....  
one or more of these tips may help:
check your proxy.
1.   no Http:// on stratum addresses.

2.   Check your pool sign on credentials.  
Make sure no space if you use the copy & paste...  an empty character field can be hard to catch.

3. Make sure you turn DHCP OFF the first time you get into the GUI,
and...... assign an address before restarting, or you will have to sniff all over again.

good luck

What part of unresponsive do you not understand.  I know you are trying to help but please try to read the problem first.

My unit has IP address of 192.168.0.190.

Going to http://192.168.0.190 gets "connection refused".
SSH to 192.168.0.190 gets "connection refused".
The unit never completes booting (red & green lights remain on).

So how exactly would I make sure the mining address is correct if the webpage is unresponsive, hence the report about unresponsive unit.

Now if I (and others with the red & green lights of death) disconnect all ASIC boards you can access the rig by IP address.  Of course it doesn't matter.
a) any settings entered are erased when you reboot (yes all mining config info is replaced with an "X" after reboot)
and
b) connecting any mining board (tried each of the 4 individually) returns to same red & green lights of death.

All my machines from knc were unresponsive upon arrival...   every one.  
They were all fine, and just needed a bit of configuring...
If your miner seems unresponsive upon arrival....  
one or more of these tips may help:
check your proxy.
1.   no Http:// on stratum addresses.

2.   Check your pool sign on credentials.  
Make sure no space if you use the copy & paste...  an empty character field can be hard to catch.

3. Make sure you turn DHCP OFF the first time you get into the GUI,
and...... assign an address before restarting, or you will have to sniff all over again.

good luck

What part of unresponsive do you not understand.  I know you are trying to help but please try to read the problem first.

My unit has IP address of 192.168.0.190.

Going to http://192.168.0.190 gets "connection refused".
SSH to 192.168.0.190 gets "connection refused".
The unit never completes booting (red & green lights remain on).

So how exactly would I make sure the mining address is correct if the webpage is unresponsive, hence the report about unresponsive unit.

Now if I (and others with the red & green lights of death) disconnect all ASIC boards you can access the rig by IP address.  Of course it doesn't matter.
a) any settings entered are erased when you reboot (yes all mining config info is replaced with an "X" after reboot)
and
b) connecting any mining board (tried each of the 4 individually) returns to same red & green lights of death.

Hence the word MAY help.
If you continue ridicule me, I will stop giving suggestions.
If you didn't want help or suggestions....  why come here?
With that said....

I had the same problem.
After a couple minutes, the miners do become unresponsive after a few poll attempts...
How I was able to get in, was to be quick about it....timing
When you get the address, waste no time accessing...
When I did it...Sniff & access must be done with a dash of speed, and sometimes repeatedly.  They all reacted the same way.
good luck

Remember it took me 18 hours to crack my first miner...   Edgar loves that....  lol
*It only takes one character in any field to mess things up.

[helmax]

iam using sd card for hdd beagleboard for now works

later i will send for RMA

maybe when shutoff power corrupt filesystem flash
this will happened is better if we use sdcard with custom OS knc

[DeathAndTaxes]

iam using sd card for hdd beagleboard for now works

later i will send for RMA

maybe when shutoff power corrupt filesystem flash
this will happened is better if we use sdcard with custom OS knc

Can you provide exact steps?

[helmax]

win32diskimager

http://vector.xyxx.com/~myrond/backup-jupiter-0.95.img

[DeathAndTaxes]

win32diskimager

http://vector.xyxx.com/~myrond/backup-jupiter-0.95.img

So just write the image to the SD card, pop it in and power it on.  The unit just knows to boot off the card not internal memory automatically?

[helmax]

automatically go to sdcard

but sometimes go to mmc

if anyone know put direct always to sdcard will be good and not more RMA beagleboard

[sickpig]

win32diskimager

http://vector.xyxx.com/~myrond/backup-jupiter-0.95.img

So just write the image to the SD card, pop it in and power it on.  The unit just knows to boot off the card not internal memory automatically?

wait this an october image, no?

D&T you do have a November jup, right?

[helmax]

this is for october batch

sorry