OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 146.

RoboCoder

sr. member

Activity: 388

Merit: 250

Save A Life, Adopt a Pet Today!

Quote from: Zeronic on July 30, 2013, 05:50:30 PM

Quote from: Luke-Jr on July 30, 2013, 01:24:24 PM

Quote from: Zeronic on July 30, 2013, 08:10:23 AM

Results of working on getting BFGMiner to work with X6500.

Using libusb-win32_1.2.6.0
http://sourceforge.net/projects/libusb-win32/?source=dlp

http://pastebin.com/bn8tecQT

Luke can we got a known working version or a better suggestion please?

All current versions are known working - I wouldn't release them if they didn't work.
There is no sign of a X6500 on your USB bus in the pastebin, with or without the correct driver.
X6500 is 0403:6001

http://tinypic.com/r/26126g5/5

I'm kind of lost at this point.

I have exactly this same problem. If i run 3.11 they are reconized and work properly, but if i run 3.13 i get the same error. (so i am running

jml

full member

Activity: 238

Merit: 100

Quote from: Luke-Jr on July 30, 2013, 04:54:26 PM

Quote from: jml on July 30, 2013, 04:38:19 PM

Update: HUPed after 3 hours operation.

What do you mean by HUPed?
The HUP signal is sent when you close the terminal...

HUP happens because I use SSH to open a terminal. When I try to SSH back in, I can't. This is why I need to power it down and then back up again.

Zeronic

member

Activity: 243

Merit: 10

Quote from: Luke-Jr on July 30, 2013, 01:24:24 PM

Quote from: Zeronic on July 30, 2013, 08:10:23 AM

Results of working on getting BFGMiner to work with X6500.

Using libusb-win32_1.2.6.0
http://sourceforge.net/projects/libusb-win32/?source=dlp

http://pastebin.com/bn8tecQT

Luke can we got a known working version or a better suggestion please?

All current versions are known working - I wouldn't release them if they didn't work.
There is no sign of a X6500 on your USB bus in the pastebin, with or without the correct driver.
X6500 is 0403:6001

http://tinypic.com/r/26126g5/5

I'm kind of lost at this point.

Xer0

hero member

Activity: 826

Merit: 1000

°^°

runs very well on a TP-Link MR3020 (WR703N)

Thanks!

(now i just need come watchdog stuff for failsafe things)

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: jml on July 30, 2013, 04:38:19 PM

Update: HUPed after 3 hours operation.

What do you mean by HUPed?
The HUP signal is sent when you close the terminal...

jml

full member

Activity: 238

Merit: 100

Quote from: jml on July 30, 2013, 04:30:04 PM

Luke,

I have been running CM1's within a single USB channel and allowed ZTEX and BE's to run on another USB channel connected to the raspberry pi.

So here is the way they are connected:

Raspberry pi = 2 USB ports (a)

(a) 1 USB port has USB 4 port hub (1)
(a) 1 USB port has USB 4 port hub (2)

(1) 4 port hub has one ZTEX link and 2 DLINK 7 port hub links
(2) 4 port hub has 2 CM1's connected

I think the CM1's and BE's don't seem to like sharing the same USB hub channel. That is my theory for now.
I have had these running now for 3+ hours as the pi usually HUPs in about one hour.

Update: HUPed after 3 hours operation.

jml

full member

Activity: 238

Merit: 100

Luke,

I have been running CM1's within a single USB channel and allowed ZTEX and BE's to run on another USB channel connected to the raspberry pi.

So here is the way they are connected:

Raspberry pi = 2 USB ports (a)

(a) 1 USB port has USB 4 port hub (1)
(a) 1 USB port has USB 4 port hub (2)

(1) 4 port hub has one ZTEX link and 2 DLINK 7 port hub links
(2) 4 port hub has 2 CM1's connected

I think the CM1's and BE's don't seem to like sharing the same USB hub channel. That is my theory for now.
I have had these running now for 3+ hours as the pi usually HUPs in about one hour.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Zeronic on July 30, 2013, 08:10:23 AM

Results of working on getting BFGMiner to work with X6500.

Using libusb-win32_1.2.6.0
http://sourceforge.net/projects/libusb-win32/?source=dlp

http://pastebin.com/bn8tecQT

Luke can we got a known working version or a better suggestion please?

All current versions are known working - I wouldn't release them if they didn't work.
There is no sign of a X6500 on your USB bus in the pastebin, with or without the correct driver.
X6500 is 0403:6001

jml

full member

Activity: 238

Merit: 100

I had running the ztex fpga with the BE and no problems; has been running for more than 12 hours.

Zeronic

member

Activity: 243

Merit: 10

Results of working on getting BFGMiner to work with X6500.

Using libusb-win32_1.2.6.0
http://sourceforge.net/projects/libusb-win32/?source=dlp

http://pastebin.com/bn8tecQT

Luke can we got a known working version or a better suggestion please?

jml

full member

Activity: 238

Merit: 100

As it is, the pi can either run the FPGA's on its own, or run solely with the BE's, but not both as it causes the pi to hang up.

jml

full member

Activity: 238

Merit: 100

https://dl.dropboxusercontent.com/u/22873106/messages

vpereira

newbie

Activity: 52

Merit: 0

no clue on your /var/log/messages?

jml

full member

Activity: 238

Merit: 100

Quote from: Luke-Jr on July 29, 2013, 02:50:57 PM

Quote from: jml on July 29, 2013, 05:56:15 AM

Quote from: vpereira on July 29, 2013, 02:42:00 AM

but you still want to run it with sudo, with you normally must run with sudo, othewise you are not allowed to open the FPGA communication. I think you will loose too much time with something that in the end won't be useful (once you are in the gdb shell, then what you want to look there?) maybe it would be useful a core file, if one is being generated, or a traceback from the problem in a text file... if you aren't developer, a gdb shell won't help you.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.

So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others Cheesy

Before you 'run' in gdb, do

Code:

handle SIGILL nostop noprint pass

Hi Luke,

I have executed the line you gave and I can run bfgminer within gdb. The problem is that when the application crashes, it causes the pi to hang. I cannot SSH back into it and I need to switch it off and then back off.

I am a bit confused in using the thr command as the thread is killed after I need to reboot.

Any suggestions? Maybe piping execution code to a file?

jml

full member

Activity: 238

Merit: 100

Quote from: vpereira on July 29, 2013, 11:52:34 AM

he wrote in his post.. after you run it and it aborts, you should run in the gdb shell:

thr app all bt

and paste the backtrace here.. but as I C developer, you should know how to get this backtrace anyway Wink

anyway I had a strange problem as well, involving a X6500, that it simply gone as soon as I removed it from the USB hub and gave to it a dedicated USB port and in my experience, the USB hub is a common source of problem.

Quote from: jml on July 29, 2013, 05:56:15 AM

Quote from: vpereira on July 29, 2013, 02:42:00 AM

but you still want to run it with sudo, with you normally must run with sudo, othewise you are not allowed to open the FPGA communication. I think you will loose too much time with something that in the end won't be useful (once you are in the gdb shell, then what you want to look there?) maybe it would be useful a core file, if one is being generated, or a traceback from the problem in a text file... if you aren't developer, a gdb shell won't help you.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.

So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others Cheesy

True, but he said to run that after it crashes, not to abort which is a voluntary action. In my case, the pi needs a hard reboot.

Anyway, I have been trying it out with 2 BE on the hub and seems to go well for now going 24hours.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: jml on July 29, 2013, 05:56:15 AM

Quote from: vpereira on July 29, 2013, 02:42:00 AM

but you still want to run it with sudo, with you normally must run with sudo, othewise you are not allowed to open the FPGA communication. I think you will loose too much time with something that in the end won't be useful (once you are in the gdb shell, then what you want to look there?) maybe it would be useful a core file, if one is being generated, or a traceback from the problem in a text file... if you aren't developer, a gdb shell won't help you.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.

So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others Cheesy

Before you 'run' in gdb, do

Code:

handle SIGILL nostop noprint pass

vpereira

newbie

Activity: 52

Merit: 0

he wrote in his post.. after you run it and it aborts, you should run in the gdb shell:

thr app all bt

and paste the backtrace here.. but as I C developer, you should know how to get this backtrace anyway Wink

anyway I had a strange problem as well, involving a X6500, that it simply gone as soon as I removed it from the USB hub and gave to it a dedicated USB port and in my experience, the USB hub is a common source of problem.

Quote from: jml on July 29, 2013, 05:56:15 AM

Quote from: vpereira on July 29, 2013, 02:42:00 AM

but you still want to run it with sudo, with you normally must run with sudo, othewise you are not allowed to open the FPGA communication. I think you will loose too much time with something that in the end won't be useful (once you are in the gdb shell, then what you want to look there?) maybe it would be useful a core file, if one is being generated, or a traceback from the problem in a text file... if you aren't developer, a gdb shell won't help you.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.

So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others Cheesy

fabrizziop

hero member

Activity: 506

Merit: 500

Hey, I'm in ubuntu 13.04 x64 mining scrypt. BFGMiner hangs if my internet connection goes down, it gives a segmentation fault. It only happens when the internet is down (it doesn't matter if the actual interface is down, as I used a switch and unplugged my pfsense router from switch, BFGMiner crashed). Is there any script that if BFGMiner stops then it starts it again?.

