|
Doh, -lpthread, not -pthread is also an issue it seems?
Anyway, try pulling the git tree again please.
|
|
|
|
Sigh it gets tiring saying "If building from git, do ./autogen.sh first"
Sorry, my fault for not posting my entire build log.. As you'll see, I did do that first..  http://www.pastie.org/2501731Anything I missed? Oh wow, sorry. LDFLAGS..............: -L/usr/src/AMD-APP-SDK-v2.4-lnx32/lib/x86/ -g -pthread -ldl -lm It's there, so ...NFI |
|
|
|
It's fixed in git. You should have been able to see it in the last 2 git changelogs I posted.
Latest GIT, still unhappy on fedora14 without the "-ldl" switch: /usr/bin/ld: cgminer-adl.o: undefined reference to symbol 'dlopen@@GLIBC_2.1'
/usr/bin/ld: note: 'dlopen@@GLIBC_2.1' is defined in DSO /lib/libdl.so.2 so try adding it to the linker command line
/lib/libdl.so.2: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/usr/src/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/cgminer'
make: *** [all] Error 2
Sigh it gets tiring saying "If building from git, do ./autogen.sh first" |
|
|
|
|
It's fixed in git. You should have been able to see it in the last 2 git changelogs I posted.
|
|
|
|
|
Waiting on debugging output on dual core cards before I can get out the next release.
Meantime, git tree updated since 2.0:
Ideally we should like with -ldl for dlopen() dlclose().
ByteReverse is not used and the bswap opcode breaks big endian builds. Remove it.
Ignore whether the display is active or not since only display enabled devices work this way, and we skip over repeat entries anwyay.
Win32 does not use dlopen so link in -ldl only when not on win32 and display what ldflags are being passed on ./configure.
Only reset values on exiting if we've ever modified them.
Flag adl as active if any card is successfully activated.
Add a thermal cutoff option as well and set it to 95 degrees by default.
Change the fan speed by only 5% if it's over the target temperature but less than the hysteresis value to minimise overshoot down in temperature.
FAQ updates.
Add a --no-adl option to disable ADL monitoring and GPU settings.
More readme docs.
Only show longpoll received delayed message at verbose level.
Latest glibc appears to want linking against -lm as well for dlopen.
Allow temperatures greater than 100 degrees.
We should be passing a float for the remainder of the vddc values.
Implement accepting a range of engine speeds as well to allow a lower limit to be specified on the command line.
Allow per-device fan ranges to be set and use them in auto-fan mode.
Display which GPU has overheated in warning message.
Allow temperature targets to be set on a per-card basis on the command line.
Document the temperature command line changes.
Display fan range in autofan status.
Setting the hysteresis is unlikely to be useful on the fly and doesn't belong in the per-gpu submenu.
With many cards, the GPU summaries can be quite long so use a terse output line when showing them all.
Use a terser device status line to show fan RPM as well when available.
Define max gpudevices in one macro.
|
|
|
|
Let me spell it out then: I'm writing this in c and I FSCKING HATE WRITING PARSERS FOR FILES.
No worries... I hate file parsing as well... but i think i can implement something in C. Note I'm a windows developer. don't know Linux for sh!t. but i can put a function that will read in a text file, parse out the values and fill in a structure. I can easily do that this weekend. question, C only or C++? I happily take patches  C only please for consistency, and please try to stick to code style. (1TBS) http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS |
|
|
|
1) Dual GPU cards don't get adjusted/disabled correctly. For example, a 5970 will only disable the one GPU that has the temp sensor: GPU 3: [80.5 C] [DISABLED /78.5 Mh/s] [Q:2 A:11 R:1 HW:0 E:550% U:1.81/m]
GPU 4: [327.3/324.5 Mh/s] [Q:25 A:23 R:1 HW:0 E:92% U:3.78/m] Out of curiosity, what does AMDOverdriveCtrl -h return as a list of adapters on machines with dual core GPUs like this one? The output should be something like: INF: Nr. of Adapters: 16
INF: Adapter index: 0, active, ID:29775168, AMD Radeon HD 6900 Series
INF: Adapter index: 1, inact., ID:29775168, AMD Radeon HD 6900 Series
INF: Adapter index: 2, inact., ID:29775168, AMD Radeon HD 6900 Series
INF: Adapter index: 3, inact., ID:29775168, AMD Radeon HD 6900 Series
INF: Adapter index: 4, active, ID:31979904, AMD Radeon HD 6900 Series
INF: Adapter index: 5, inact., ID:31979904, AMD Radeon HD 6900 Series
INF: Adapter index: 6, inact., ID:31979904, AMD Radeon HD 6900 Series
INF: Adapter index: 7, inact., ID:31979904, AMD Radeon HD 6900 Series
INF: Adapter index: 8, active, ID:34184080, AMD Radeon HD 6900 Series
INF: Adapter index: 9, inact., ID:34184080, AMD Radeon HD 6900 Series
INF: Adapter index: 10, inact., ID:34184080, AMD Radeon HD 6900 Series
INF: Adapter index: 11, inact., ID:34184080, AMD Radeon HD 6900 Series
INF: Adapter index: 12, active, ID:36388256, AMD Radeon HD 6900 Series
INF: Adapter index: 13, inact., ID:36388256, AMD Radeon HD 6900 Series
INF: Adapter index: 14, inact., ID:36388256, AMD Radeon HD 6900 Series
INF: Adapter index: 15, inact., ID:36388256, AMD Radeon HD 6900 Series
|
|
|
|
|
Let me spell it out then: I'm writing this in c and I FSCKING HATE WRITING PARSERS FOR FILES.
|
|
|
|
I just tried to debug the problem I'm seeing, but attaching gdb to the cgminer process or starting cgminer from gdb froze the whole display (except the mouse pointer) after a short while and maxed out all 4 CPU cores. X went back to working normally after I logged in remotely and killed cgminer & gdb.
Indeed you cannot gdb with opencl code running. Everything hangs and you have to kill both the app and gdb. Makes debugging tons of fun at my end. Great, and here I was hoping I had missed something...  I'm running it with -T -D now to see whether debug output will shed any light on this, but it may be a while as this issue doesn't appear too soon. Did it actually crash this time? Sometimes they're literally milliseconds apart (longpoll and detection) and their messages just happen to get posted to the output in the wrong order (you'll note they're always on the same second). |
|
|
|
1) Dual GPU cards don't get adjusted/disabled correctly. For example, a 5970 will only disable the one GPU that has the temp sensor: GPU 3: [80.5 C] [DISABLED /78.5 Mh/s] [Q:2 A:11 R:1 HW:0 E:550% U:1.81/m]
GPU 4: [327.3/324.5 Mh/s] [Q:25 A:23 R:1 HW:0 E:92% U:3.78/m] 2) It'd be awesome if cgminer would record the current clocks on startup, and restore them on exit if the auto tuning changed them at all. 3) Pressing "G" when you have more than a couple of cards makes it impossible to read the output, because the window the output is displayed to is too small unless you have a HUGE screen. 4) I'd love a way to specify different temperature thresholds per GPU on the command line. If I have different model cards in there, they have different points where they're happy. 5770s get crashy above 90-95, where 5970 and 6990 cards idle near there at times. 5) My ideal dream would be a way of somehow saying "Any 5970 cards you see, set the temperature thresholds to X/Y, the voltage to Z, etc. Any 5770 cards, the temperature threshold is..." so that I don't have to look up which cards are in which system, just to pass that along to cgminer. 6) Temperatures >100C should be allowed, no matter how bad of an idea that sounds. We have some cards that go up to 105-107C without issue. 7) Specifying an overclock/underclock range that cgminer is allowed to adjust the clock in would be handy.  One step further, having it attempt to determine (maybe even saved into a local file) how high the clock was able to go without problems, and self-tuning the max clock rate while under the threshold temperature. 1: Not sure how to fix that since they don't return a different adapter id. I'll poke around some more. 2: It already does. 3: I'll consider trimming it somehow 4: Doable. 5: *cough* 6: Doable 7: Doable 8: *cough |
|
|
|
I just tried to debug the problem I'm seeing, but attaching gdb to the cgminer process or starting cgminer from gdb froze the whole display (except the mouse pointer) after a short while and maxed out all 4 CPU cores. X went back to working normally after I logged in remotely and killed cgminer & gdb.
Indeed you cannot gdb with opencl code running. Everything hangs and you have to kill both the app and gdb. Makes debugging tons of fun at my end. |
|
|
|
I'm also seeing something where the size of the queue on each GPU keeps growing over time, until there are hundreds of queued work per card. It may have something to do with cgminer reporting that the pool isn't providing work quickly enough (which I think is incorrect, the pushpoold it's talking to is a few feet away, on a totally unloaded box, that older versions of cgminer aren't complaining about), and after that the size of the queue keeps growing like crazy. This also seems to be causing some of the work that's being done to be so old it's being rejected by the time it actually gets a chance to run. Example from a box running for a few hours: [(5s):845.3 (avg):833.2 Mh/s] [Q:1336 A:1820 R:84 HW:0 E:136% U:10.99/m]
TQ: 8 ST: 8 SS: 0 DW: 11 NB: 18 LW: 2745 GF: 4 RF: 0 I: 9
Connected to
Block: 00000938f98c268dcf86a8cb4efa000a... Started: [18:28:21]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: [95.0 C] [367.3/373.5 Mh/s] [Q:673 A:810 R:43 HW:0 E:120% U:4.89/m]
GPU 1: [88.0 C] [187.7/186.9 Mh/s] [Q:251 A:400 R:11 HW:0 E:159% U:2.41/m]
GPU 2: [99.0 C] [106.1/100.8 Mh/s] [Q:137 A:235 R:9 HW:0 E:172% U:1.42/m]
GPU 3: [88.0 C] [179.8/172.1 Mh/s] [Q:225 A:375 R:21 HW:0 E:167% U:2.26/m] That's total queued to date, not current queued. |
|
|
|
|
About changing GPU settings: cgminer already reports the so-called "safe" range of whatever it is you are modifying when you ask to modify it on the fly. However, you can change settings to values outside this range. Despite this, the card can easily refuse to accept your changes, or worse, to accept your changes and then silently ignore them. So there is absolutely no way for me to know how far to/from where/to I can set things safely or otherwise, and there is nothing stopping you from at least trying to set them outside this range. I'm very conscious of these possible failures and that's why cgminer will report back the current values for you to examine how exactly the card has responded. Even within the reported range of accepted values by the card, it is very easy to crash just about any card, so I cannot use those values to determine what range to set. You have to provide something meaningful manually for cgminer to work with through experimentation.
|
|
|
|
Now if this $%&##^ 100% CPU bug can be squashed I'll be laughing. Bloody AMD *shakes fist*.
just out of curiosity... can't a Sleep(1); be added into each thread? this would fix the 100% cpu bug? 1ms shouldn't affect the mining at any signifigant level It's while the GPU code is executing that the CPU usage is high due to the driver consuming useless cycles. Sleeping when it comes back to the CPU will do nothing for that. |
|
|
|
And now, ladies and gentlemen, just for kicks a "screenshot" of cgminer in action on an 8-GPU rig. One word: awesomeness/ cgminer version 2.0.0 - Started: [2011-09-07 10:59:38]
--------------------------------------------------------------------------------
[ALL (5s):2955.4 (avg):2946.7 Mh/s] [Q:52 A:48 R:0 HW:0 E:92% U:47.01/m]
TQ: 24 ST: 24 SS: 0 DW: 0 NB: 1 LW: 115 GF: 0 RF: 0 I: 10
Connected to http://arsbitcoin.com:8344 with LP as user znort987.00
Block: 0000010b4d05033cb8ac32e1768d2b2d... Started: [10:59:23]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: [67.5 C] [372.2/373.5 Mh/s] [Q:4 A:6 R:0 HW:0 E:150% U:5.88/m]
GPU 1: [368.9/373.5 Mh/s] [Q:5 A:6 R:0 HW:0 E:120% U:5.88/m]
GPU 2: [70.5 C] [359.2/374.6 Mh/s] [Q:4 A:11 R:0 HW:0 E:275% U:10.77/m]
GPU 3: [383.2/369.2 Mh/s] [Q:2 A:4 R:0 HW:0 E:200% U:3.92/m]
GPU 4: [71.0 C] [361.0/375.7 Mh/s] [Q:18 A:4 R:0 HW:0 E:22% U:3.92/m]
GPU 5: [364.4/374.6 Mh/s] [Q:11 A:5 R:0 HW:0 E:45% U:4.90/m]
GPU 6: [40.5 C] [403.9/370.3 Mh/s] [Q:2 A:10 R:0 HW:0 E:500% U:9.79/m]
GPU 7: [387.5/371.4 Mh/s] [Q:3 A:4 R:0 HW:0 E:133% U:3.92/m]
--------------------------------------------------------------------------------
[2011-09-07 11:00:11] [GPU1 (5s):375.2 (avg):402.5 Mh/s] [Q:4 A:5 R:0 HW:0 E:125% U:9.89/m]
[2011-09-07 11:00:11] [GPU4 71.0 C (5s):397.5 (avg):406.9 Mh/s] [Q:4 A:3 R:0 HW:0 E:75% U:5.93/m]
[2011-09-07 11:00:12] [GPU7 (5s):350.2 (avg):409.1 Mh/s] [Q:3 A:1 R:0 HW:0 E:33% U:1.98/m]
[2011-09-07 11:00:12] Accepted 381dbc11 GPU 7 thread 23 pool 0
[2011-09-07 11:00:12] Accepted 53b68709 GPU 2 thread 2 pool 0
[2011-09-07 11:00:13] [GPU6 37.5 C (5s):365.4 (avg):418.0 Mh/s] [Q:2 A:2 R:0 HW:0 E:100% U:3.95/m]
[2011-09-07 11:00:13] [ALL (5s):2960.0 (avg):2947.1 Mh/s] [Q:28 A:29 R:0 HW:0 E:104% U:49.17/m]
[2011-09-07 11:00:14] Accepted 2568f80c GPU 6 thread 22 pool 0
[2011-09-07 11:00:15] [GPU2 69.5 C (5s):392.1 (avg):388.8 Mh/s] [Q:4 A:7 R:0 HW:0 E:175% U:11.87/m]
[2011-09-07 11:00:16] [GPU4 71.0 C (5s):313.7 (avg):400.2 Mh/s] [Q:4 A:3 R:0 HW:0 E:75% U:5.09/m]
[2011-09-07 11:00:16] [GPU3 (5s):349.2 (avg):400.2 Mh/s] [Q:2 A:1 R:0 HW:0 E:50% U:1.70/m]
[2011-09-07 11:00:16] [GPU5 (5s):362.7 (avg):398.3 Mh/s] [Q:2 A:4 R:0 HW:0 E:200% U:6.78/m]
[2011-09-07 11:00:16] [GPU1 (5s):380.8 (avg):403.9 Mh/s] [Q:4 A:5 R:0 HW:0 E:125% U:8.48/m]
[2011-09-07 11:00:17] [GPU0 66.5 C (5s):388.5 (avg):400.2 Mh/s] [Q:4 A:5 R:0 HW:0 E:125% U:8.48/m]
[2011-09-07 11:00:17] [GPU7 (5s):398.2 (avg):407.7 Mh/s] [Q:3 A:2 R:0 HW:0 E:67% U:3.39/m]
[2011-09-07 11:00:17] Accepted 580e101e GPU 3 thread 3 pool 0
[2011-09-07 11:00:18] [GPU6 38.5 C (5s):407.0 (avg):417.2 Mh/s] [Q:2 A:3 R:0 HW:0 E:150% U:5.09/m]
[2011-09-07 11:00:18] Accepted 6ba85346 GPU 0 thread 0 pool 0
[2011-09-07 11:00:19] [ALL (5s):2949.5 (avg):2933.6 Mh/s] [Q:28 A:32 R:0 HW:0 E:114% U:47.05/m]
[2011-09-07 11:00:19] Accepted be4a473a GPU 6 thread 14 pool 0
[2011-09-07 11:00:20] [GPU2 69.5 C (5s):410.6 (avg):383.1 Mh/s] [Q:4 A:7 R:0 HW:0 E:175% U:10.29/m]
[2011-09-07 11:00:21] [GPU3 (5s):370.4 (avg):394.7 Mh/s] [Q:2 A:2 R:0 HW:0 E:100% U:2.94/m]
[2011-09-07 11:00:22] [GPU4 71.0 C (5s):396.5 (avg):393.0 Mh/s] [Q:4 A:3 R:0 HW:0 E:75% U:4.41/m]
[2011-09-07 11:00:22] [GPU5 (5s):458.5 (avg):393.0 Mh/s] [Q:2 A:4 R:0 HW:0 E:200% U:5.88/m]
[2011-09-07 11:00:22] [GPU0 67.0 C (5s):406.6 (avg):397.9 Mh/s] [Q:4 A:6 R:0 HW:0 E:150% U:8.82/m]
[2011-09-07 11:00:22] Accepted 472f6139 GPU 3 thread 3 pool 0
[2011-09-07 11:00:22] [GPU1 (5s):439.6 (avg):394.7 Mh/s] [Q:4 A:5 R:0 HW:0 E:125% U:7.35/m]
[2011-09-07 11:00:23] [GPU7 (5s):427.1 (avg):404.5 Mh/s] [Q:3 A:2 R:0 HW:0 E:67% U:2.94/m]
[2011-09-07 11:00:23] [GPU6 39.0 C (5s):449.4 (avg):409.4 Mh/s] [Q:2 A:4 R:0 HW:0 E:200% U:5.88/m]
[2011-09-07 11:00:23] Accepted 7d62646e GPU 7 thread 23 pool 0
[2011-09-07 11:00:24] [ALL (5s):2950.8 (avg):2936.8 Mh/s] [Q:28 A:35 R:0 HW:0 E:125% U:45.79/m]
[2011-09-07 11:00:24] Accepted 89c5a35e GPU 1 thread 17 pool 0
[2011-09-07 11:00:25] [GPU2 70.0 C (5s):346.5 (avg):377.5 Mh/s] [Q:4 A:7 R:0 HW:0 E:175% U:10.29/m]
[2011-09-07 11:00:25] Accepted 667edd59 GPU 2 thread 10 pool 0
[2011-09-07 11:00:26] [GPU3 (5s):362.5 (avg):390.7 Mh/s] [Q:2 A:3 R:0 HW:0 E:150% U:3.92/m]
[2011-09-07 11:00:27] [GPU4 71.0 C (5s):352.2 (avg):395.1 Mh/s] [Q:4 A:3 R:0 HW:0 E:75% U:3.92/m]
[2011-09-07 11:00:27] [GPU5 (5s):381.7 (avg):396.5 Mh/s] [Q:2 A:4 R:0 HW:0 E:200% U:5.23/m]
[2011-09-07 11:00:27] [GPU0 67.0 C (5s):424.8 (avg):396.5 Mh/s] [Q:4 A:6 R:0 HW:0 E:150% U:7.85/m]
[2011-09-07 11:00:27] [GPU1 (5s):368.1 (avg):395.1 Mh/s] [Q:4 A:6 R:0 HW:0 E:150% U:7.85/m]
[2011-09-07 11:00:28] [GPU7 (5s):349.9 (avg):405.3 Mh/s] [Q:3 A:3 R:0 HW:0 E:100% U:3.92/m]
[2011-09-07 11:00:28] Accepted 6eeeb06e GPU 2 thread 10 pool 0
[2011-09-07 11:00:29] [GPU6 40.0 C (5s):397.5 (avg):411.2 Mh/s] [Q:2 A:4 R:0 HW:0 E:200% U:5.23/m]
[2011-09-07 11:00:29] [ALL (5s):2964.0 (avg):2952.8 Mh/s] [Q:28 A:38 R:0 HW:0 E:136% U:44.73/m]
[2011-09-07 11:00:30] Accepted 40b10b8c GPU 4 thread 4 pool 0
[2011-09-07 11:00:30] Accepted 44a1a972 GPU 6 thread 6 pool 0
[2011-09-07 11:00:30] Accepted 50e3c567 GPU 2 thread 18 pool 0
[2011-09-07 11:00:31] [GPU2 70.0 C (5s):381.8 (avg):380.5 Mh/s] [Q:4 A:10 R:0 HW:0 E:250% U:11.77/m]
[2011-09-07 11:00:31] Accepted bd57c182 GPU 6 thread 14 pool 0
[2011-09-07 11:00:32] [GPU3 (5s):390.8 (avg):388.4 Mh/s] [Q:2 A:3 R:0 HW:0 E:150% U:3.53/m]
[2011-09-07 11:00:32] [GPU4 71.5 C (5s):400.0 (avg):392.3 Mh/s] [Q:4 A:4 R:0 HW:0 E:100% U:4.71/m]
[2011-09-07 11:00:32] [GPU0 67.0 C (5s):429.6 (avg):393.6 Mh/s] [Q:4 A:6 R:0 HW:0 E:150% U:7.06/m]
[2011-09-07 11:00:32] [GPU5 (5s):417.4 (avg):396.3 Mh/s] [Q:2 A:4 R:0 HW:0 E:200% U:4.71/m]
[2011-09-07 11:00:33] [GPU1 (5s):394.6 (avg):397.6 Mh/s] [Q:4 A:6 R:0 HW:0 E:150% U:7.06/m]
[2011-09-07 11:00:33] Accepted 129233a6 GPU 6 thread 22 pool 0
[2011-09-07 11:00:34] [GPU7 (5s):395.6 (avg):404.2 Mh/s] [Q:3 A:3 R:0 HW:0 E:100% U:3.53/m]
[2011-09-07 11:00:34] [GPU6 40.0 C (5s):338.8 (avg):406.8 Mh/s] [Q:2 A:7 R:0 HW:0 E:350% U:8.24/m]
[2011-09-07 11:00:34] Accepted 73ef92ab GPU 6 thread 22 pool 0
[2011-09-07 11:00:34] [ALL (5s):2964.6 (avg):2954.4 Mh/s] [Q:28 A:44 R:0 HW:0 E:157% U:47.11/m]
[2011-09-07 11:00:35] Accepted 3b12cba1 GPU 6 thread 14 pool 0
...
Now that is mining pr0n.  |
|
|
|
|
The adl include files are only needed for compiling it. I have compiled adl support into the windows binaries myself. I tried very hard to make the code work on both platforms, and even I'm surprised the windows version works as well as the linux one. There is no ADL support for any other operating systems though.
|
|
|
|
With 11.8 drivers dummy plugs and extra monitors weren't needed, plus you can now have 8 HPU's.
Hopefully the revised version works with 11.8 when I test in 6 hours.
Nice work Con!
HPUs! w00t, one better than GPUs! Thanks |
|
|
|
|
I've updated the source tarballs and linux binaries as well. No new version, just new archive name. Links in top post.
|
|
|
|
|
Updated git tree: (new feature --temp-cutoff)
Ideally we should link with -ldl for dlopen() dlclose().
ByteReverse is not used and the bswap opcode breaks big endian builds. Remove it.
Ignore whether the display is active or not since only display enabled devices work this way, and we skip over repeat entries anwyay.
Win32 does not use dlopen so link in -ldl only when not on win32 and display what ldflags are being passed on ./configure.
Only reset values on exiting if we've ever modified them.
Flag adl as active if any card is successfully activated.
Add a thermal cutoff option as well and set it to 95 degrees by default.
Change the fan speed by only 5% if it's over the target temperature but less than the hysteresis value to minimise overshoot down in temperature.
|
|
|
|
|
On Linux, 11.6 driver with ANY sdk is fine. 2.1, 2.4 and 2.5 do not chew up CPU. It's all in the driver. 11.7 and 11.8 drivers use 100% CPU no matter how many cards you use, nor if you set that environment variable or not.
A fix for that would be most appreciated.
|
|
|
|
|
Show Posts
