Author

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

sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
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 Smiley

I will give you a hint.  It's in the README.
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 Smiley
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?
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
newbie
Activity: 26
Merit: 0
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 Smiley

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!
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).
full member
Activity: 206
Merit: 100
Mostly Harmless...
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
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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 Smiley

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)
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/
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
full member
Activity: 206
Merit: 100
Mostly Harmless...
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.
legendary
Activity: 2450
Merit: 1002
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
newbie
Activity: 26
Merit: 0
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?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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
member
Activity: 109
Merit: 10
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:

  • installed Xcode via App Store
  • sudo port install pkgconfig curl +ssl
  • ./configure --enable-cpumining
  • sudo make install

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

EDIT: Btw: You must use -w 64 because of the OSX OpenCL bug. And, if you have two adapters, it seems that the weaker one is device 1, and the discrete is 0. E.g. in the mid-2009 MBP: Device 0 is the 9600M and device 1 is the 9400M.
legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
OS: Win7 64
Driver: 12.6
Card: XFX 6770
Cgminer: 2.5.0
It is still hanging after a while if NOT use --no-adl ... It can be ever fixed somehow?
Or can I do something to debug that?
Being a windows driver bug, there really is nothing I can do about it apart from suggesting trying a different driver version. I'm surprised you hit this bug so quickly after 2.5.0 though since most people find it hitting after a week of running.
Mayeb add some async watchdog that will detect stuck miner (lock over 1 minute), ignore ADL for a while using safe settings (fan on 99%) then try restart it?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
OS: Win7 64
Driver: 12.6
Card: XFX 6770
Cgminer: 2.5.0
It is still hanging after a while if NOT use --no-adl ... It can be ever fixed somehow?
Or can I do something to debug that?
Being a windows driver bug, there really is nothing I can do about it apart from suggesting trying a different driver version. I'm surprised you hit this bug so quickly after 2.5.0 though since most people find it hitting after a week of running.
legendary
Activity: 2450
Merit: 1002
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?
legendary
Activity: 1162
Merit: 1000
DiabloMiner author
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented.
GET THE FUCK OUT OF MY FORUM THREAD WITH YOUR FUD
Speaking the truth by calling out false claims is not FUD.
You now have the dubious honour of being the first ever person on this forum I've ignored.

Surprised it took so long.
Jump to: