HashFast BabyJet users thread

[CurcO]

I was getting great performance when my 3 BJ's arrived. At least on two of them, there was one that seemed a bit flakey and seems to be getting worse. All 3 seem to be getting worse. One of them keeps shutting down and restarting grabbing a new ID each time. I posted a small capture from my monitor so that maybe if others have had this and fixed it they can help. This one that is flaky was delivered in poor condition, all but one screw was sliding around the inside of the box and 4 risers that prop the board up were also floating around. I though the board was damaged and it may be. Worst assembly I have ever seen and I used to build PC's. That point is mute if they all work but they don't.

Here is what I need help answering.
1. How do I get back to my 400+ GH performance. All three of these were pushing +-420GH.
2. Worse case scenario is how do I raise the clock speed to get up to the 400GH range? I was promised by Erin at Hashfast that it would not void the warranty but the delivery paperwork stated otherwise. I will have to deal with that warranty issue separately, I know.
3. I seem to be getting huge error rates, I think it is on the flaky board but not 100% sure that is the only place. 70% to 80% errors are common. Elgius reports I am only getting 900 to 950 GH/s AVG with 3 boards and I should be getting closer to 1200. Not good for profits. Any help would be appreciated. I hate to try and send a board back under warranty since I might be stuck for months. I still am waiting on my 3 upgrades, I would hat to be down to 2 processors if I can avoid it.

 [2014-02-05 10:15:06] HFA 21 HFHash usb write err:(-7) LIBUSB_ERROR_TIMEOUT                                                   
 [2014-02-05 10:15:06] HFA 21 attempted reset got err:(0) LIBUSB_SUCCESS                                                       
 [2014-02-05 10:15:07] Accepted 6b3cd65e Diff 611/512 HFA 1                                                                     
 [2014-02-05 10:15:08] HFA 21 HFHash usb write err:(-7) LIBUSB_ERROR_TIMEOUT                                                   
 [2014-02-05 10:15:08] HFA 21 HFGetHeader usb read err:(-4) LIBUSB_ERROR_NO_DEVICE                                             
 [2014-02-05 10:15:08] Accepted 4a23005d Diff 884/512 HFA 1                                                                     
 [2014-02-05 10:15:09] HFA 21 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND                                               
 [2014-02-05 10:15:10] Accepted 5c43a019 Diff 710/512 HFA 3                                                                     
 [2014-02-05 10:15:10] HFA 21: hfa_send_frame: USB Send error, ret -5 amount 64 vs. tx_length 64                               
 [2014-02-05 10:15:10] HFA21: send_packet: OP_USB_INIT USB Send error, ret -4 amount 0 vs. length 8                             
 [2014-02-05 10:15:10] HFA 21: Failed to reset after write failure, disabling                                                   
 [2014-02-05 10:15:11] HFA 21 failure, disabling!                                                                               
 [2014-02-05 10:15:11] HFA 21: hfa_send_frame: USB Send error, ret -4 amount 0 vs. tx_length 8                                 
 [2014-02-05 10:15:15] Accepted 1f29f70a Diff 2.1K/512 HFA 1                                                                   
 [2014-02-05 10:15:17] Accepted 1537e75f Diff 3.09K/512 HFA 1                                                                   
 [2014-02-05 10:15:21] Accepted 5bfd3c83 Diff 182K/512 HFA 3                                                                   
 [2014-02-05 10:15:22] Hotplug: Hashfast added HFA 22                                                                           
 [2014-02-05 10:15:25] Accepted 61ee0ec8 Diff 669/512 HFA 22                                                                   
 [2014-02-05 10:15:27] Accepted 7d126b85 Diff 524/512 HFA 22       

kenpofighta,  I had errors too saw them go down when I OC, it seems that the die's like temps in the 70's, mine game me errors when they ran at the 60 range, also see your  Pool Hashrate instead of the Cgminier Hashrate since it displays incorrect data .

[-ck]

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143).  However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

The code in git master needs new firmware which is not out yet.

[starsoccer9]

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143).  However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

The code in git master needs new firmware which is not out yet.

2 quick questions,

1. is it possible to just disable cgminer from seeing other hardware, for example BFL. I tried the only allowing usb device 1 or something but I have no way of figuring out which device is what number.

2. is there anyway to see each cores temp in windows like on the RPI?

[-ck]

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143).  However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

The code in git master needs new firmware which is not out yet.

2 quick questions,

1. is it possible to just disable cgminer from seeing other hardware, for example BFL. I tried the only allowing usb device 1 or something but I have no way of figuring out which device is what number.

