The Habanero - 650GH/s - OOS

[Swimmer63]

So I run a number of these boards and have almost zero problems.
But yesterday I see one stopped hashing.  The Corsair 100i logo which is usually white was flashing red.  CGminer showed errors consistent with a temperature issue.  I can't find much online about this.  Anyone in the know??
Seems odd to have a temp issue just all of a sudden.
I am going to take the cooler off, redo the paste and reinstall.  But I wanted to see if anyone know what's up.

[1714715889]

1714715889

[Taugeran]

So I run a number of these boards and have almost zero problems.
But yesterday I see one stopped hashing.  The Corsair 100i logo which is usually white was flashing red.  CGminer showed errors consistent with a temperature issue.  I can't find much online about this.  Anyone in the know??
Seems odd to have a temp issue just all of a sudden.
I am going to take the cooler off, redo the paste and reinstall.  But I wanted to see if anyone know what's up.

A quick google yielded that that flashing red logo usually indicates a failing cooler. Most likely need to RMA IT

[MrTeal]

So I run a number of these boards and have almost zero problems.
But yesterday I see one stopped hashing.  The Corsair 100i logo which is usually white was flashing red.  CGminer showed errors consistent with a temperature issue.  I can't find much online about this.  Anyone in the know??
Seems odd to have a temp issue just all of a sudden.
I am going to take the cooler off, redo the paste and reinstall.  But I wanted to see if anyone know what's up.

A quick google yielded that that flashing red logo usually indicates a failing cooler. Most likely need to RMA IT

That's what I guessed as well. If you want to check, in a quieter room connect just the SATA power cable to a PSU and listen to the pump without the fans on. You should hear it working pretty quietly. If you hear nothing or it makes horrible noises, it's probably dead.

[Swimmer63]

After uninstalling and reinstalling, and using another computer I agree.  It's dead.
Thanks guys.

[jimmychopps]

I'm trying to update the firmware on my hab and I'm getting the following:

pi@raspberrypi ~/firmware/firmware-20140713-0 $ sudo python3.2 ./field_firmware_update.py
confirm is  False
FIRMWARE_DIR is  .
UC_HFU_FILE at './uc3.cropped.hfu'.
READSERIAL found at 'armv6l/readserial'.
HFUPDATE found at 'armv6l/hfupdate'.
ENTERLOADER found at 'armv6l/enterloader'.
HashFast Firmware Updater
Reading serial number from module.
armv6l/readserial: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
Entering Boot Loader...
armv6l/enterloader: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "./field_firmware_update.py", line 184, in <module>
    firmware_updater()
  File "./field_firmware_update.py", line 143, in firmware_updater
    enterloader()
  File "./field_firmware_update.py", line 62, in enterloader
    subprocess.check_call([ENTERLOADER])
  File "/usr/lib/python3.2/subprocess.py", line 489, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['armv6l/enterloader']' returned non-zero exit status 127
Command '['armv6l/enterloader']' returned non-zero exit status 127
Firmware Update had an error.  Please retry or report to HashFast Support.

Any idea what could be wrong?

Have you installed libudev?
sudo apt-get install libudev1
Assuming you're using raspbian.

I am using raspbian.

I tried installing libudev1 and got the following:

pi@raspberrypi ~ $ sudo apt-get install libudev1
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libudev1

[Taugeran]

I'm trying to update the firmware on my hab and I'm getting the following:

pi@raspberrypi ~/firmware/firmware-20140713-0 $ sudo python3.2 ./field_firmware_update.py
confirm is  False
FIRMWARE_DIR is  .
UC_HFU_FILE at './uc3.cropped.hfu'.
READSERIAL found at 'armv6l/readserial'.
HFUPDATE found at 'armv6l/hfupdate'.
ENTERLOADER found at 'armv6l/enterloader'.
HashFast Firmware Updater
Reading serial number from module.
armv6l/readserial: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
Entering Boot Loader...
armv6l/enterloader: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "./field_firmware_update.py", line 184, in <module>
    firmware_updater()
  File "./field_firmware_update.py", line 143, in firmware_updater
    enterloader()
  File "./field_firmware_update.py", line 62, in enterloader
    subprocess.check_call([ENTERLOADER])
  File "/usr/lib/python3.2/subprocess.py", line 489, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['armv6l/enterloader']' returned non-zero exit status 127
Command '['armv6l/enterloader']' returned non-zero exit status 127
Firmware Update had an error.  Please retry or report to HashFast Support.

Any idea what could be wrong?

Have you installed libudev?
sudo apt-get install libudev1
Assuming you're using raspbian.

I am using raspbian.

I tried installing libudev1 and got the following:

