Author

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

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
@ckolivas

THX for the USB Fix!

Code:
cgminer version 4.2.0 - Started: [2014-03-18 21:43:16]
--------------------------------------------------------------------------------------------------
 (5s):11.83G (avg):12.65Gh/s | A:140096  R:2736  HW:8044  WU:127.0/m
 ST: 3  SS: 1  NB: 132  LW: 357785  GF: 1  RF: 0
 Connected to bitcoin.minerpool.de diff 16 with stratum as user 13gtAPBFkrTq5QEnyxxpBKF2wDWvdKd7mw/+16
 Block: 4f8d22c7...  Diff:4.25G  Started: [16:20:44]  Best share: 666K
--------------------------------------------------------------------------------------------------
 [U]SB device management [P]ool management [S]ettings [D]isplay options [Q]uit
 1: ANU 1:                         | 1.820G/1.808Gh/s | A:21484 R:400 HW:1124 WU: 18.0/m
 3: ANU 3:                         | 1.726G/1.807Gh/s | A:19764 R:496 HW:1178 WU: 18.1/m
 4: ANU 4:                         | 1.827G/1.808Gh/s | A:19880 R:192 HW:1109 WU: 17.9/m
 5: ANU 5:                         | 1.826G/1.809Gh/s | A:19884 R:416 HW:1118 WU: 18.0/m
 6: ANU 6:                         | 1.808G/1.807Gh/s | A:20184 R:464 HW:1209 WU: 18.6/m
 7: ANU 7:                         | 1.743G/1.808Gh/s | A: 8400 R:128 HW: 487 WU: 18.2/m
 8: ANU 8:                         | 1.826G/1.806Gh/s | A: 8784 R:160 HW: 537 WU: 18.7/m
--------------------------------------------------------------------------------------------------
 [2014-03-19 08:22:19] ANU 2: Device failed to respond to restart
 [2014-03-19 08:22:19] ANU 2 failure, disabling!
 [2014-03-19 08:22:21] ANU 0: Device failed to respond to restart
 [2014-03-19 08:22:21] ANU 0 failure, disabling!

The miner start as new ANU 7 and 8 after "Device failure" new  Kiss

regards
Great, thanks for the feedback  Smiley
legendary
Activity: 3934
Merit: 2634
@ckolivas

THX for the USB Fix!
Quote
cgminer version 4.2.0 - Started: [2014-03-18 21:43:16]
--------------------------------------------------------------------------------------------------
 (5s):11.83G (avg):12.65Gh/s | A:140096  R:2736  HW:8044  WU:127.0/m
 ST: 3  SS: 1  NB: 132  LW: 357785  GF: 1  RF: 0
 Connected to bitcoin.minerpool.de diff 16 with stratum as user 13gtAPBFkrTq5QEnyxxpBKF2wDWvdKd7mw/+16
 Block: 4f8d22c7...  Diff:4.25G  Started: [16:20:44]  Best share: 666K
--------------------------------------------------------------------------------------------------
 SB device management [P]ool management ettings [D]isplay options [Q]uit
 1: ANU 1:                         | 1.820G/1.808Gh/s | A:21484 R:400 HW:1124 WU: 18.0/m
 3: ANU 3:                         | 1.726G/1.807Gh/s | A:19764 R:496 HW:1178 WU: 18.1/m
 4: ANU 4:                         | 1.827G/1.808Gh/s | A:19880 R:192 HW:1109 WU: 17.9/m
 5: ANU 5:                         | 1.826G/1.809Gh/s | A:19884 R:416 HW:1118 WU: 18.0/m
 6: ANU 6:                         | 1.808G/1.807Gh/s | A:20184 R:464 HW:1209 WU: 18.6/m
 7: ANU 7:                         | 1.743G/1.808Gh/s | A: 8400 R:128 HW: 487 WU: 18.2/m
 8: ANU 8:                         | 1.826G/1.806Gh/s | A: 8784 R:160 HW: 537 WU: 18.7/m