2. is there anyway to see each cores temp in windows like on the RPI?

1. Read section on --usb in the README eg --usb HFA:1,BAS:0
2. Via the RPC API stats command which has busloads of information.
eg:
java API stats

Code:

[STATS8] =>
(
   [STATS] => 8
   [ID] => HFS3
   [Elapsed] => 45661
   [Calls] => 0
   [Wait] => 0.000000
   [Max] => 0.000000
   [Min] => 99999999.000000
   [asic count] => 12
   [core count] => 96
   [firmware rev] => 0.3
   [hardware rev] => 1.1
   [serial number] => 0xc10cfe86
   [hash clockrate] => 604
   [inflight target] => 2300
   [sequence modulus] => 8192
   [fan percent] => 56
   [rx preambles] => 2
   [rx rcv byte err] => 0
   [rx bad hcrc] => 0
   [tx attempts] => 0
   [tx packets] => 0
   [tx incompletes] => 0
   [tx ep stalled] => 0
   [tx disconnect] => 0
   [tx suspend] => 0
   [max tx buf] => 0
   [max rx buf] => 0
   [Core] => 0
   [hash clockrate] => 615
   [die temperature] => 79.300781
   [board temperature] => 65.489990
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 1
   [hash clockrate] => 615
   [die temperature] => 73.968750
   [board temperature] => 65.895256
   [core voltage] => 0: 0.80
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 2
   [hash clockrate] => 615
   [die temperature] => 79.242188
   [board temperature] => 64.298401
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 3
   [hash clockrate] => 615
   [die temperature] => 81.234375
   [board temperature] => 63.523308
   [core voltage] => 0: 0.78
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 5364
   [stats overrun] => 21
   [Core] => 4
   [hash clockrate] => 615
   [die temperature] => 83.871094
   [board temperature] => 75.037781
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 5
   [hash clockrate] => 615
   [die temperature] => 80.414062
   [board temperature] => 74.524971
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 6
   [hash clockrate] => 615
   [die temperature] => 80.589844
   [board temperature] => 69.744179
   [core voltage] => 0: 0.78
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 7
   [hash clockrate] => 615
   [die temperature] => 87.503906
   [board temperature] => 73.768532
   [core voltage] => 0: 0.78
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 8
   [hash clockrate] => 615
   [die temperature] => 78.070312
   [board temperature] => 66.304733
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 9
   [hash clockrate] => 615
   [die temperature] => 76.429688
   [board temperature] => 69.297256
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 10
   [hash clockrate] => 615
   [die temperature] => 78.070312
   [board temperature] => 68.855446
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [Core] => 11
   [hash clockrate] => 615
   [die temperature] => 75.375000
   [board temperature] => 72.299377
   [core voltage] => 0: 0.79
   [core voltage] => 1: 0.00
   [core voltage] => 2: 0.00
   [core voltage] => 3: 0.00
   [core voltage] => 4: 0.00
   [core voltage] => 5: 0.00
   [rx header crc] => 0
   [rx body crc] => 0
   [rx header to] => 0
   [rx body to] => 0
   [cn fifo full] => 0
   [an fifo full] => 0
   [stats overrun] => 0
   [raw hashcount] => 54752187254833152
   [calc hashcount] => 50974458467488978
   [no matching work] => 675
   [resets] => 0
   [USB Pipe] => 0
   [USB Delay] => r0 0.000000 w0 0.000000
   [USB tmo] => 13598514 0
)

[targetalk]

[Suspicious link removed]

Thank you for you help minternj. I downloaded 3.12.0 and it looks can see the device, but still gave an error:
[2014-02-04 22:49:28] USB all: found 3 devices - listing known devices
.USB dev 0: Bus 2 Device 127 ID: 297c:0001
  ** dev 0: Failed to open, err -3                   
 [2014-02-04 22:49:28] 1 known USB devices                   