pi@raspberrypi ~ $ sudo apt-get install libudev1
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libudev1. Includes the library and header files

Libudev-dev should work. It's the development package for udev

[PCComf]

This gets stranger and stranger. I had some time this evening and took a chance with additional troubleshooting since I'm pretty dead in the water otherwise. The board powers up fine when A,C,D PCI-E are plugged in, but B is what causes the issue. I see nothing wrong with that connection.

If I try to get the board to hash in this state - I am not sure this is possible - I get the Operation status 20 error and it continuously re-detects the board. I have not touched anything to do with firmware and since it doesn't seem to be helping the others with that problem and I'm not going to try yet. I am wondering if it is complaining because that one isn't powered up and if it is possible to disable a chip. I'm not even sure if things are set up that way - just hoping for some kind of way to get it partially alive again.

Thanks for any help.

In a conversation at some point I was advised by Dave that it was worth trying to disable certain dies to resolve this issue. Essentially the idea is to identify the bad die then set its voltage to ZERO so it will then be disregarded and allow the healthy dies to work. So using the version of the hcm tool I have the command is something like # ./hcm --write-die-settings 1:0@0 if you wanted to disable die 1. I tried this tonight but it did not solve my problem.

Hopefully Dave can chime in with further suggestions. I will report back if I have any luck tomorrow.

It's weird that it continues to give you the error 20 even with a die disabled. Did you try running them each individually to see if they'll run one at a time? IE,
./hftool.py -w 0:950@900/1:0@900/2:0@900/3:0@900
then ./hftool.py -w 0:0@900/1:950@900/2:0@900/3:0@900
etc.

Well I know this has been a long time, but I finally found some time to take a look at this again. [Dropped my notebook computer or rather it flew out of my backpack and landed on pavement and killed it, and had a hard drive failure on the OS drive of my desktop while I was recovering data from the SSD in the laptop.]

I've tried that now - only a single core enabled at a time and I still get the same error:
HFA : OP_USB_INIT failed! Operation status 20 (Regulator programming error)

[MrTeal]

This gets stranger and stranger. I had some time this evening and took a chance with additional troubleshooting since I'm pretty dead in the water otherwise. The board powers up fine when A,C,D PCI-E are plugged in, but B is what causes the issue. I see nothing wrong with that connection.

If I try to get the board to hash in this state - I am not sure this is possible - I get the Operation status 20 error and it continuously re-detects the board. I have not touched anything to do with firmware and since it doesn't seem to be helping the others with that problem and I'm not going to try yet. I am wondering if it is complaining because that one isn't powered up and if it is possible to disable a chip. I'm not even sure if things are set up that way - just hoping for some kind of way to get it partially alive again.

Thanks for any help.

In a conversation at some point I was advised by Dave that it was worth trying to disable certain dies to resolve this issue. Essentially the idea is to identify the bad die then set its voltage to ZERO so it will then be disregarded and allow the healthy dies to work. So using the version of the hcm tool I have the command is something like # ./hcm --write-die-settings 1:0@0 if you wanted to disable die 1. I tried this tonight but it did not solve my problem.

Hopefully Dave can chime in with further suggestions. I will report back if I have any luck tomorrow.

It's weird that it continues to give you the error 20 even with a die disabled. Did you try running them each individually to see if they'll run one at a time? IE,
./hftool.py -w 0:950@900/1:0@900/2:0@900/3:0@900
then ./hftool.py -w 0:0@900/1:950@900/2:0@900/3:0@900
etc.

Well I know this has been a long time, but I finally found some time to take a look at this again. [Dropped my notebook computer or rather it flew out of my backpack and landed on pavement and killed it, and had a hard drive failure on the OS drive of my desktop while I was recovering data from the SSD in the laptop.]

I've tried that now - only a single core enabled at a time and I still get the same error:
HFA : OP_USB_INIT failed! Operation status 20 (Regulator programming error)

Have you updated the FW yet?

[PCComf]

This gets stranger and stranger. I had some time this evening and took a chance with additional troubleshooting since I'm pretty dead in the water otherwise. The board powers up fine when A,C,D PCI-E are plugged in, but B is what causes the issue. I see nothing wrong with that connection.

If I try to get the board to hash in this state - I am not sure this is possible - I get the Operation status 20 error and it continuously re-detects the board. I have not touched anything to do with firmware and since it doesn't seem to be helping the others with that problem and I'm not going to try yet. I am wondering if it is complaining because that one isn't powered up and if it is possible to disable a chip. I'm not even sure if things are set up that way - just hoping for some kind of way to get it partially alive again.

Thanks for any help.

