OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 541.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: af_newbie on July 09, 2012, 08:23:11 AM

Quote from: tucenaber on July 09, 2012, 04:32:02 AM

Decreasing the time from 112 to 60 results in an increased hashrate to ~275MH/s. About 25%. Better but no cigarr...

The Utility stays about the same. The total goes from about 69 to 70. But it was correct from the start. Theoretically my total hashrate is 4956MH/s, which should give a utility of 60 x 4.956e⁹/4295032833 = 69.23 shares/minute.

The hash rate is an estimate. If you put 80 as abort time, you'll get a better estimate.
If you put 90 or a 100, your hash rate estimate will be lower.

In my setup, the new icarus code does weird things (hash rates swing wildly), my utility rarely goes above 5/min.

With the old icarus code (some small mods by me, see my site) I get consistently 26.80/min out of my 5 icarus boards.
I stopped using the latest greatest icarus code as it is making me less money.

BTW, I'm using 6.5 secs to abandon previously submitted jobs.

Wrong.

The hash rate is 2 things:
1) If a nonce range returns a share, it is the exact number of hashes that happened and the exact amount of time it took.
2) If a nonce range did not return a share by the time the abort counter was reached, it is the calculated number of hashes that should have been done in the exact time from start to abort based on the Hs value (which is also correct for a standard Icarus Rev3)

--icarus-timing allows you to calculate/specify the Hs time and abort time for non-standard Icarus Rev3 (different bitstream) or non Icarus devices that use the Icarus bitstream.

Adjusting the abort time will not change the Hash rate unless there is something wrong either with the device or the computer's termios timing

If you are using 6.5 seconds to abandon jobs then you are aborting work too early.
However the reason you have to do that may be because you are using windows and the termios timing may not be accurate.
Some time in the ... future ... I'm going to rewrite that code to not rely on the OS being accurate with timing
My linux xubuntu 11.04 is very accurate with the termios timing and never has issues of running past the full nonce time (and ending up idle)
Your code is also using that same termios timing and that is probably why you have to set it to such a low abort value when it really should be 11.2/11.3

A standard Icarus Rev3 hashes at ~380Mh/s
That equates to a U: of 5.31 x 5 = 26.54
A U: of 26.80 over 5 devices is 383.6MH/s
Utility is random, it takes a few days to START to converge on it's expected value.
Also, you cannot get it to hash at max MH/s constantly, LP's will reduce that by about 0.6MH/s

tucenaber

sr. member

Activity: 337

Merit: 252

Quote

Try --icarus-timing 2.6316=60
and see how that goes

Decreasing the time from 112 to 60 results in an increased hashrate to ~275MH/s. About 25%. Better but no cigarr...

The Utility stays about the same. The total goes from about 69 to 70. But it was correct from the start. Theoretically my total hashrate is 4956MH/s, which should give a utility of 60 x 4.956e⁹/4295032833 = 69.23 shares/minute.

Quote

What version of cgminer? What OS?

don't have java installed, but I can use netcat:

Code:

$ echo -n version|netcat localhost 4028|tr '|' '\n'
STATUS=S,When=1341825320,Code=22,Msg=CGMiner versions,Description=cgminer 2.5.0
VERSION,CGMiner=2.5.0,API=1.14

$ echo -n config|netcat localhost 4028|tr '|' '\n'
STATUS=S,When=1341825320,Code=33,Msg=CGMiner config,Description=cgminer 2.5.0
CONFIG,GPU Count=4,PGA Count=10,CPU Count=0,Pool Count=3,ADL=Y,ADL in use=Y,Strategy=Failover,Log Interval=5,Device Code=GPU ICA ,OS=Linux