Read the fine document called ASIC-README included with cgminer.

Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`

But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.

Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.

[legendroute]

Hi Phil,
It seems that it is the issue of the SD card you shipped. I replaced that card with my sandisk which is working now.
I think the SD card you provided is too thin so that the pins do not contact properly in the slot in the RB Pi. My sandisk card is much thicker and after I plug it in, I can feel solid contact. Anyway, thank you for your help. I can see it's hashing at 415G/s but for your default BTC address, will switch to my address and see. 

Awesome, Glad to hear it!  Is the original SD card we shipped actually a "no name" Micro SD inside an adapter with the Raspberry Pi logo on it?  We got those specifically because they are "official" RPI cards, so they'd be the most likely to work well, but it's turning out that they stink.  We'll test some different ones for the next batch.

BTW, any time you build a new image, the first time it boots, it makes a new bitcoin wallet (viewable on the "wallet" page of the web UI), and begins mining with that wallet.  Be sure if it made any BTC that you don't forget to collect it!  If you make a backup from the settings page, the wallet is also backed up and restored.  If you want to change to a new wallet or mining username, that's done on the "pools" page of the web UI.  If you ever restore from a previous backup, it puts all your original settings in, so it's a good idea to make a backup once you get things dialed in like you want.  (In case an SD card dies or something.)

-Phil

Hi Phil,
Yes the defective SD card is the default RB Pi card with the log on it. I can not say it's the card's issue because it works fine on my computer, I think it just does not fit well with the slot in the Pi. But the fix is definitely use a thicker card.

I don't really understand the collection from the default wallet? Do you mean there is a default wallet created on the Raspberry Pi and there could be BTC already generated during the test? In my case cause I have never get original card boot successfully, and just created new card from downloaded image, does that mean I lost the original wallet already? And I also don't understand how to use that wallet and transfer the BTC out? Is there a wallet application on RB Pi? Or I just recover this wallet on another computer using the key pare? Thanks!

[HF-Engineer]

If you use our RPI image as configured, you will have a reliable mining system and will get updates as they are made available.  Here's my personal system mining away: http://setup.hashfast.com/rpi/

-Phil

Just curious, what core clock are you running this at? I ran mine at default (550) for a day and it got about 400GH/s, 0.37% rejects, and 1.83% errors and showed 360GH/s on eligius. Overnight I started it at 560 and it shows 412GH/s, 0.36% rejects, and 9.26% errors with 388GH/s showing on eligius. Should I be worried about 9.26% error rate? They run at 80C/80C/70C/72C right now.

It's running at 600.  You can see that it's not totally stable at that speed, it gets the "work watchdog restart" often, but overall the hashrate is higher because it resumes hashing almost immediately if it stops.  MinePeon's stats page looks silly, but that matters is the pool's reported hashrate which you can see here:
http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87Ahd

Only worry about the error rate if it starts to lower your overall rate. 

-Phil

[HF-Engineer]

Here's the source code: http://setup.hashfast.com/cgminer-3.9.0h2.tar.gz
(MD5: fdef15ae73b180deef74bc51df482eb0)

-Phil

Any Windows binaries available?

Sorry, we don't officially support windows as a platform.  I don't run it either, so I can't even unofficially help you out.  Maybe someone here you trust can compile it for you?

I firmly believe the RPI is a better platform your average windows machine, and the monitoring and remote capabilities MinePeon brings is nice to have.  I can pull up my miner on my phone and get text messages if it ever goes down.  (has yet to happen unless I unplug it!)

-Phil

[HF-Engineer]

I don't know how to get a message to ckolivas, but I'm testing the current master branch of cgminer and one feature that was added is fan speed control (OP code 143).  However, I keep getting the error that OP_CODE 143 is unhandled.

Is it possible that I have an older revision of the board/firmware something that doesn't support controlling the fan speed using that op code?

That's in the new firmware that's coming soon.  Sorry, until we complete testing we cannot release it.  I'll say it again; Until the new firmware comes out, you're best bet is to run 3.9.0hf2 that I've posted here.

-Phil

[HF-Engineer]

Anyone else getting forum errors?  Can't seem to reply to existing threads.  Seems like the SQL DB is corrupt or something.

-Phil

[HF-Engineer]

Hi Phil,
Yes the defective SD card is the default RB Pi card with the log on it. I can not say it's the card's issue because it works fine on my computer, I think it just does not fit well with the slot in the Pi. But the fix is definitely use a thicker card.

I don't really understand the collection from the default wallet? Do you mean there is a default wallet created on the Raspberry Pi and there could be BTC already generated during the test? In my case cause I have never get original card boot successfully, and just created new card from downloaded image, does that mean I lost the original wallet already? And I also don't understand how to use that wallet and transfer the BTC out? Is there a wallet application on RB Pi? Or I just recover this wallet on another computer using the key pare? Thanks!

This is why I always ask people to make a backup.

Yes, a new wallet is generated the first time each new image is booted on the RPI.  It then begins mining with that wallet, it's yours to keep.  We test all BJ's at the factory like that, and some machines end up mining overnight, so there's sometimes a good bit of coin in there!  I absolutely hate "orphaning" any BTC regardless of amount, as it's forever lost.

See if you can get that old card to boot, even if you have to take the case off the RPI and hold down the card.  We've yet to see that particular problem.  Maybe it's just a bent contact on your RPI's socket?  A closer inspection may reveal why.

If you can get it to boot, the wallet is visible on the "Wallet" page from the web interface, and if you make a backup from the settings page, it will contain the wallet.

-Phil 

[HF-Engineer]

,

I was getting great performance when my 3 BJ's arrived. At least on two of them, there was one that seemed a bit flakey and seems to be getting worse. All 3 seem to be getting worse. One of them keeps shutting down and restarting grabbing a new ID each time. I posted a small capture from my monitor so that maybe if others have had this and fixed it they can help. This one that is flaky was delivered in poor condition, all but one screw was sliding around the inside of the box and 4 risers that prop the board up were also floating around. I though the board was damaged and it may be. Worst assembly I have ever seen and I used to build PC's. That point is mute if they all work but they don't.

Here is what I need help answering.
1. How do I get back to my 400+ GH performance. All three of these were pushing +-420GH.
2. Worse case scenario is how do I raise the clock speed to get up to the 400GH range? I was promised by Erin at Hashfast that it would not void the warranty but the delivery paperwork stated otherwise. I will have to deal with that warranty issue separately, I know.
3. I seem to be getting huge error rates, I think it is on the flaky board but not 100% sure that is the only place. 70% to 80% errors are common. Elgius reports I am only getting 900 to 950 GH/s AVG with 3 boards and I should be getting closer to 1200. Not good for profits. Any help would be appreciated. I hate to try and send a board back under warranty since I might be stuck for months. I still am waiting on my 3 upgrades, I would hat to be down to 2 processors if I can avoid it.

Sorry about the loose parts.  The problem wasn't bad assembly, it was the parts coming loose during shipping.  They are using threadlock now to stop that problem.   It's unlikely your boards are damaged if they are hashing on all 4 die, which sounds like they are.

What are your die temps and voltages?  (if you run the "hf" version of cgminer it reports all dies/voltages)

Since your unit obviously had quite a ride during shipping, I'd look at each die temp and see if there is a discrepancy.  You might need to take the cooler head off, re-grease the thermal interface, and re-tighten the cooler.  Apparently some of those earlier orders that had loose standoffs have a high chance of having a loose cooler.

Also, what hash clock speed are you using?   Have you tired other speeds?

-Phil

[legendroute]

Hi Phil,
It seems that it is the issue of the SD card you shipped. I replaced that card with my sandisk which is working now.
I think the SD card you provided is too thin so that the pins do not contact properly in the slot in the RB Pi. My sandisk card is much thicker and after I plug it in, I can feel solid contact. Anyway, thank you for your help. I can see it's hashing at 415G/s but for your default BTC address, will switch to my address and see. 

Awesome, Glad to hear it!  Is the original SD card we shipped actually a "no name" Micro SD inside an adapter with the Raspberry Pi logo on it?  We got those specifically because they are "official" RPI cards, so they'd be the most likely to work well, but it's turning out that they stink.  We'll test some different ones for the next batch.

BTW, any time you build a new image, the first time it boots, it makes a new bitcoin wallet (viewable on the "wallet" page of the web UI), and begins mining with that wallet.  Be sure if it made any BTC that you don't forget to collect it!  If you make a backup from the settings page, the wallet is also backed up and restored.  If you want to change to a new wallet or mining username, that's done on the "pools" page of the web UI.  If you ever restore from a previous backup, it puts all your original settings in, so it's a good idea to make a backup once you get things dialed in like you want.  (In case an SD card dies or something.)

-Phil

Also Phil, I have two more questions:
1. I can see some errors in cgminer out put, how to fix them?
https://i.imgur.com/eG8L8XV.png
As you can see the hardware error is keep going up, is this normal?
Also the first line of the scroll-able zone there is an error message:
HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND 
How to fix it?

2. Second, with default configuration, from cgminer's interface I can see the hash rate is always around 400GH/s. But from pool statistics average is only between 320 to 380. How to explain that? Can I say my BJ does not perform as described in specification?
Thanks you!
https://i.imgur.com/CaBvWqB.png

[freddyfarnsworth]

Anyone else getting forum errors?  Can't seem to reply to existing threads.  Seems like the SQL DB is corrupt or something.

-Phil

Yup. it was last night however for me.

[HF-Engineer]

Also Phil, I have two more questions:
1. I can see some errors in cgminer out put, how to fix them?
[image snipped]
As you can see the hardware error is keep going up, is this normal?
Also the first line of the scroll-able zone there is an error message:
HFA 0 attempted reset got err:(-5) LIBUSB_ERROR_NOT_FOUND 
How to fix it?

2. Second, with default configuration, from cgminer's interface I can see the hash rate is always around 400GH/s. But from pool statistics average is only between 320 to 380. How to explain that? Can I say my BJ does not perform as described in specification?
Thanks you!
[image snipped]

In both these cases, we hope the new firmware will help correct these issues.  It's absolutely normal to have some hardware errors.  We have fixed the source of some of these in the upcoming firmware.  Con Kolivas is also working with us to make many improvements in cgminer, so we will release both together as soon as we can.

You should be able to get about 400Gh/s at the pool (average) though you might have to clock to 600mhz to get it at present.

My test system at http://setup.hashfast.com/rpi/ is running at 600, it's got a bunch of errors, but as you can see from the pool stats on Eligius it's cruising along at about 428Gh/s for the 12 hour average:
http://eligius.st/~wizkid057/newstats/userstats.php/17ao2fT7gbnnKYpMd7x29E8p4oGdE87Ahd

The longer timeframe stats on Eligius tend to be more accurate and useful.  The stuff under 3 hours is hit-or-miss.

-Phil

[-ck]

[Suspicious link removed]

Thank you for you help minternj. I downloaded 3.12.0 and it looks can see the device, but still gave an error:
[2014-02-04 22:49:28] USB all: found 3 devices - listing known devices
.USB dev 0: Bus 2 Device 127 ID: 297c:0001
  ** dev 0: Failed to open, err -3                   
 [2014-02-04 22:49:28] 1 known USB devices                   

Read the fine document called ASIC-README included with cgminer.

Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`