In a conversation at some point I was advised by Dave that it was worth trying to disable certain dies to resolve this issue. Essentially the idea is to identify the bad die then set its voltage to ZERO so it will then be disregarded and allow the healthy dies to work. So using the version of the hcm tool I have the command is something like # ./hcm --write-die-settings 1:0@0 if you wanted to disable die 1. I tried this tonight but it did not solve my problem.

Hopefully Dave can chime in with further suggestions. I will report back if I have any luck tomorrow.

It's weird that it continues to give you the error 20 even with a die disabled. Did you try running them each individually to see if they'll run one at a time? IE,
./hftool.py -w 0:950@900/1:0@900/2:0@900/3:0@900
then ./hftool.py -w 0:0@900/1:950@900/2:0@900/3:0@900
etc.

Well I know this has been a long time, but I finally found some time to take a look at this again. [Dropped my notebook computer or rather it flew out of my backpack and landed on pavement and killed it, and had a hard drive failure on the OS drive of my desktop while I was recovering data from the SSD in the laptop.]

I've tried that now - only a single core enabled at a time and I still get the same error:
HFA : OP_USB_INIT failed! Operation status 20 (Regulator programming error)

Have you updated the FW yet?

Yes, updated to the latest posted on peppermining.com
Thanks.

[toothpick]

I have a Sierra from batch 2 with board revision 2.3. I would like to upgrade to the Habanero board but have some questions.
-I am very good with electronics and have designed and fabricated many PCB boards. But I have never attempted to solder something like a CPU... What is the suggested process for desoldering the ASIC and resoldering to the habanero without damaging the chip?
-$600 is pretty steep for me considering I lost ALL my savings due to the HashFast fiasco. I am only interested in this if it will increase my ROI. Do you have any plans to make the PCB design files available so we can have our own boards fabricated? If not, what about schematics?
-Will you be making more of these in the future? I know your supply is limited and I need 3 boards.
-If all else fails... Do you have any suggestions on what I can do to increase my clock above 700mhz using the stock Sierra configuration? It is very stable at 700mhz but I cannot go higher.
-On a related note, does HF-Tools software work on the Batch 2 Sierra boards or is it only for EVO+? And the firmware update software? Because I have been unable to get HF-Tools or the firmware update (dont know if I even need that) to work on my Ubuntu host.

Any info is much appreciated! It is very hard to find information on the Sierra machines since there aren't many of them. Mine was literally the last one shipped before they started scrapping the machines and harvesting the ASIC chips. As a college student, buying this Sierra was the most expensive and worst mistake I've made in my entire life! 60 BTC I paid and have only mined just over 1 BTC in the 3+ months it's been running! Makes me sick! My only hope is that I can somehow overclock this very capable ASIC before it's obsolete! It seems like you guys are the ones to talk too!

[Taugeran]

I have a Sierra from batch 2 with board revision 2.3. I would like to upgrade to the Habanero board but have some questions.
-I am very good with electronics and have designed and fabricated many PCB boards. But I have never attempted to solder something like a CPU... What is the suggested process for desoldering the ASIC and resoldering to the habanero without damaging the chip?
-$600 is pretty steep for me considering I lost ALL my savings due to the HashFast fiasco. I am only interested in this if it will increase my ROI. Do you have any plans to make the PCB design files available so we can have our own boards fabricated? If not, what about schematics?
-Will you be making more of these in the future? I know your supply is limited and I need 3 boards.
-If all else fails... Do you have any suggestions on what I can do to increase my clock above 700mhz using the stock Sierra configuration? It is very stable at 700mhz but I cannot go higher.
-On a related note, does HF-Tools software work on the Batch 2 Sierra boards or is it only for EVO+? And the firmware update software? Because I have been unable to get HF-Tools or the firmware update (dont know if I even need that) to work on my Ubuntu host.

Any info is much appreciated! It is very hard to find information on the Sierra machines since there aren't many of them. Mine was literally the last one shipped before they started scrapping the machines and harvesting the ASIC chips. As a college student, buying this Sierra was the most expensive and worst mistake I've made in my entire life! 60 BTC I paid and have only mined just over 1 BTC in the 3+ months it's been running! Makes me sick! My only hope is that I can somehow overclock this very capable ASIC before it's obsolete! It seems like you guys are the ones to talk too!

I'll be plain and blunt. Do NOT Attempt.. Just leave it as it is. Desoldering a several hundred, if not thousand pin count FCBGA package without damaging it is nigh impossible without professional equipment.

Somewhere in this post MrTeal said only 10 boards cost 4000USD. as qty goes down price per unit goes up

[PCComf]

Anyone want to buy my broken board?