--------------------------------------------------------------------------------------------------
 [2014-03-19 08:22:19] ANU 2: Device failed to respond to restart
 [2014-03-19 08:22:19] ANU 2 failure, disabling!
 [2014-03-19 08:22:21] ANU 0: Device failed to respond to restart
 [2014-03-19 08:22:21] ANU 0 failure, disabling!

The miner start as new ANU 7 and 8 after "Device failure" new  Kiss

regards
member
Activity: 84
Merit: 10
Ok that's suspicious of being plugged into a usb port that winusb doesn't recognise, such as a usb3 port. I suspect the earlier version of cgminer included a different libusb which probably did recognise it (though that libusbx is buggy in so many other ways which is why I dropped it). See if you have any usb2 ports anywhere or a usb2 hub to plug in and see if it's recognised. If it doesn't show up with cgminer.exe -n then it will never work.

W00t.....USB 2.0 port works! Thanks alot! I can confirm it worked on the USB3 port with earlier releases.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
No idea then. Heck hashfast weren't even looking for windows support from me, I just told them I could get it working on it as an afterthought. You're ALWAYS going to be better off mining with linux with cgminer but I might take a look at losedows soon to see if I can figure out what the problem is. What does it show with "cgminer.exe -n" ?

Yeah, I don't want to complain really. It's just the windows binaries/readme suggest hashfast devices will work with it and I wondered if maybe the problem is at my end.

cgminer -n:

Code:
[2014-03-19 10:46:24] USB all: found 6 devices - listing known devices
 [2014-03-19 10:46:24] No known USB devices

I can confirm the HF device is there, WinUSB installed, PID is correct in device manager.
Ok that's suspicious of being plugged into a usb port that winusb doesn't recognise, such as a usb3 port. I suspect the earlier version of cgminer included a different libusb which probably did recognise it (though that libusbx is buggy in so many other ways which is why I dropped it). See if you have any usb2 ports anywhere or a usb2 hub to plug in and see if it's recognised. If it doesn't show up with cgminer.exe -n then it will never work.
member
Activity: 84
Merit: 10
No idea then. Heck hashfast weren't even looking for windows support from me, I just told them I could get it working on it as an afterthought. You're ALWAYS going to be better off mining with linux with cgminer but I might take a look at losedows soon to see if I can figure out what the problem is. What does it show with "cgminer.exe -n" ?

Yeah, I don't want to complain really. It's just the windows binaries/readme suggest hashfast devices will work with it and I wondered if maybe the problem is at my end.

cgminer -n:

Code:
[2014-03-19 10:46:24] USB all: found 6 devices - listing known devices
 [2014-03-19 10:46:24] No known USB devices