$ echo -n stats|netcat localhost 4028|tr '|' '\n'|grep -a 'ID=ICA'
STATS=4,ID=ICA0,Elapsed=4058,Calls=1149,Wait=0.007328,Max=0.000117,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=5,ID=ICA1,Elapsed=4058,Calls=1155,Wait=0.008084,Max=0.000199,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=6,ID=ICA2,Elapsed=4058,Calls=1140,Wait=0.007985,Max=0.000643,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=7,ID=ICA3,Elapsed=4058,Calls=1157,Wait=0.007119,Max=0.000081,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=8,ID=ICA4,Elapsed=4058,Calls=1149,Wait=0.006996,Max=0.000149,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=9,ID=ICA5,Elapsed=4058,Calls=1124,Wait=0.007068,Max=0.000069,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=10,ID=ICA6,Elapsed=4058,Calls=1160,Wait=0.015211,Max=0.000337,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=11,ID=ICA7,Elapsed=4058,Calls=1147,Wait=0.007531,Max=0.000140,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=12,ID=ICA8,Elapsed=4058,Calls=1145,Wait=0.009075,Max=0.000069,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=13,ID=ICA9,Elapsed=4058,Calls=1161,Wait=0.007518,Max=0.000137,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false

$ echo -n devs|netcat localhost 4028|tr '|' '\n'|grep -a '^PGA'
PGA=0,Name=ICA,ID=0,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=271.60,MHS 5s=315.51,Accepted=369,Rejected=5,Hardware Errors=0,Utility=5.46,Last Share Pool=0,Last Share Time=1341825314,Total MH=1102250.2917,Frequency=0.00
PGA=1,Name=ICA,ID=1,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=269.40,MHS 5s=320.07,Accepted=367,Rejected=5,Hardware Errors=0,Utility=5.43,Last Share Pool=0,Last Share Time=1341825292,Total MH=1093339.7307,Frequency=0.00
PGA=2,Name=ICA,ID=2,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=272.01,MHS 5s=319.05,Accepted=348,Rejected=3,Hardware Errors=0,Utility=5.14,Last Share Pool=0,Last Share Time=1341825301,Total MH=1103934.3132,Frequency=0.00
PGA=3,Name=ICA,ID=3,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=271.99,MHS 5s=302.06,Accepted=378,Rejected=5,Hardware Errors=0,Utility=5.59,Last Share Pool=0,Last Share Time=1341825319,Total MH=1103838.6265,Frequency=0.00
PGA=4,Name=ICA,ID=4,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=271.59,MHS 5s=333.23,Accepted=370,Rejected=2,Hardware Errors=0,Utility=5.47,Last Share Pool=0,Last Share Time=1341825303,Total MH=1102219.0277,Frequency=0.00
PGA=5,Name=ICA,ID=5,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=270.25,MHS 5s=297.82,Accepted=336,Rejected=5,Hardware Errors=0,Utility=4.97,Last Share Pool=0,Last Share Time=1341825318,Total MH=1096755.9705,Frequency=0.00
PGA=6,Name=ICA,ID=6,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=272.78,MHS 5s=293.71,Accepted=370,Rejected=6,Hardware Errors=0,Utility=5.47,Last Share Pool=0,Last Share Time=1341825320,Total MH=1107036.1526,Frequency=0.00
PGA=7,Name=ICA,ID=7,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=269.22,MHS 5s=336.00,Accepted=379,Rejected=2,Hardware Errors=0,Utility=5.60,Last Share Pool=0,Last Share Time=1341825319,Total MH=1092576.1434,Frequency=0.00
PGA=8,Name=ICA,ID=8,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=273.70,MHS 5s=303.55,Accepted=367,Rejected=0,Hardware Errors=0,Utility=5.43,Last Share Pool=0,Last Share Time=1341825300,Total MH=1110775.4866,Frequency=0.00
PGA=9,Name=ICA,ID=9,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=274.27,MHS 5s=324.41,Accepted=370,Rejected=8,Hardware Errors=0,Utility=5.47,Last Share Pool=0,Last Share Time=1341825313,Total MH=1113103.2650,Frequency=0.00

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: tucenaber on July 08, 2012, 03:15:12 PM

