kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 04, 2012, 12:05:09 PM |
|
... 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)
|
|
|
|
yohan (OP)
|
|
August 04, 2012, 04:47:43 PM |
|
@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 (OP)
|
|
August 04, 2012, 04:58:06 PM |
|
... 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
|
|
August 04, 2012, 05:31:53 PM |
|
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
|
|
|
|
yohan (OP)
|
|
August 04, 2012, 05:39:48 PM |
|
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
Activity: 919
Merit: 1000
|
|
August 04, 2012, 05:40:40 PM |
|
@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
|
|
August 04, 2012, 05:42:09 PM |
|
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
|
|
|
|
yohan (OP)
|
|
August 04, 2012, 05:44:10 PM |
|
@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 (OP)
|
|
August 04, 2012, 05:47:19 PM |
|
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
|
|
August 04, 2012, 05:51:52 PM |
|
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.
|
|
|
|
makomk
|
|
August 04, 2012, 06:35:16 PM |
|
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
|
|
August 04, 2012, 06:48:33 PM |
|
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. 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
Activity: 2128
Merit: 1073
|
|
August 04, 2012, 08:22:00 PM |
|
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.
|
|
|
|
ebereon
|
|
August 04, 2012, 09:26:36 PM |
|
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
|
|
August 04, 2012, 09:55:43 PM |
|
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
Activity: 2128
Merit: 1073
|
|
August 04, 2012, 10:21:14 PM |
|
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.
|
|
|
|
steamboat
|
|
August 05, 2012, 12:43:52 AM Last edit: August 05, 2012, 01:42:54 AM by steamboat |
|
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
|
|
|
|
testconpastas2
|
|
August 05, 2012, 08:53:44 AM |
|
[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 privilegesTry 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.
|
|
|
|
toxicocean
Newbie
Offline
Activity: 24
Merit: 0
|
|
August 05, 2012, 10:27:06 AM |
|
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
|
|
August 05, 2012, 11:41:34 AM |
|
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?
|
|
|
|
|