Bitcoin Forum
December 09, 2016, 09:42:32 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 [90] 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251386 times)
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 04, 2012, 12:05:09 PM
 #1781

...
Kano,

My intent was to suggest an option to software reset the CM1 boards when they stop performing as expected. Can cgminer reset cards mid-mining? If so, can we automate this for when they crash?
No.
cgminer has an API where you can ask it for information
You can then act on that information
(including telling cgminer to stop or even restart or many other commands as documented in API-README)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
1481319752
Hero Member
*
Offline Offline

Posts: 1481319752

View Profile Personal Message (Offline)

Ignore
1481319752
Reply with quote  #2

1481319752
Report to moderator
1481319752
Hero Member
*
Offline Offline

Posts: 1481319752

View Profile Personal Message (Offline)

Ignore
1481319752
Reply with quote  #2

1481319752
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481319752
Hero Member
*
Offline Offline

Posts: 1481319752

View Profile Personal Message (Offline)

Ignore
1481319752
Reply with quote  #2

1481319752
Report to moderator
1481319752
Hero Member
*
Offline Offline

Posts: 1481319752

View Profile Personal Message (Offline)

Ignore
1481319752
Reply with quote  #2

1481319752
Report to moderator
1481319752
Hero Member
*
Offline Offline

Posts: 1481319752

View Profile Personal Message (Offline)

Ignore
1481319752
Reply with quote  #2

1481319752
Report to moderator
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
August 04, 2012, 04:47:43 PM
 #1782

@yohan : upgrading controller with a Linux system ? This is the 4th time I ask this here, I'm beginning to wonder what's going on.

We are going to try and cross compile the existing windows utility to Linux but it is a case of stopping work on other things to do this. Not a promise but I will see if we can do that this week.
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
August 04, 2012, 04:58:06 PM
 #1783

...
Kano,

My intent was to suggest an option to software reset the CM1 boards when they stop performing as expected. Can cgminer reset cards mid-mining? If so, can we automate this for when they crash?
No.
cgminer has an API where you can ask it for information
You can then act on that information
(including telling cgminer to stop or even restart or many other commands as documented in API-README)

If we put support into the Controller and the array FPGA supports reset on a suitable pin (and uses it suitably internally) it's possible to do 2 things on CM1 for a frozen/under-performing FPGA issue. The first is we can apply a reset to an individual array FPGA or any combination of them. We can also switch off the 1.2V rails individually from the controller. The 3.3V can be turned off as well but that is across all 4 FPGAs.

The are several ways these things can be implemented. Anything from in-band messaging to using spare I/Os from the FTDI interface.
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 04, 2012, 05:31:53 PM
 #1784

In getting my rig up and running I've run across an issue.

Up to board #5 everything went relatively smoothly in flashing the makomk 190 bitstream to SPI. however when I went to flash the 6th (which went well) and plugged everything back in, the 5th was not able to detect one com. I unplugged the USB and plugged it back in and both coms on #5 stopped responding. unplugged #5 and reset, plugged back in, and still nothing. Unplugged #6 and tried again, still nothing. Plugged in #5 solo and nothing. Deleted #5's drivers and reinstalled and still no response on any of the COM ports.

It was working fine until I flashed the 6th (with all other boards disconnected) and decided to stop responding. I've reset, rebooted, switched out usb's, switched hubs, tried with multiple cards and just the single. All the other cards run fine, just #5 w/ the issue.

any ideas?


also, Win 7 64 w/ the latest cgminer build.

Thanks in advance,
Steamboat

ASIC miners available for purchase

Those who serve best, profit most.
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
August 04, 2012, 05:39:48 PM
 #1785

In getting my rig up and running I've run across an issue.

Up to board #5 everything went relatively smoothly in flashing the makomk 190 bitstream to SPI. however when I went to flash the 6th (which went well) and plugged everything back in, the 5th was not able to detect one com. I unplugged the USB and plugged it back in and both coms on #5 stopped responding. unplugged #5 and reset, plugged back in, and still nothing. Unplugged #6 and tried again, still nothing. Plugged in #5 solo and nothing. Deleted #5's drivers and reinstalled and still no response on any of the COM ports.

It was working fine until I flashed the 6th (with all other boards disconnected) and decided to stop responding. I've reset, rebooted, switched out usb's, switched hubs, tried with multiple cards and just the single. All the other cards run fine, just #5 w/ the issue.

any ideas?


also, Win 7 64 w/ the latest cgminer build.

Thanks in advance,
Steamboat


This sounds a bit like the FTDI issue I described yesterday. I don't have the full details but there is a utility from FTDI to do a clean-up which followed by clean install might solve the issue. Normal uninstall doesn't appear to be enough if it is this. I think some registry entires are left that cause the issue and hence the utility. I will try and get more details of the how and what on this on Monday.

On a more mundane level have you tried a complete power-off and boot as opposed to reboot and clean plugin and bring up afterwards?

Also if you had dip switches set for programming did you put them to the correct settings for running?
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
August 04, 2012, 05:40:40 PM
 #1786

@yohan : upgrading controller with a Linux system ? This is the 4th time I ask this here, I'm beginning to wonder what's going on.

We are going to try and cross compile the existing windows utility to Linux but it is a case of stopping work on other things to do this. Not a promise but I will see if we can do that this week.

Yohan, would it be possible to provide either the Windows source code of SPIProg, or at least a detailed description of what it does? I'd be glad to support you with getting this part working with Linux. It might be even doable with a script on top of the xc3sprog tools.

Allowing you to concentrate on more important things (controller FW) is currently for sure the best contribution we could get.

Thanks.

steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 04, 2012, 05:42:09 PM
 #1787

In getting my rig up and running I've run across an issue.

Up to board #5 everything went relatively smoothly in flashing the makomk 190 bitstream to SPI. however when I went to flash the 6th (which went well) and plugged everything back in, the 5th was not able to detect one com. I unplugged the USB and plugged it back in and both coms on #5 stopped responding. unplugged #5 and reset, plugged back in, and still nothing. Unplugged #6 and tried again, still nothing. Plugged in #5 solo and nothing. Deleted #5's drivers and reinstalled and still no response on any of the COM ports.

It was working fine until I flashed the 6th (with all other boards disconnected) and decided to stop responding. I've reset, rebooted, switched out usb's, switched hubs, tried with multiple cards and just the single. All the other cards run fine, just #5 w/ the issue.

any ideas?


also, Win 7 64 w/ the latest cgminer build.

Thanks in advance,
Steamboat


This sounds a bit like the FTDI issue I described yesterday. I don't have the full details but there is a utility from FTDI to do a clean-up which followed by clean install might solve the issue. Normal uninstall doesn't appear to be enough if it is this. I think some registry entires are left that cause the issue and hence the utility. I will try and get more details of the how and what on this on Monday.

On a more mundane level have you tried a complete power-off and boot as opposed to reboot and clean plugin and bring up afterwards?

I completely shut down, unplugged the usb, unplugged power to the CM1, plugged in the power again, turned on computer, plugged in usb. no-go

ASIC miners available for purchase

Those who serve best, profit most.
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
August 04, 2012, 05:44:10 PM
 #1788

@yohan : upgrading controller with a Linux system ? This is the 4th time I ask this here, I'm beginning to wonder what's going on.

We are going to try and cross compile the existing windows utility to Linux but it is a case of stopping work on other things to do this. Not a promise but I will see if we can do that this week.

Yohan, would it be possible to provide either the Windows source code of SPIProg, or at least a detailed description of what it does? I'd be glad to support you with getting this part working with Linux. It might be even doable with a script on top of the xc3sprog tools.

Allowing you to concentrate on more important things (controller FW) is currently for sure the best contribution we could get.

Thanks.

Probably is the answer. I'll talk it through with the team on Monday to see if there are any issues in doing this e.g. partner IP that we can't release.
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
August 04, 2012, 05:47:19 PM
 #1789

In getting my rig up and running I've run across an issue.

Up to board #5 everything went relatively smoothly in flashing the makomk 190 bitstream to SPI. however when I went to flash the 6th (which went well) and plugged everything back in, the 5th was not able to detect one com. I unplugged the USB and plugged it back in and both coms on #5 stopped responding. unplugged #5 and reset, plugged back in, and still nothing. Unplugged #6 and tried again, still nothing. Plugged in #5 solo and nothing. Deleted #5's drivers and reinstalled and still no response on any of the COM ports.

It was working fine until I flashed the 6th (with all other boards disconnected) and decided to stop responding. I've reset, rebooted, switched out usb's, switched hubs, tried with multiple cards and just the single. All the other cards run fine, just #5 w/ the issue.