Thanks in advance.

edit: quick ugly solution, run the miner with this scrypt:

Code:

#!/bin/sh
export DISPLAY=:0
export GPU_MAX_ALLOC_PERCENT=100
export GPU_USE_SYNC_OBJECTS=1
while true
do
bfgminer PLACE SETTINGS HERE
done

jml

full member

Activity: 238

Merit: 100

Quote from: vpereira on July 29, 2013, 02:42:00 AM

but you still want to run it with sudo, with you normally must run with sudo, othewise you are not allowed to open the FPGA communication. I think you will loose too much time with something that in the end won't be useful (once you are in the gdb shell, then what you want to look there?) maybe it would be useful a core file, if one is being generated, or a traceback from the problem in a text file... if you aren't developer, a gdb shell won't help you.

Vpereira, FYI, If you read a couple of posts back, Luke asked for the backtrace which I am trying to deliver and since I am not involved in this project, there is no way I will be able to familiarise myself in time with the code so that I know what the problem is. If I asked you to look into an unfamiliar mature project with several KLOC, I suspect you would be in the same position as I am.

So here is an update
===============
I have been testing all night two separate hosts; one with the 7 BE running windows bfgminer 3.1.3 and the pi running 3.1.2 with the FPGA's (2 CM1 and the ZTEX 1.15x). No problems so far, I believe I can rule out the power issue.

PS: I am a Java and ANSI-C developer amongst many others Cheesy

drewage

member

Activity: 262

Merit: 10

I wanted to install MacMiner on a Mac Mini late 2006 but currently it isn't compiled for 32 bit support. If I install Ubuntu 10.04, which is the recommended version for this hw, will I still be able to install bfgminer from the PPA? Is it compiled for 32 bit support? I tried to compile it, bfgminer, using Xcode but it kept throwing errors related to the fact that Snow Leopard apparently uses a legacy version of C or ObjC. Or will I have to upgrade the hardware and go from there?

By the way, I'm not all that adept in a shell environment but I'm willing to try... Grin

Topic: OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB - page 146. (Read 1193223 times)