I might add that running cgminer with --benchmark gives the expected 380MH/s result for my Icarus boards. Switching back to normal mode gives me 220MH/s :-(

Could it be an issue with p2pool-Icarus combo?

What version of cgminer? What OS?
java API version
java API config

The numbers to expect on the cgminer screen if everything is working fine are something like:
379.6/376.4Mh/s (give or take a MH/s

)

If you are using the current version of cgminer it will also report the timing information in
java API stats

Icarus are pretty static in their performance under normal conditions, so 'short' is really only needed for the other non-Icarus boards where the default settings may be different.
'long' would only be useful on an unstable device

Having the wrong value for Hs (default 2.6316ns) will increase the displayed hash rate if the number is too low (but not affect anything else)
If the number is way too high the Icarus will idle at the end of each nonce range that doesn't find a share - so it will lower the hash rate.

If your device is unstable, then yes it may not get the expected results - I don't have a faulty Icarus to see what happens in that case

Try --icarus-timing 2.6316=60
and see how that goes

Also if you don't already, make sure at least --api-allow is on so you can use
java API stats
to see what the timing is doing

tucenaber

sr. member

Activity: 337

Merit: 252

I might add that running cgminer with --benchmark gives the expected 380MH/s result for my Icarus boards. Switching back to normal mode gives me 220MH/s :-(

Could it be an issue with p2pool-Icarus combo?

tucenaber

sr. member

Activity: 337

Merit: 252

Quote from: TheHarbinger on July 08, 2012, 10:38:18 AM

I thought it was supposed to be timing=short?

According to the FPGA-README, "short" makes it measure for a while and then stop whereas "long" measures continuosly. Anway, I have tried both and the result is the same. It comes up with a number close to the theoretical 1/380e6=2.631579e9, but the hashrate is still wrong.

TheHarbinger

sr. member

Activity: 378

Merit: 250

Why is it so damn hot in here?

Quote from: tucenaber on July 08, 2012, 08:57:34 AM

cgminer gives the wrong hashrate for my Incarus rev3 boards and I can't understand what I'm doing wrong. According to FPGA-README I shouldn't have to use the icarus-timing option but I have tried different settings anyway, but to no avail. My searches have also come up with nothing, so if anybody can help I would appreciate it.

The hashrate is estimated by cgminer as ~220MH/s instead of the expected 380MH/s even with icarus-timing=long. The "shares mer minute" number (U) seems correct though (around 5.2) and the pool is giving reasonable numbers so there is not a huge issue but if possible I would like to configue cgminer correctly.

Does anybody experience the same thing or perhaps have a solution?

I thought it was supposed to be timing=short?

TheHarbinger

sr. member

Activity: 378

Merit: 250

Why is it so damn hot in here?

Quote from: UnderGod on July 08, 2012, 10:23:42 AM

Hi there, been using cgminer on Windows 7 for quite a bit now, decided to go back to linux, not without problems offcourse :]
I have a 6990, with windows cgminer sees gpu0 and gpu1 and happily mines on both.
In linux cgminer only sees gpu0.
cgminer -n shows only one gpu.
Does anyone have an idea where I should start to look why he doesn't want to see the second gpu?
Thanks

I will give you a hint. It's in the README.

UnderGod

full member

Activity: 163

Merit: 100

Hi there, been using cgminer on Windows 7 for quite a bit now, decided to go back to linux, not without problems offcourse :]
I have a 6990, with windows cgminer sees gpu0 and gpu1 and happily mines on both.
In linux cgminer only sees gpu0.
cgminer -n shows only one gpu.
Does anyone have an idea where I should start to look why he doesn't want to see the second gpu?
Thanks

tucenaber

sr. member

Activity: 337

Merit: 252

cgminer gives the wrong hashrate for my Incarus rev3 boards and I can't understand what I'm doing wrong. According to FPGA-README I shouldn't have to use the icarus-timing option but I have tried different settings anyway, but to no avail. My searches have also come up with nothing, so if anybody can help I would appreciate it.

The hashrate is estimated by cgminer as ~220MH/s instead of the expected 380MH/s even with icarus-timing=long. The "shares mer minute" number (U) seems correct though (around 5.2) and the pool is giving reasonable numbers so there is not a huge issue but if possible I would like to configue cgminer correctly.

Does anybody experience the same thing or perhaps have a solution?

BlackPrapor