cgminer -D startup output (these PID's are all HID devices)

Code:
[2014-03-19 10:45:11] Started cgminer 4.2.0
 [2014-03-19 10:45:11] USB scan devices: checking for ICA devices
 [2014-03-19 10:45:11] RES: thread starting
 [2014-03-19 10:45:11] ICA looking for ICA 067b:2303 but found 8086:1c26 instead
 [2014-03-19 10:45:11] ICA looking for AMU 10c4:ea60 but found 8086:1c26 instead
 [2014-03-19 10:45:11] ICA looking for ANU 10c4:ea60 but found 8086:1c26 instead
 [2014-03-19 10:45:11] ICA looking for BLT 0403:6001 but found 8086:1c26 instead
 [2014-03-19 10:45:11] ICA looking for LLT 0403:6001 but found 8086:1c26 instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:6014 but found 8086:1c26 instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:8350 but found 8086:1c26 instead
 [2014-03-19 10:45:11] ICA looking for ICA 067b:2303 but found 8086:1c2d instead
 [2014-03-19 10:45:11] ICA looking for AMU 10c4:ea60 but found 8086:1c2d instead
 [2014-03-19 10:45:11] ICA looking for ANU 10c4:ea60 but found 8086:1c2d instead
 [2014-03-19 10:45:11] ICA looking for BLT 0403:6001 but found 8086:1c2d instead
 [2014-03-19 10:45:11] ICA looking for LLT 0403:6001 but found 8086:1c2d instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:6014 but found 8086:1c2d instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:8350 but found 8086:1c2d instead
 [2014-03-19 10:45:11] ICA looking for ICA 067b:2303 but found 046a:0107 instead
 [2014-03-19 10:45:11] ICA looking for AMU 10c4:ea60 but found 046a:0107 instead
 [2014-03-19 10:45:11] ICA looking for ANU 10c4:ea60 but found 046a:0107 instead
 [2014-03-19 10:45:11] ICA looking for BLT 0403:6001 but found 046a:0107 instead
 [2014-03-19 10:45:11] ICA looking for LLT 0403:6001 but found 046a:0107 instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:6014 but found 046a:0107 instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:8350 but found 046a:0107 instead
 [2014-03-19 10:45:11] ICA looking for ICA 067b:2303 but found 046d:c05a instead
 [2014-03-19 10:45:11] ICA looking for AMU 10c4:ea60 but found 046d:c05a instead
 [2014-03-19 10:45:11] ICA looking for ANU 10c4:ea60 but found 046d:c05a instead
 [2014-03-19 10:45:11] ICA looking for BLT 0403:6001 but found 046d:c05a instead
 [2014-03-19 10:45:11] ICA looking for LLT 0403:6001 but found 046d:c05a instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:6014 but found 046d:c05a instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:8350 but found 046d:c05a instead
 [2014-03-19 10:45:11] ICA looking for ICA 067b:2303 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for AMU 10c4:ea60 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for ANU 10c4:ea60 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for BLT 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for LLT 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:6014 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:8350 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for ICA 067b:2303 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for AMU 10c4:ea60 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for ANU 10c4:ea60 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for BLT 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for LLT 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:6014 but found 8087:0024 instead
 [2014-03-19 10:45:11] ICA looking for CMR 0403:8350 but found 8087:0024 instead
 [2014-03-19 10:45:11] USB scan devices: checking for BAS devices
 [2014-03-19 10:45:11] BAS looking for BAS 0403:6014 but found 8086:1c26 instead
 [2014-03-19 10:45:11] BAS looking for BAS 0403:6014 but found 8086:1c2d instead
 [2014-03-19 10:45:11] BAS looking for BAS 0403:6014 but found 046a:0107 instead
 [2014-03-19 10:45:11] BAS looking for BAS 0403:6014 but found 046d:c05a instead
 [2014-03-19 10:45:11] BAS looking for BAS 0403:6014 but found 8087:0024 instead
 [2014-03-19 10:45:11] BAS looking for BAS 0403:6014 but found 8087:0024 instead
 [2014-03-19 10:45:11] USB scan devices: checking for BF1 devices
 [2014-03-19 10:45:12] BF1 looking for BF1 03eb:204b but found 8086:1c26 instead
 [2014-03-19 10:45:12] BF1 looking for BXF 198c:b1f1 but found 8086:1c26 instead
 [2014-03-19 10:45:12] BF1 looking for NF1 04d8:00de but found 8086:1c26 instead
 [2014-03-19 10:45:12] BF1 looking for BXM 0403:6014 but found 8086:1c26 instead
 [2014-03-19 10:45:12] BF1 looking for BF1 03eb:204b but found 8086:1c2d instead
 [2014-03-19 10:45:12] BF1 looking for BXF 198c:b1f1 but found 8086:1c2d instead
 [2014-03-19 10:45:12] BF1 looking for NF1 04d8:00de but found 8086:1c2d instead
 [2014-03-19 10:45:12] BF1 looking for BXM 0403:6014 but found 8086:1c2d instead
 [2014-03-19 10:45:12] BF1 looking for BF1 03eb:204b but found 046a:0107 instead
 [2014-03-19 10:45:12] BF1 looking for BXF 198c:b1f1 but found 046a:0107 instead
 [2014-03-19 10:45:12] BF1 looking for NF1 04d8:00de but found 046a:0107 instead
 [2014-03-19 10:45:12] BF1 looking for BXM 0403:6014 but found 046a:0107 instead
 [2014-03-19 10:45:12] BF1 looking for BF1 03eb:204b but found 046d:c05a instead
 [2014-03-19 10:45:12] BF1 looking for BXF 198c:b1f1 but found 046d:c05a instead
 [2014-03-19 10:45:12] BF1 looking for NF1 04d8:00de but found 046d:c05a instead
 [2014-03-19 10:45:12] BF1 looking for BXM 0403:6014 but found 046d:c05a instead
 [2014-03-19 10:45:12] BF1 looking for BF1 03eb:204b but found 8087:0024 instead
 [2014-03-19 10:45:12] BF1 looking for BXF 198c:b1f1 but found 8087:0024 instead
 [2014-03-19 10:45:12] BF1 looking for NF1 04d8:00de but found 8087:0024 instead
 [2014-03-19 10:45:12] BF1 looking for BXM 0403:6014 but found 8087:0024 instead
 [2014-03-19 10:45:12] BF1 looking for BF1 03eb:204b but found 8087:0024 instead
 [2014-03-19 10:45:12] BF1 looking for BXF 198c:b1f1 but found 8087:0024 instead
 [2014-03-19 10:45:12] BF1 looking for NF1 04d8:00de but found 8087:0024 instead
 [2014-03-19 10:45:12] BF1 looking for BXM 0403:6014 but found 8087:0024 instead
 [2014-03-19 10:45:12] USB scan devices: checking for CTA devices
 [2014-03-19 10:45:12] CTA looking for CTA 1cbe:0003 but found 8086:1c26 instead
 [2014-03-19 10:45:12] CTA looking for CTA 1cbe:0003 but found 8086:1c2d instead
 [2014-03-19 10:45:12] CTA looking for CTA 1cbe:0003 but found 046a:0107 instead
 [2014-03-19 10:45:12] CTA looking for CTA 1cbe:0003 but found 046d:c05a instead
 [2014-03-19 10:45:12] CTA looking for CTA 1cbe:0003 but found 8087:0024 instead
 [2014-03-19 10:45:12] CTA looking for CTA 1cbe:0003 but found 8087:0024 instead
 [2014-03-19 10:45:12] USB scan devices: checking for HFA devices
 [2014-03-19 10:45:12] HFA looking for HFA 297c:0001 but found 8086:1c26 instead
 [2014-03-19 10:45:12] HFA looking for HFA 297c:0001 but found 8086:1c2d instead
 [2014-03-19 10:45:12] HFA looking for HFA 297c:0001 but found 046a:0107 instead
 [2014-03-19 10:45:12] HFA looking for HFA 297c:0001 but found 046d:c05a instead
 [2014-03-19 10:45:12] HFA looking for HFA 297c:0001 but found 8087:0024 instead
 [2014-03-19 10:45:12] HFA looking for HFA 297c:0001 but found 8087:0024 instead
 [2014-03-19 10:45:12] USB scan devices: checking for KLN devices
 [2014-03-19 10:45:12] KLN looking for KLN 04d8:f60a but found 8086:1c26 instead
 [2014-03-19 10:45:12] KLN looking for KLI 04d8:f60a but found 8086:1c26 instead
 [2014-03-19 10:45:12] KLN looking for KLN 04d8:f60a but found 8086:1c2d instead
 [2014-03-19 10:45:12] KLN looking for KLI 04d8:f60a but found 8086:1c2d instead
 [2014-03-19 10:45:12] KLN looking for KLN 04d8:f60a but found 046a:0107 instead
 [2014-03-19 10:45:12] KLN looking for KLI 04d8:f60a but found 046a:0107 instead
 [2014-03-19 10:45:12] KLN looking for KLN 04d8:f60a but found 046d:c05a instead
 [2014-03-19 10:45:12] KLN looking for KLI 04d8:f60a but found 046d:c05a instead
 [2014-03-19 10:45:12] KLN looking for KLN 04d8:f60a but found 8087:0024 instead
 [2014-03-19 10:45:12] KLN looking for KLI 04d8:f60a but found 8087:0024 instead
 [2014-03-19 10:45:12] KLN looking for KLN 04d8:f60a but found 8087:0024 instead
 [2014-03-19 10:45:12] KLN looking for KLI 04d8:f60a but found 8087:0024 instead
 [2014-03-19 10:45:12] USB scan devices: checking for DRB devices
 [2014-03-19 10:45:12] DRB looking for DRB 03eb:2404 but found 8086:1c26 instead
 [2014-03-19 10:45:12] DRB looking for DRB 03eb:2404 but found 8086:1c2d instead
 [2014-03-19 10:45:12] DRB looking for DRB 03eb:2404 but found 046a:0107 instead
 [2014-03-19 10:45:12] DRB looking for DRB 03eb:2404 but found 046d:c05a instead
 [2014-03-19 10:45:12] DRB looking for DRB 03eb:2404 but found 8087:0024 instead
 [2014-03-19 10:45:12] DRB looking for DRB 03eb:2404 but found 8087:0024 instead
 [2014-03-19 10:45:12] USB scan devices: checking for AVA devices
 [2014-03-19 10:45:13] AVA looking for BTB 0403:6001 but found 8086:1c26 instead
 [2014-03-19 10:45:13] AVA looking for BBF 0403:6001 but found 8086:1c26 instead
 [2014-03-19 10:45:13] AVA looking for AVA 0403:6001 but found 8086:1c26 instead
 [2014-03-19 10:45:13] AVA looking for BTB 0403:6001 but found 8086:1c2d instead
 [2014-03-19 10:45:13] AVA looking for BBF 0403:6001 but found 8086:1c2d instead
 [2014-03-19 10:45:13] AVA looking for AVA 0403:6001 but found 8086:1c2d instead
 [2014-03-19 10:45:13] AVA looking for BTB 0403:6001 but found 046a:0107 instead
 [2014-03-19 10:45:13] AVA looking for BBF 0403:6001 but found 046a:0107 instead
 [2014-03-19 10:45:13] AVA looking for AVA 0403:6001 but found 046a:0107 instead
 [2014-03-19 10:45:13] AVA looking for BTB 0403:6001 but found 046d:c05a instead
 [2014-03-19 10:45:13] AVA looking for BBF 0403:6001 but found 046d:c05a instead
 [2014-03-19 10:45:13] AVA looking for AVA 0403:6001 but found 046d:c05a instead
 [2014-03-19 10:45:13] AVA looking for BTB 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:13] AVA looking for BBF 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:13] AVA looking for AVA 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:13] AVA looking for BTB 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:13] AVA looking for BBF 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:13] AVA looking for AVA 0403:6001 but found 8087:0024 instead
 [2014-03-19 10:45:13] No devices detected!
 [2014-03-19 10:45:13] Waiting for USB hotplug devices or press q to quit
 [2014-03-19 10:45:13] Need to specify at least one pool server.
 [2014-03-19 10:45:17] Shutdown signal received.

