FPGA development board "Icarus" - DisContinued/ important announcement - page 9.

chungenhung

legendary

Activity: 1134

Merit: 1005

Quote from: Turbor on April 03, 2012, 05:41:40 AM

I compiled Windows binaries from 2.3.2 sources, with --enable-icarus, I'm getting the following
error:

[2012-04-03 00:21:01] Started cgminer 2.3.2
[2012-04-03 00:21:09] Icarus Read: No data in 8 seconds
[2012-04-03 00:21:10] Icarus Detect: Test failed at com3: get 00000000, should: 063c5e0

I've tried all 5 cards, one at the time. I get the above error for all 5 cards.

Has anyone got cgminer to work with icarus cards on Windows 7?

I'm using 1.5.2 prolific installer for the usb-com driver.
(Same result with 1.5.0 installer)

Tried different USB cables, no luck. Power supply provides 12.2V open.

It looks like cgminer is not communicating with the card. Same error as when the power is off.

I use my Icarus with "enable-icarus" : true, and "scan-serial" : "COMX", in the conf file. Works well. I had to pull the usb cable one time because cgminer and mpbm did not recognize the board. Restarting the board did not help. Perhaps you can try with scan serial option or get cons ready to use version.

Do you have all the other files from ngzhangs git ?

Tubor, can you post your cgminer config file? I am having trouble running cgminer 2.3.2 on Win7 as well.
When I start, it says "OpenCL.dll" is missing. This is a Icarus only machine. NO GPUS. Do I still need the OpenCL?

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Quote from: ?? on ??

I compiled Windows binaries from 2.3.2 sources, with --enable-icarus, I'm getting the following
error:

[2012-04-03 00:21:01] Started cgminer 2.3.2
[2012-04-03 00:21:09] Icarus Read: No data in 8 seconds
[2012-04-03 00:21:10] Icarus Detect: Test failed at com3: get 00000000, should: 063c5e0

I've tried all 5 cards, one at the time. I get the above error for all 5 cards.

Has anyone got cgminer to work with icarus cards on Windows 7?

I'm using 1.5.2 prolific installer for the usb-com driver.
(Same result with 1.5.0 installer)

Tried different USB cables, no luck. Power supply provides 12.2V open.

It looks like cgminer is not communicating with the card. Same error as when the power is off.

I use my Icarus with "enable-icarus" : true, and "scan-serial" : "COMX", in the conf file. Works well. I had to pull the usb cable one time because cgminer and mpbm did not recognize the board. Restarting the board did not help. Perhaps you can try with scan serial option or get cons ready to use version.

Do you have all the other files from ngzhangs git ?

tgmarks

donator

Activity: 490

Merit: 500

Just jumping in to hear about lancelot...

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: twmz on March 30, 2012, 07:33:04 PM

Quote from: ngzhang on March 30, 2012, 01:33:33 PM

Quote from: twmz on March 30, 2012, 07:52:42 AM

I'm getting some odd behavior from one of my icarus boards. The symptom seems to be that every time it finds a share, the miner sees it as two shares that are the same. Of course the second one gets rejected as a duplicate. Here is example from MPBM:

this behavior usually happen when set the FPGA ID to the same value. this variable is set by S2-2 and S3-2 switches.
please notice if they set to a same value, or cause by something like switch internal poorconnection.

a solution is change the S2-2 and S3-2 value to opposite.

Well, I looked at the board and they looked correct. However, just to be sure, I flipped both dip switches and then flipped them back. Now it is working again. So maybe it was just not entirely flipped.

ngzhang's answer and you being able to fix it is really good to know!
(for possible future reference

)

twmz

hero member

Activity: 737

Merit: 500

Quote from: ngzhang on March 30, 2012, 01:33:33 PM

Quote from: twmz on March 30, 2012, 07:52:42 AM

I'm getting some odd behavior from one of my icarus boards. The symptom seems to be that every time it finds a share, the miner sees it as two shares that are the same. Of course the second one gets rejected as a duplicate. Here is example from MPBM:

this behavior usually happen when set the FPGA ID to the same value. this variable is set by S2-2 and S3-2 switches.
please notice if they set to a same value, or cause by something like switch internal poorconnection.

a solution is change the S2-2 and S3-2 value to opposite.

Well, I looked at the board and they looked correct. However, just to be sure, I flipped both dip switches and then flipped them back. Now it is working again. So maybe it was just not entirely flipped.

ngzhang

hero member

Activity: 592

Merit: 501

We will stand and fight.

allinvain

legendary

Activity: 3080

Merit: 1080

Quote from: chungenhung on March 28, 2012, 04:28:31 PM

does anyone sell power cords to connect from ATX power supply to Icarus?
Or if you want to make it and sell it. PM me.

https://bitcointalksearch.org/topic/wts-atx-psu-to-25-or-2155mm-12v-coaxial-plug-power-cables-new-product-74397

twmz

hero member

Activity: 737

Merit: 500

Quote from: TheSeven on March 30, 2012, 09:09:00 AM

Quote from: twmz on March 30, 2012, 07:52:42 AM

I'm getting some odd behavior from one of my icarus boards. The symptom seems to be that every time it finds a share, the miner sees it as two shares that are the same. Of course the second one gets rejected as a duplicate. Here is example from MPBM:

Can you compare the dip switch settings of a working board with the misbehaving one? If they are different between boards (especially if both FPGAs on the misbehaving board set to the same value) that could explain this issue.

Ah, good idea. I'll check when I get home. Note, this started happening at about the same time that I physically reorganized my rigs and moved these boards to a different location, so maybe I bumped something.

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

twmz

hero member

Activity: 737

Merit: 500

I'm getting some odd behavior from one of my icarus boards. The symptom seems to be that every time it finds a share, the miner sees it as two shares that are the same. Of course the second one gets rejected as a duplicate. Here is example from MPBM:

Code:

2012-03-30 06:30:39.812854 [350]: Icarus 0 found share: BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a0000087200000000f8e7cdd443fb0bc6d2d933fddd7dfd8f08e21a12ef6d45751ea616c54dd5327a4f7598b41a0a507e:96729b3a
2012-03-30 06:30:39.813580 [350]: Icarus 0 found share: BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a0000087200000000f8e7cdd443fb0bc6d2d933fddd7dfd8f08e21a12ef6d45751ea616c54dd5327a4f7598b41a0a507e:96729b3a
2012-03-30 06:30:39.853994 [400]: Mining BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a00000872000000007147b19ecba613c5b68fbddc0777343cfc65f3dae2a4f28fcd058d18fd0c06034f7598b91a0a507e on Icarus 0
2012-03-30 06:30:40.198653 [500]: BTCProxy: Got 1 jobs
2012-03-30 06:30:40.202807 [250]: BTCProxy accepted share 96729b3a (difficulty 1.34014)
2012-03-30 06:30:40.319497 [200]: BTCProxy rejected share 96729b3a (difficulty 1.34014): Unknown reason
2012-03-30 06:30:42.819884 [350]: Icarus 0 found share: BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a00000872000000007147b19ecba613c5b68fbddc0777343cfc65f3dae2a4f28fcd058d18fd0c06034f7598b91a0a507e:c08f8021
2012-03-30 06:30:42.820828 [350]: Icarus 0 found share: BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a00000872000000007147b19ecba613c5b68fbddc0777343cfc65f3dae2a4f28fcd058d18fd0c06034f7598b91a0a507e:c08f8021
2012-03-30 06:30:42.823446 [400]: Mining BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a0000087200000000afe089209862ec0ac0038b7e62fda7528d9c7d44f9aeb8b50502539f06248ddc4f7598c01a0a507e on Icarus 0
2012-03-30 06:30:42.921271 [500]: BTCProxy: Got 1 jobs
2012-03-30 06:30:42.938696 [250]: BTCProxy accepted share c08f8021 (difficulty 1.18879)
2012-03-30 06:30:43.057058 [200]: BTCProxy rejected share c08f8021 (difficulty 1.18879): Unknown reason