hero member

Activity: 628

Merit: 504

In win7x64 after updating to 2.5.0 cgminer would hang up right after start. I'm using catalyst 12.5 and 6950 video cards. Currently went back to 2.4.1

SiegeBreaker

newbie

Activity: 26

Merit: 0

Quote from: kano on July 07, 2012, 09:18:09 PM

Quote from: SiegeBreaker on July 07, 2012, 02:22:57 PM

Quote from: kano on July 02, 2012, 08:25:58 AM

Quote from: Bitbird on July 02, 2012, 01:18:13 AM

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

Quote

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

Kano, sent some bitcs your way for saving me an OS upgrade. Seriously, why is it required to upgrade your OS for a new version of software? Shouldn't there be an easy way to just get the new GLIBC installed on an old version?

Thanks for the BTC

I keep making 11.04 binaries since my GPU/BFL rig is 11.04 based on my setup script in cgminer and I don't have any 7xxx GPUs (yet)

The GLIBC version ties in with the kernel, so updating GLIBC has a habit of hitting a brick wall at some stage after kernel upgrades stop on any linux distro version.

I'd certainly not want to try building a later GLIBC from scratch coz I'd expect there to be issues that either:
1) I'd not know about and thus be using a potentially buggy GLIBC
(I'd have to spend a lot of effort looking at all the changes in GLIBC and why they changed)
or
2) would show up as failing to build it on the 11.04 kernel (2.6.38-8) and thus most likely be lots of effort to resolve

It's all pretty much: lots of effort for no real gain for me, and building on 11.04 is simple enough for me with an 11.04 dev VM also.
(interesting for me also is that the binaries I build on 11.04 work on my desktop fc16 too where I have my 2xIcarus)

Thanks for the explanation, Kano. I figured it was coupled to the OS fairly tightly or else I would have been able to find some how-to googling, your explanation is a lot better than anything I found online.

cklovias, I understand that at some point you have to move on (although I don't know specifically what new feature was required in the newer version, I know you are smart enough to not just rebase to the new version for fun). My gripe is with the linux setup, not with your excellent software.

Thanks to both of you for all your work!

Inaba

legendary

Activity: 1260

Merit: 1000

So there seems to be some bugs in cgminer (and bfgminer) in relation to ridiculous number of units. Here's basically the setup:

With more than ~30-32 units, if you try to launch cgminer from the command line without a .conf file and without -q, cgminer will hang. Adding -q and controlling things from the API and having a .conf file with your pools in it seems to bypass the issue and will mine with a lot of units, far in excess of 32 units. I can reproduce this repeatedly... but if I do, it tends to kill the BFL units which require a power cycle.. so I'm thinking i'ts something to do with the BFL initialization routines, possibly.

This is on Linux, I did not test Windows. Latest git as of this writing (2.5.0).

Phraust

full member

Activity: 206

Merit: 100

Mostly Harmless...

Quote from: Phraust on July 07, 2012, 04:15:42 PM

Quote from: kano on July 07, 2012, 09:46:37 AM

Quote from: TechCF on July 07, 2012, 07:49:12 AM

Just built this on OSX 10.7.4, but I have trouble getting --enable-bitforce to work, and beeing a newbie on these kind of things I would like if anybody can help. If I can be of any help, I built it with these steps:
...
The error I get when trying with --enable-bitforce is:

Code:

  CC       cgminer-fpgautils.o
fpgautils.c: In function ‘serial_open’:
fpgautils.c:214: error: ‘CBAUD’ undeclared (first use in this function)
fpgautils.c:214: error: (Each undeclared identifier is reported only once
fpgautils.c:214: error: for each function it appears in.)
make[1]: *** [cgminer-fpgautils.o] Error 1
make: *** [install-recursive] Error 1

...

CBAUD is part of termios.h - which is included by termio.h - the same place B115200 comes from.
The actual definition of both of them is in bits/termios.h

Find where B115200 is defined and CBAUD should be in the same place:
grep B115200 /usr/include/*
grep B115200 /usr/include/*/*
grep CBAUD /usr/include/*
grep CBAUD /usr/include/*/*

If it's missing then all I can guess is that OSX has done something very strange ...

The addition of CBAUD was to fix an old issue that setting the serial BAUD rate should only change the bits that represent the BAUD, not zero everything else.

I ran across this same issue, and tried to do some research into it. The best I could find was:

http://earthworm.isti.com/trac/earthworm/ticket/151

This is because CBAUD is a Linux extension to the POSIX Terminal I/O definitions. The fix is to use the standard POSIX Terminal I/O functions to set the serial input and output BAUD rates (e.g., if CBAUD is undefined)...

Dunno how to change that in the fpgautils.c file, though that looks to be the root cause since CBAUD is showing up as undeclared.

After some bungling around with fpgautils.c, I managed to get things working. Where CBAUD is undefined in OSX (why? dunno...), it throws the error around line 214:

Quote

      my_termios.c_cflag &= ~CBAUD;
      my_termios.c_cflag |= B115200;
      break;

So using the link I posted earlier http://earthworm.isti.com/trac/earthworm/ticket/151 as a template, I changed it to this:

Quote

   #ifdef CBAUD
       my_termios.c_cflag &= ~CBAUD; // baudrate mask
         my_termios.c_cflag |= B115200; // baudrate
   #else
       cfsetispeed( &my_termios, B115200 );
       cfsetospeed( &my_termios, B115200 );
   #endif
      break;

This allowed it to compile in OSX, and I'm currently testing it out now. Any help regarding the change I made would be awesome, as it LOOKS like it worked (it's mining right now), but I have no idea if this breaks anything else.