I can confirm the HF device is there, WinUSB installed, PID is correct in device manager.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
There are no known problems on windows, but then I have not tried running any hashfast devices on windows since my very first release. You did the WinUSB driver dance with zadig?

Yes I did the moonwalk with Zadig, and earlier releases of cgminer worked well with it!
No idea then. Heck hashfast weren't even looking for windows support from me, I just told them I could get it working on it as an afterthought. You're ALWAYS going to be better off mining with linux with cgminer but I might take a look at losedows soon to see if I can figure out what the problem is. What does it show with "cgminer.exe -n" ?
member
Activity: 84
Merit: 10
@ckolivas: Are there known issues with the newer CG miner versions with Hashfast devices on Windows(tm) or has anything changed prerequisite wise?
I been trying all the cgminer releases since ~4.0 (The hashfast firmware update releases) and none of them works on windows. No devices detected. Only seems to show HID PID's in debug log.

No problems whatsoever on Linux though Smiley
There are no known problems on windows, but then I have not tried running any hashfast devices on windows since my very first release. You did the WinUSB driver dance with zadig?

Yes I did the moonwalk with Zadig, and earlier releases of cgminer worked well with it!
newbie
Activity: 5
Merit: 0
Try picking a valid collection of drivers to compile on your hardware ........
Actually the same collection worked for 4.1.0, and the error doesn't really seem to be caused by choice of hardware (of course you don't hit it if avalon2 disabled, but I still think this a bug if avalon2 just cannot be built...)
Yes it is a bug if the avalon2 code can't be built; that will be fixed... however the avalon2 code doesn't even work if I recall correctly so there is no point any user building it just yet either.
Oops, thanks for the info.