[MrTeal]

I have a Sierra from batch 2 with board revision 2.3. I would like to upgrade to the Habanero board but have some questions.
-I am very good with electronics and have designed and fabricated many PCB boards. But I have never attempted to solder something like a CPU... What is the suggested process for desoldering the ASIC and resoldering to the habanero without damaging the chip?
-$600 is pretty steep for me considering I lost ALL my savings due to the HashFast fiasco. I am only interested in this if it will increase my ROI. Do you have any plans to make the PCB design files available so we can have our own boards fabricated? If not, what about schematics?
-Will you be making more of these in the future? I know your supply is limited and I need 3 boards.
-If all else fails... Do you have any suggestions on what I can do to increase my clock above 700mhz using the stock Sierra configuration? It is very stable at 700mhz but I cannot go higher.
-On a related note, does HF-Tools software work on the Batch 2 Sierra boards or is it only for EVO+? And the firmware update software? Because I have been unable to get HF-Tools or the firmware update (dont know if I even need that) to work on my Ubuntu host.

Any info is much appreciated! It is very hard to find information on the Sierra machines since there aren't many of them. Mine was literally the last one shipped before they started scrapping the machines and harvesting the ASIC chips. As a college student, buying this Sierra was the most expensive and worst mistake I've made in my entire life! 60 BTC I paid and have only mined just over 1 BTC in the 3+ months it's been running! Makes me sick! My only hope is that I can somehow overclock this very capable ASIC before it's obsolete! It seems like you guys are the ones to talk too!

I'll be plain and blunt. Do NOT Attempt.. Just leave it as it is. Desoldering a several hundred, if not thousand pin count FCBGA package without damaging it is nigh impossible without professional equipment.

Somewhere in this post MrTeal said only 10 boards cost 4000USD. as qty goes down price per unit goes up

1935 balls, to be exact. Even reballing that many is a PITA.

To the OP, if the Sierra is working, I would just leave it to be honest. The increase in hashrate you'll get won't be worth the cost vs just mining with what you have. I don't imagine you'll see much if any improvement on the rev 2 boards over 700MHz. No idea on the Hashfast tools for the Sierras, sorry. Also no plans to open source the design (and I believe the HDK agreement with HF would actually prohibit parts of it from being open sourced).

[MrTeal]

Anyone want to buy my broken board?

Sorry, I must have misunderstood your previous post. When you updated to the latest FW, did it not fix the issue you were having?

[PCComf]

Anyone want to buy my broken board?

Sorry, I must have misunderstood your previous post. When you updated to the latest FW, did it not fix the issue you were having?

No, still get the same error even if only one core is enabled.

[MrTeal]

Anyone want to buy my broken board?

Sorry, I must have misunderstood your previous post. When you updated to the latest FW, did it not fix the issue you were having?

No, still get the same error even if only one core is enabled.

Can you PM me an email address? I've made a FW change that I believe should allow you to get the board hashing, I'd like to have you try it out.

[PCComf]

Anyone want to buy my broken board?

Sorry, I must have misunderstood your previous post. When you updated to the latest FW, did it not fix the issue you were having?

No, still get the same error even if only one core is enabled.

Can you PM me an email address? I've made a FW change that I believe should allow you to get the board hashing, I'd like to have you try it out.

That firmware fixed my issue. The board is now hashing on 3 cores with one of the power leads unplugged. hftool.py output looked a little different, so I suspect it wasn't working right on the old firmware with one lead removed either.

Thanks much!

[Swimmer63]

So my cgminer crashes whenever I try and save the config file using these Habs.  Does not matter what version of cgminer.  Someone else mentioned they had the same issue.  Any answers?

[MrTeal]

So my cgminer crashes whenever I try and save the config file using these Habs.  Does not matter what version of cgminer.  Someone else mentioned they had the same issue.  Any answers?

Not that I can think of, all cgminer is doing when saving the config is that it's writing to a text file on the host. That would probably be something that Con would have to answer. What OS/device, and could it be a permissions issue?

[Swimmer63]

So my cgminer crashes whenever I try and save the config file using these Habs.  Does not matter what version of cgminer.  Someone else mentioned they had the same issue.  Any answers?

Not that I can think of, all cgminer is doing when saving the config is that it's writing to a text file on the host. That would probably be something that Con would have to answer. What OS/device, and could it be a permissions issue?

Right now they are running on Win7 but I had the same issue on Win8.  It will save a config file, but it also kills the miner.  No error message, just stops working.  When I start up cgminer off the bat file it looks for the conf file and then returns a JSON error.  Then it just runs based on the bat file.  Not sure if that has something to do with it or not.