Oh, I have uploaded my updated version here: http://bitcoin.phraust.com/fpgautils.c

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: SiegeBreaker on July 07, 2012, 02:22:57 PM

Quote from: kano on July 02, 2012, 08:25:58 AM

Quote from: Bitbird on July 02, 2012, 01:18:13 AM

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

Quote

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

Kano, sent some bitcs your way for saving me an OS upgrade. Seriously, why is it required to upgrade your OS for a new version of software? Shouldn't there be an easy way to just get the new GLIBC installed on an old version?

Thanks for the BTC

I keep making 11.04 binaries since my GPU/BFL rig is 11.04 based on my setup script in cgminer and I don't have any 7xxx GPUs (yet)

The GLIBC version ties in with the kernel, so updating GLIBC has a habit of hitting a brick wall at some stage after kernel upgrades stop on any linux distro version.

I'd certainly not want to try building a later GLIBC from scratch coz I'd expect there to be issues that either:
1) I'd not know about and thus be using a potentially buggy GLIBC
(I'd have to spend a lot of effort looking at all the changes in GLIBC and why they changed)
or
2) would show up as failing to build it on the 11.04 kernel (2.6.38-8) and thus most likely be lots of effort to resolve

It's all pretty much: lots of effort for no real gain for me, and building on 11.04 is simple enough for me with an 11.04 dev VM also.
(interesting for me also is that the binaries I build on 11.04 work on my desktop fc16 too where I have my 2xIcarus)

Krak

hero member

Activity: 591

Merit: 500

I've been using 2.5 for a while now and it seems like dynamic intensity is broken again. It'll constantly go anywhere from 1 to 14 and when it spikes up to 12-14, the desktop becomes completely unresponsive for several seconds. This also has a negative affect on my second GPU with a static intensity because its hashrate drops by about 50% when the desktop goes unresponsive.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: SiegeBreaker on July 07, 2012, 02:22:57 PM

Quote from: kano on July 02, 2012, 08:25:58 AM

Quote from: Bitbird on July 02, 2012, 01:18:13 AM

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

Quote

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

Kano, sent some bitcs your way for saving me an OS upgrade. Seriously, why is it required to upgrade your OS for a new version of software? Shouldn't there be an easy way to just get the new GLIBC installed on an old version?

https://bitcointalksearch.org/topic/m.983090

Phraust

full member

Activity: 206

Merit: 100

Mostly Harmless...

Quote from: kano on July 07, 2012, 09:46:37 AM