I'm just trying to build a "general" version that have all drivers enabled (except incompatible KnC as pointed out earlier on this thread), so if avalon2 just doesn't work at all, I'll simply disable it for this release.

OT: Is providing "general" versions like this really a bad idea? I don't use all of them of course, but what I think is, others could get a compiled version that just works.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Try picking a valid collection of drivers to compile on your hardware ........
Actually the same collection worked for 4.1.0, and the error doesn't really seem to be caused by choice of hardware (of course you don't hit it if avalon2 disabled, but I still think this a bug if avalon2 just cannot be built...)
Yes it is a bug if the avalon2 code can't be built; that will be fixed... however the avalon2 code doesn't even work if I recall correctly so there is no point any user building it just yet either.
newbie
Activity: 5
Merit: 0
Try picking a valid collection of drivers to compile on your hardware ........
Actually the same collection worked for 4.1.0, and the error doesn't really seem to be caused by choice of hardware (of course you don't hit it if avalon2 disabled, but I still think this a bug if avalon2 just cannot be built...)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
@ckolivas: Are there known issues with the newer CG miner versions with Hashfast devices on Windows(tm) or has anything changed prerequisite wise?
I been trying all the cgminer releases since ~4.0 (The hashfast firmware update releases) and none of them works on windows. No devices detected. Only seems to show HID PID's in debug log.