I tried this with cgminer also and it doesn't list any errors about duplicates (perhaps because it is quietly detecting the duplicates and ignoring them?). However, that board has a Utility stat of only 2.5 instead of being close to 5.2. So perhaps it is still happening and the extra round trips are reducing the effective hashrate.

Note, this does not happen on my other icarus board. The other one is working normally. In fact the board that is currently acting up was working fine for a day or two before this started happening.

I thought it might be a heat problem, so I stopped it for an hour to let it cool completely down, but the problem persisted right away after rebooting my host computer and starting mining.

Anyone seen anything like this before?

chungenhung

legendary

Activity: 1134

Merit: 1005

does anyone sell power cords to connect from ATX power supply to Icarus?
Or if you want to make it and sell it. PM me.

xiangfu

full member

Activity: 120

Merit: 100

make sense.

Quote from: makomk on March 26, 2012, 08:41:14 AM

Quote from: nelisky on March 25, 2012, 01:01:58 PM

Because xiangfu tested and found no issues I'm pretty sure nothing's wrong with the code itself. It's probably my toolchain or something with the device, I just mentioned the code because without calling that function my openwrt cgminer has been running for 2 days now and as soon as it gets called, segfault.

I suspect from looking at the code that you might be running into an alignment issue. The code in regeneratehash assumes that it can take a pointer to an array of type "unsigned char", cast it to a pointer to uint32_t, and access the contents of the array as though it contained 32-bit integers. This works fine on normal x86 machines which have very lax alignment requirements, but ARM requires memory that's accessed in this way to be aligned on 4-byte boundaries in RAM and it probably won't be because the compiler wasn't told that the data needed to be accessed in this way. So cgminer is going to crash.

makomk

hero member

Activity: 686

Merit: 564

Quote from: nelisky on March 25, 2012, 01:01:58 PM

Because xiangfu tested and found no issues I'm pretty sure nothing's wrong with the code itself. It's probably my toolchain or something with the device, I just mentioned the code because without calling that function my openwrt cgminer has been running for 2 days now and as soon as it gets called, segfault.

I suspect from looking at the code that you might be running into an alignment issue. The code in regeneratehash assumes that it can take a pointer to an array of type "unsigned char", cast it to a pointer to uint32_t, and access the contents of the array as though it contained 32-bit integers. This works fine on normal x86 machines which have very lax alignment requirements, but ARM requires memory that's accessed in this way to be aligned on 4-byte boundaries in RAM and it probably won't be because the compiler wasn't told that the data needed to be accessed in this way. So cgminer is going to crash.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: nelisky on March 26, 2012, 04:32:57 AM

Quote from: kano on March 25, 2012, 03:10:47 PM

So ... no Accepted or Rejected shares for 2 days?
(That code is used to generate the actual share displayed, the "00000000.xxxxxxxx.xxxxxxxx" bit that is also used to determine if you generated a block)

I'm not explaining myself too well. I disabled (i.e. commented out) the call to that function and everything works great. The block gerenation detection is only there for logging purposes and doesn't prevent normal functioning.

Yeah I know - I wrote and added it ...

OK you changed the code to not display that - well that's different Tongue

Either way, if there is a problem yes I do want to know, it's just that that function is called every time a share is generated (Accepted or Rejected) so I was wondering why it wasn't being called for 2 days

(as you have answered)

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: kano on March 25, 2012, 03:10:47 PM

So ... no Accepted or Rejected shares for 2 days?
(That code is used to generate the actual share displayed, the "00000000.xxxxxxxx.xxxxxxxx" bit that is also used to determine if you generated a block)

I'm not explaining myself too well. I disabled (i.e. commented out) the call to that function and everything works great. The block gerenation detection is only there for logging purposes and doesn't prevent normal functioning.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: nelisky on March 25, 2012, 01:01:58 PM

Quote from: kano on March 25, 2012, 11:31:50 AM

Quote from: nelisky on March 25, 2012, 09:24:10 AM

...
cgminer.c:regeneatehash(work)
...

I wrote it (including the difficulty generation, which is in fact my own original code)
What's wrong with it?
It is called every time cgminer shows you an Accepted or Rejected share.