Quote from: TechCF on July 07, 2012, 07:49:12 AM

Just built this on OSX 10.7.4, but I have trouble getting --enable-bitforce to work, and beeing a newbie on these kind of things I would like if anybody can help. If I can be of any help, I built it with these steps:
...
The error I get when trying with --enable-bitforce is:

Code:

  CC       cgminer-fpgautils.o
fpgautils.c: In function ‘serial_open’:
fpgautils.c:214: error: ‘CBAUD’ undeclared (first use in this function)
fpgautils.c:214: error: (Each undeclared identifier is reported only once
fpgautils.c:214: error: for each function it appears in.)
make[1]: *** [cgminer-fpgautils.o] Error 1
make: *** [install-recursive] Error 1

...

CBAUD is part of termios.h - which is included by termio.h - the same place B115200 comes from.
The actual definition of both of them is in bits/termios.h

Find where B115200 is defined and CBAUD should be in the same place:
grep B115200 /usr/include/*
grep B115200 /usr/include/*/*
grep CBAUD /usr/include/*
grep CBAUD /usr/include/*/*

If it's missing then all I can guess is that OSX has done something very strange ...

The addition of CBAUD was to fix an old issue that setting the serial BAUD rate should only change the bits that represent the BAUD, not zero everything else.

I ran across this same issue, and tried to do some research into it. The best I could find was:

http://earthworm.isti.com/trac/earthworm/ticket/151

This is because CBAUD is a Linux extension to the POSIX Terminal I/O definitions. The fix is to use the standard POSIX Terminal I/O functions to set the serial input and output BAUD rates (e.g., if CBAUD is undefined)...

Dunno how to change that in the fpgautils.c file, though that looks to be the root cause since CBAUD is showing up as undeclared.

GenTarkin

legendary

Activity: 2450

Merit: 1002

Quote from: kano on July 07, 2012, 09:29:17 AM

Quote from: GenTarkin on July 07, 2012, 02:16:17 AM

I couldnt easily find this anywhere, but whats the proper json format for the new "restricted access" feature? vs full access for remote API accessing of cgminer?

I'm not really sure exactly what you mean by your question - but the API-README contains all the info about the API ...

Edit: If you mean the command line parameters then they are in README for the basic command definitions and more details in API-README

figured it out, it was the api-groups addition =)ty for pointing me to api-readme

SiegeBreaker

newbie

Activity: 26

Merit: 0

Quote from: kano on July 02, 2012, 08:25:58 AM

Quote from: Bitbird on July 02, 2012, 01:18:13 AM

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

Quote

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

Kano, sent some bitcs your way for saving me an OS upgrade. Seriously, why is it required to upgrade your OS for a new version of software? Shouldn't there be an easy way to just get the new GLIBC installed on an old version?

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: TechCF on July 07, 2012, 07:49:12 AM

Just built this on OSX 10.7.4, but I have trouble getting --enable-bitforce to work, and beeing a newbie on these kind of things I would like if anybody can help. If I can be of any help, I built it with these steps:
...
The error I get when trying with --enable-bitforce is:

Code:

  CC       cgminer-fpgautils.o
fpgautils.c: In function ‘serial_open’:
fpgautils.c:214: error: ‘CBAUD’ undeclared (first use in this function)
fpgautils.c:214: error: (Each undeclared identifier is reported only once
fpgautils.c:214: error: for each function it appears in.)
make[1]: *** [cgminer-fpgautils.o] Error 1
make: *** [install-recursive] Error 1

...

CBAUD is part of termios.h - which is included by termio.h - the same place B115200 comes from.
The actual definition of both of them is in bits/termios.h

Find where B115200 is defined and CBAUD should be in the same place:
grep B115200 /usr/include/*
grep B115200 /usr/include/*/*
grep CBAUD /usr/include/*
grep CBAUD /usr/include/*/*

If it's missing then all I can guess is that OSX has done something very strange ...

The addition of CBAUD was to fix an old issue that setting the serial BAUD rate should only change the bits that represent the BAUD, not zero everything else.

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 541. (Read 5806088 times)