No problems whatsoever on Linux though Smiley
There are no known problems on windows, but then I have not tried running any hashfast devices on windows since my very first release. You did the WinUSB driver dance with zadig?
member
Activity: 84
Merit: 10
@ckolivas: Are there known issues with the newer CG miner versions with Hashfast devices on Windows(tm) or has anything changed prerequisite wise?
I been trying all the cgminer releases since ~4.0 (The hashfast firmware update releases) and none of them works on windows. No devices detected. Only seems to show HID PID's in debug log.

No problems whatsoever on Linux though Smiley
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Try picking a valid collection of drivers to compile on your hardware ........
newbie
Activity: 5
Merit: 0
Hi I'm getting the following error when trying to compile the v4.2.0 tag on github:

Code:
  CC       cgminer-driver-minion.o
In file included from miner.h:26:0,
                 from driver-avalon2.c:36:
driver-avalon2.c: In function 'avalon2_stratum_pkgs':
driver-avalon2.c:397:20: error: 'struct stratum_work' has no member named 'cb_len'
         pool->swork.cb_len,
                    ^
logging.h:40:42: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                          ^
driver-avalon2.c:400:13: error: 'struct pool' has no member named 'merkle_offset'
         pool->merkle_offset,
             ^
logging.h:40:42: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                          ^
driver-avalon2.c:401:20: error: 'struct stratum_work' has no member named 'merkles'
         pool->swork.merkles);
                    ^