But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.

Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.

That wasn't all the instructions that were in the readme, you need the udev file installed. That other command is usually not needed in fact - but I don't know how permissions are set up on minepeon as the instructions revolve around regular PCs running regular PC distributions of linux and I'm no RPi distribution expert. It is always a permissions problem if it goes away as root.

[HF-Engineer]

Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`

But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.

Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.

That wasn't all the instructions that were in the readme, you need the udev file installed. That other command is usually not needed in fact - but I don't know how permissions are set up on minepeon as the instructions revolve around regular PCs running regular PC distributions of linux and I'm no RPi distribution expert. It is always a permissions problem if it goes away as root.

Thanks Con.  The RPI is set up to run cgminer as the user "minepeon".  By default it is correctly set for this, no changes to UDEV or permissions.

Targetalk: If you are compiling your own version, you need to be sure you have enabled the HashFast driver support before compiling:

Code:

./configure --enable-hashfast

You should not need to do anything else if you have correctly run the autogen script.

Of course none of this is needed if you use the default version we supply.  We will be sending out Con's latest as soon as everything is finalized and tested.

-Phil

[Gyrsur]

watching

[joshv06]

I am here working at the DataCenter working on the BJ's. I have 12, want to put 2/case.

Where do I plug the motherboard power for the 2nd BJ into on the Power supply?

There is one port labeled "MB" on the power supply. It is already taken by the first BJ.

Any Immediate help is greatly appreciated.

Thanks

[legendroute]

Thank you ckolivas. I figured that it's the permission issue. And I followed the guide and added current user into plugdev group by issuing:
sudo usermod -G plugdev -a `whoami`

But it does not fix the problem. In this case does that mean I can only run cgminer under root user? Or you think it's not the issue of permission? Please kindly point out.
Also I logged into my RB Pi and can see cgminer is running under minepeon user and that user belongs only to minepeon group.

Anyway thank you for you help, I have made my RB Pi working now, so have no chance to test BJ on my linux box for now. Will report when I get a chance.

That wasn't all the instructions that were in the readme, you need the udev file installed. That other command is usually not needed in fact - but I don't know how permissions are set up on minepeon as the instructions revolve around regular PCs running regular PC distributions of linux and I'm no RPi distribution expert. It is always a permissions problem if it goes away as root.

Thanks Con.  The RPI is set up to run cgminer as the user "minepeon".  By default it is correctly set for this, no changes to UDEV or permissions.

Targetalk: If you are compiling your own version, you need to be sure you have enabled the HashFast driver support before compiling:

Code:

./configure --enable-hashfast

You should not need to do anything else if you have correctly run the autogen script.

Of course none of this is needed if you use the default version we supply.  We will be sending out Con's latest as soon as everything is finalized and tested.

-Phil

Hi Phil,
Yes, I compiled cgminer with --enable-hashfast on my xubuntu. It can detect HF device but can not enable the device, that's why I think it's permission issue.