Because xiangfu tested and found no issues I'm pretty sure nothing's wrong with the code itself. It's probably my toolchain or something with the device, I just mentioned the code because without calling that function my openwrt cgminer has been running for 2 days now and as soon as it gets called, segfault.

As I mentioned it gets called every time cgminer shows an Accepted or Rejected share ... in normal output.
So ... no Accepted or Rejected shares for 2 days?
(That code is used to generate the actual share displayed, the "00000000.xxxxxxxx.xxxxxxxx" bit that is also used to determine if you generated a block)

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: kano on March 25, 2012, 11:31:50 AM

Quote from: nelisky on March 25, 2012, 09:24:10 AM

...
cgminer.c:regeneatehash(work)
...

I wrote it (including the difficulty generation, which is in fact my own original code)
What's wrong with it?
It is called every time cgminer shows you an Accepted or Rejected share.

Because xiangfu tested and found no issues I'm pretty sure nothing's wrong with the code itself. It's probably my toolchain or something with the device, I just mentioned the code because without calling that function my openwrt cgminer has been running for 2 days now and as soon as it gets called, segfault.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: nelisky on March 25, 2012, 09:24:10 AM

...
cgminer.c:regeneatehash(work)
...

I wrote it (including the difficulty generation, which is in fact my own original code)
What's wrong with it?
It is called every time cgminer shows you an Accepted or Rejected share.

xiangfu

full member

Activity: 120

Merit: 100

Hi

I have tried:
cgminer -T --verbose ...
cgminer ....(direct use the ncurses)
all works fine. so far I didn't met segfault. (except direct un-plug the Icarus usb cable when cgminer running)

I have this patch apply when compile OpenWrt package:
http://projects.qi-hardware.com/index.php/p/openwrt-packages/source/tree/master/cgminer/patches/0001-add-MIPSED-to-icarus-for-BIG_ENDIAN.patch.patch

Quote from: nelisky on March 25, 2012, 09:24:10 AM

But doing some more debug I realized the function that triggers the segfault (in an unrelated place, so I'm guessing memory mismanage) is cgminer.c:regeneatehash(work). This is only called if doing verbose output and since you are passing -q to your cgminer you do net follow this code path. Could you give it a try without the -q, just to make sure it's not some weird thing with my setup? It segfaults as soon as a nonce is submitted to the pool.

Also, did you have to do anything to handle the device's endianess? It's weird, because I had to swab32 the data I receive which is consistent with BIG_ENDIAN, but defining __BIG_ENDIAN__ breaks everything hard. Could be an effect of the bi-endianess of mips, dunno.

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: xiangfu on March 24, 2012, 01:19:21 AM

I am using Linux 3.0.0-14-generic #23-Ubuntu SMP x86_64, Ubuntu 11.10, the latest build is using OpenWrt trunk 30834, you can find the .config file, VERSIONS here:
http://downloads.qi-hardware.com/people/xiangfu/icarus/openwrt-ar71xx-generic-trunk-30834/

BTW: the MAX_DEVICES under miner.h define is 32. so if you want support more then 32 devices. just change that one. I changed MAX_DEVICES to 64 and connect 41 Icarus. works just fine.

Thanks. I know about MAX_DEVICES and I don't yet have enough cards to make it worth changing

But doing some more debug I realized the function that triggers the segfault (in an unrelated place, so I'm guessing memory mismanage) is cgminer.c:regeneatehash(work). This is only called if doing verbose output and since you are passing -q to your cgminer you do net follow this code path. Could you give it a try without the -q, just to make sure it's not some weird thing with my setup? It segfaults as soon as a nonce is submitted to the pool.

Also, did you have to do anything to handle the device's endianess? It's weird, because I had to swab32 the data I receive which is consistent with BIG_ENDIAN, but defining __BIG_ENDIAN__ breaks everything hard. Could be an effect of the bi-endianess of mips, dunno.

Topic: FPGA development board "Icarus" - DisContinued/ important announcement - page 9. (Read 207279 times)