logging.h:40:42: note: in definition of macro 'applog'
    snprintf(tmp42, sizeof(tmp42), fmt, ##__VA_ARGS__); \
                                          ^
In file included from /usr/include/pthread.h:22:0,
                 from driver-avalon2.c:16:
driver-avalon2.c:403:27: error: 'struct stratum_work' has no member named 'cb_len'
  tmp = be32toh(pool->swork.cb_len);
                           ^
driver-avalon2.c:412:20: error: 'struct pool' has no member named 'merkle_offset'
  tmp = be32toh(pool->merkle_offset);
                    ^
driver-avalon2.c:415:27: error: 'struct stratum_work' has no member named 'merkles'
  tmp = be32toh(pool->swork.merkles);
                           ^
driver-avalon2.c:454:17: error: 'struct stratum_work' has no member named 'cb_len'
  a = pool->swork.cb_len / AVA2_P_DATA_LEN;
                 ^
driver-avalon2.c:455:17: error: 'struct stratum_work' has no member named 'cb_len'
  b = pool->swork.cb_len % AVA2_P_DATA_LEN;
                 ^
driver-avalon2.c:471:17: error: 'struct stratum_work' has no member named 'merkles'
  b = pool->swork.merkles;
                 ^
driver-avalon2.c: In function 'avalon2_scanhash':
driver-avalon2.c:695:18: error: 'struct stratum_work' has no member named 'cb_len'
   if (pool->swork.cb_len > AVA2_P_COINBASE_SIZE)
                  ^
driver-avalon2.c:697:18: error: 'struct stratum_work' has no member named 'merkles'
   if (pool->swork.merkles > AVA2_P_MERKLES_COUNT)
                  ^
driver-avalon2.c: In function 'avalon2_api_stats':
driver-avalon2.c:760:3: warning: passing argument 3 of 'api_add_string' from incompatible pointer type [enabled by default]
   root = api_add_string(root, buf, &(info->mm_version[i]), false);
   ^
In file included from driver-avalon2.c:36:0:
miner.h:1487:25: note: expected 'char *' but argument is of type 'char (*)[16]'
 extern struct api_data *api_add_string(struct api_data *root, char *name, char *data, bool copy_data);
                         ^
driver-avalon2.c: At top level:
driver-avalon2.c:815:2: warning: initialization from incompatible pointer type [enabled by default]
  .drv_detect = avalon2_detect,
  ^
driver-avalon2.c:815:2: warning: (near initialization for 'avalon2_drv.drv_detect') [enabled by default]
Makefile:1137: recipe for target 'cgminer-driver-avalon2.o' failed
make[2]: *** [cgminer-driver-avalon2.o] Error 1
make[2]: *** Waiting for unfinished jobs....
driver-minion.c: In function 'minion_spi_reply':
driver-minion.c:1934:8: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
    read(minioninfo->gpiointfd, &c, 1);
        ^
make[2]: Leaving directory '/build/cgminer/src/cgminer'
Makefile:1243: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/build/cgminer/src/cgminer'
Makefile:648: recipe for target 'all' failed
make: *** [all] Error 2

Please help, thanks!
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Ok so on starting with -o -p -u and --btc-address I saved a conf file and didn't see a difference between that and my previous one.  All options had correct values but I didn't see an additional pool appended to my list. I didn't avoid loading my previous conf file.

Is the bitcoin address not saved into the config file? I assume it is and that my previous config loading messed things up.

Is it ok if I omit the -o -p and -u with the appropriate info in them and just keep --btc-address in my command line will it still mine paying to my address?
No, the write config from menu is really limited in what it stores at the moment, storing only about 1/3 of the options cos I never got around to updating it. You'll have to manually edit the file to add it or keep the address on your command line.
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Ok so on starting with -o -p -u and --btc-address I saved a conf file and didn't see a difference between that and my previous one.  All options had correct values but I didn't see an additional pool appended to my list. I didn't avoid loading my previous conf file.

Is the bitcoin address not saved into the config file? I assume it is and that my previous config loading messed things up.

Is it ok if I omit the -o -p and -u with the appropriate info in them and just keep --btc-address in my command line will it still mine paying to my address?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Yes you have to specify a bitcoin address when mining GBT solo. When you were mining with getwork to bitcoind, bitcoind would randomly give you new addresses but no such option exists with GBT solo since you are building everything from scratch. Mind you, when you are mining to a pool with stratum, that pool is actually talking GBT solo to its own bitcoind anyway. The issue is that stratum itself, or a more comprehensive mining communication protocol could be built into bitcoind directly, but the bitcoind devs feel that as much mining code should be separated from bitcoind as possible, to not associate bitcoind with the concept of mining. Seems silly if you ask me but meh, I got tired of arguing that one, it's not like bitcoin exists without mining so there's no point pretending it has nothing to do with it.
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Thanks for the release.
However, I don't think it's the right thing to do to make solo miners mine by default to an address owned by you, unless they pay attention to the documentation and add the --btc-address option.
Some people like me mine solo even if they have a low hashing power. They do so because pool mining wouldn't provide a significant income, and they rather take their chance with the solo mining lottery. You shouldn't assume that somebody doing solo mining has millions worth of equipment so if they don't pay attention to your documentation it's only fair to punish them by ripping them off of their mining.
In any case, simply upgrading a piece of software shouldn't require the user to add an option in order to keep the previous behaviour. And in this case the change in behaviour is quite dramatic: all mining will go to your address instead of the one belonging to the user!
This is a bad default because it is most likely not what a user would want to do by default, and the most sensible default behaviour should be for cgminer to refuse to start and print an error.
The problem here is that obviously there are money involved, and I think this really reflects negatively on your reputation and the reputation of cgminer.
The fact that a piece of software is given away for free doesn't mean that the developer doesn't have to behave professionally and treat his users with respect.
Other high profile open source software like Linux or Apache certainly would never do anything like that.

Unless I misunderstood GBT that is the exact way it works. You don't mine to its address. You mine to an address you specify at least from a bitcoind. Pools that use it have a different GBT implementation so that you can't get all the pools money. Don't get me wrong I do wish it defaulted to the bitcoind's local address not some other address. I'm not saying its a cgminer thing.

Still I my bitcoind doesn't keep up with my setup as is so I really do like the upgrade. I do suppose I could have the GBT thing wrong but I seem to remember it that way. Part of why I wish bitcoind had stratum instead.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
My concern was existing solo miners.
I have always had bitcoind running and I was mining with these options:
cgminer -o http://127.0.0.1:8332 -u bitcoinrpc -p $PASSWORD

cgminer was displaying this:
Connected to 127.0.0.1 diff 4.25G without LP as user bitcoinrpc

Given that the difficulty matched the network difficulty I always assumed it was solo mining, was it not? How was I not mining "in a meaningful way" ? =)
Bitcoind would run out of work usually around 5GH. Lower hashrates would indeed mine solo but it was very cpu intensive and inefficient.
Quote
Also I always assumed that cgminer would ask bitcoind for an address for the mined btc, in a similar way in which it asks for the difficulty.
The fact that it could have been sending the mined btc to some hard-coded address belonging to you really didn't cross my mind, and I still think it's a bit strange as a default. =/
So that's why when I read the 4.2.0 release notes I thought that this was a change in behaviour.
Were versions of cgminer previous to 4.2.0 already using your hard-coded address if one didn't specify --btc-address ?

