Topic: Swedish ASIC miner company kncminer.com - page 859. (Read 3050071 times)

Correct.  If the issue is that the BBB is corrupting the internal memory for some reason (which given that settings are all trashed on reboot kinda makes sense) then this might work if there was a Nov img file available.  It at least would be worth trying as I have nothing to lose at this point.

Damn I just noticed the link is to an Oct image.  I would need an uncorrupted copy of Nov image to test it out.

Well, when he stops giving suggestions, don't worry D&T.. the rest of us will still try to help.

And keep it related to the problem at hand.

this is for october batch

sorry

wait this an october image, no?

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

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

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?

win32diskimager

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

Can you provide exact steps?

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

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.

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.

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.


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".

+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...

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

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

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

LOL..

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?

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.

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.

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