any ideas?


also, Win 7 64 w/ the latest cgminer build.

Thanks in advance,
Steamboat


This sounds a bit like the FTDI issue I described yesterday. I don't have the full details but there is a utility from FTDI to do a clean-up which followed by clean install might solve the issue. Normal uninstall doesn't appear to be enough if it is this. I think some registry entires are left that cause the issue and hence the utility. I will try and get more details of the how and what on this on Monday.

On a more mundane level have you tried a complete power-off and boot as opposed to reboot and clean plugin and bring up afterwards?

I completely shut down, unplugged the usb, unplugged power to the CM1, plugged in the power again, turned on computer, plugged in usb. no-go

Ok I will try and get more info on this on Monday but as usual I would recommend you send an email into the bitcoin.support email as a backup so that all of the team see what problems you have.
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 04, 2012, 05:51:52 PM
 #1790

In getting my rig up and running I've run across an issue.

Up to board #5 everything went relatively smoothly in flashing the makomk 190 bitstream to SPI. however when I went to flash the 6th (which went well) and plugged everything back in, the 5th was not able to detect one com. I unplugged the USB and plugged it back in and both coms on #5 stopped responding. unplugged #5 and reset, plugged back in, and still nothing. Unplugged #6 and tried again, still nothing. Plugged in #5 solo and nothing. Deleted #5's drivers and reinstalled and still no response on any of the COM ports.

It was working fine until I flashed the 6th (with all other boards disconnected) and decided to stop responding. I've reset, rebooted, switched out usb's, switched hubs, tried with multiple cards and just the single. All the other cards run fine, just #5 w/ the issue.

any ideas?


also, Win 7 64 w/ the latest cgminer build.

Thanks in advance,
Steamboat


This sounds a bit like the FTDI issue I described yesterday. I don't have the full details but there is a utility from FTDI to do a clean-up which followed by clean install might solve the issue. Normal uninstall doesn't appear to be enough if it is this. I think some registry entires are left that cause the issue and hence the utility. I will try and get more details of the how and what on this on Monday.

On a more mundane level have you tried a complete power-off and boot as opposed to reboot and clean plugin and bring up afterwards?

I completely shut down, unplugged the usb, unplugged power to the CM1, plugged in the power again, turned on computer, plugged in usb. no-go

Ok I will try and get more info on this on Monday but as usual I would recommend you send an email into the bitcoin.support email as a backup so that all of the team see what problems you have.

sounds good. I'm going to continue flashing the rest of the boards and come back to #5. Hopefully it's the only one w/ that issue.

ASIC miners available for purchase

Those who serve best, profit most.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 04, 2012, 06:35:16 PM
 #1791

Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 04, 2012, 06:48:33 PM
 #1792

HowTo deinstall drivers completely from device manager in windows 7:

First:


This will enable to see all drivers in the device manager that are not used but still installed.
Code:
Name: devmgr_show_nonpresent_devices
Value: 1


Next open device manager and click this:



Then you will see grey entries like this:



Right click a grey entry and chose deinstall:



If you want to deinstall that driver comletely from windows, check the option:


Now make this with every device you want to deinstall from windows and you can start again to install. This works for me on every attempt when i had problems with a driver. I had this when i was playing with libusb.

You can also don't check the option to deinstall completely, just deinstall the device, in this case a replugin of the device will cause new COM selection for this device. In most cases this is enought to get the Cairnsmore working again.

I hope you find this one usefull =)

eb
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
August 04, 2012, 08:22:00 PM
 #1793

common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore)
I don't have the CM1 hardware, but I watch this thread and I have to ask:

Why not using PLL_ADV in front of the DCM to filter out the jitter? Just from looking at the floorplan of Spartan-6 the PLL_ADV block is about twice the size of the DCM block. With BANDWIDTH=LOW it should serve as a decent jitter filter.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 04, 2012, 09:26:36 PM
 #1794

Update on latest bitstreams after 4 days:
Total 40 FPGA's = 10 boards SN#400+.

Makomk's dcmwd2 oc bitstreams:
17x 200Mh, 22x 190Mh, 1x 180Mh. That means 97.50% of all fpga's running @190Mh+ with <2.8% invalids!

Working bitstreams in percent:
200Mh oc = 42.5%
190Mh oc = 97.5%
180Mh oc = 100%
170Mh oc = 100%
160Mh = 100%
150Mh = 100%
140Mh = 100%


Update Glasswalker's bitstreams:
not changed will update when new bitstream is out

eb
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 04, 2012, 09:55:43 PM
 #1795

I don't have the CM1 hardware, but I watch this thread and I have to ask:

Why not using PLL_ADV in front of the DCM to filter out the jitter? Just from looking at the floorplan of Spartan-6 the PLL_ADV block is about twice the size of the DCM block. With BANDWIDTH=LOW it should serve as a decent jitter filter.
I've actually got some changes locally to try and do that, but it turns out that mucking with clocking like that affects how ISE maps, places and routes everything for some reason so I'd have to do another long SmartXplorer run - and it's possible that after all that the clock issues would be severe enough that the PLL wouldn't lock either. Since these boards are apparently wired for differential clock signals it probably makes more sense to wait until those are available and try using the PLL with them if they're still not low-jitter enough.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
August 04, 2012, 10:21:14 PM
 #1796

it turns out that mucking with clocking like that affects how ISE maps, places and routes everything for some reason
Thanks for the clarification. Fortunately for me I never had the problems with on-board signals but only with off-the-board comms.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 05, 2012, 12:43:52 AM
 #1797

ebereon,

how many boards do you have running per instance of cgminer?

EDIT: I've gotten 8 boards running fine in 2 instances of cgminer (any more than 4 per instance crashes it for some reason???) but I can't seem to get my 9th to get detected.

as per Ebereons instructions, I've identified the boards usb's. I've uninstalled w/ and w/out deleting the drivers, and w/ and w/out uninstalling the com's ports associated w/ the board. Each time, the board re-installs to the same coms, which gives me

[2012-08-04 21:39:32] Started cgminer 2.6.2a
 [2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
 [2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2

every time. No clue where to begin figuring out this issue, any help would be greatly appreciated.

Thanks,

Steamboat

ASIC miners available for purchase

Those who serve best, profit most.
testconpastas2
Full Member
***
Offline Offline

Activity: 199



View Profile
August 05, 2012, 08:53:44 AM
 #1798


[2012-08-04 21:39:32] Started cgminer 2.6.2a
 [2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
 [2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2

Steamboat

I think your error is mine . I run one board in one cgminer . Could you check if after   error lines you posted ,do  show up other for a little time telling you something about user privilegesHuh

Try to unplug  usb from all your  boards( better in ubs hub) , then  power off PSU,  wait a couple of minutes (cold?¿? your board) and then power on PSU and first plug usb  of your problematic board.  windows should detect it.

Im almost sure in my case is a temp or usb hub  issue. because sometimes when board is frozen ( amber leds)   it start to work again but other  different fails suddenly.


NOTE: frozen for me is when you have your COMS ok and cgminer is not showing OFF state. but lots of LONGPOLL's and amber leds in the fpgas you have programmed.


Please tell me if it works for you.


Next week I'm going to buy some extra fans and i'll post if they fix my problems.



Bitmessage: BM-2DAetLWJBKWHZoPbNCgg5z8jwaPpDYWwd4
gpg key id:C6EF5CE3
toxicocean
Newbie
*
Offline Offline

Activity: 24


View Profile
August 05, 2012, 10:27:06 AM
 #1799

I'm trying to get my Cairnsmore1 run on a Raspberry Pi (cgminer), but I'm getting these type of errors:

 [2012-08-05 09:38:57] Icarus Detect: Test failed at /dev/usbdev1.2: get 12010002, should: 000187a2

I then tried on a Linux machine, and I get the same type:

 [2012-08-05 10:17:12] Icarus Detect: Test failed at /dev/ttyUSB0: get 00000000, should: 000187a2

on Windows it mines without problems. Anyone an idea on how to fix this?
norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
August 05, 2012, 11:41:34 AM
 #1800

I'm trying to get my Cairnsmore1 run on a Raspberry Pi (cgminer), but I'm getting these type of errors:

 [2012-08-05 09:38:57] Icarus Detect: Test failed at /dev/usbdev1.2: get 12010002, should: 000187a2

I then tried on a Linux machine, and I get the same type:

 [2012-08-05 10:17:12] Icarus Detect: Test failed at /dev/ttyUSB0: get 00000000, should: 000187a2

on Windows it mines without problems. Anyone an idea on how to fix this?


Have you got the latest ftdi drivers?

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
Pages: « 1 ... 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 [90] 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!