Wouldn't it be possible to have the receiving address always displayed by cgminer while running?
That would avoid any confusion, and would be quite an important piece of information to have. =)
Sure, next version.
newbie
Activity: 28
Merit: 0
No you're reading it wrong. It will not mine solo unless you go to the effort of setting up bitcoind AND adding it as a pool and NOT follow the instructions that discretely say to add a btc address. It does NOT change default behaviour one bit for existing miners with existing configurations.

EDIT: Or is your concern existing solo miners? The previous versions of cgminer could not meaningfully mine solo so I didn't think anyone was trying to.

My concern was existing solo miners.
I have always had bitcoind running and I was mining with these options:
cgminer -o http://127.0.0.1:8332 -u bitcoinrpc -p $PASSWORD

cgminer was displaying this:
Connected to 127.0.0.1 diff 4.25G without LP as user bitcoinrpc

Given that the difficulty matched the network difficulty I always assumed it was solo mining, was it not? How was I not mining "in a meaningful way" ? =)
Also I always assumed that cgminer would ask bitcoind for an address for the mined btc, in a similar way in which it asks for the difficulty.
The fact that it could have been sending the mined btc to some hard-coded address belonging to you really didn't cross my mind, and I still think it's a bit strange as a default. =/
So that's why when I read the 4.2.0 release notes I thought that this was a change in behaviour.
Were versions of cgminer previous to 4.2.0 already using your hard-coded address if one didn't specify --btc-address ?

Wouldn't it be possible to have the receiving address always displayed by cgminer while running? That would avoid any confusion, and would be quite an important piece of information to have. =)
Jump to: