OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

I've had some safeguards against the "lost connection" crash in BFGMiner for a while. If anyone wants to tell Con (he likes to ignore me), the problem is that the submission threads pile up (as they sit around trying to retry) and Windows doesn't like having a lot of threads.

Figures it would be windows problem, no wonder I have never seen it. And there you are quoted so he sees it..

That's helpful indeed.

However it does not change the fact that I'd really appreciate it if at least *one* of the users out there getting crashes at least tried to help me get debugging info.

[1714847545]

1714847545

[1714847545]

1714847545

[1714847545]

1714847545

[1714847545]

1714847545

[1714847545]

1714847545

[crazyates]

I've had some safeguards against the "lost connection" crash in BFGMiner for a while. If anyone wants to tell Con (he likes to ignore me), the problem is that the submission threads pile up (as they sit around trying to retry) and Windows doesn't like having a lot of threads.

Figures it would be windows problem, no wonder I have never seen it. And there you are quoted so he sees it..

That's helpful indeed.

However it does not change the fact that I'd really appreciate it if at least *one* of the users out there getting crashes at least tried to help me get debugging info.

I set it up, but it appears to take time for this problem to come up. I'll let you know when I have something.

[-ck]

I set it up, but it appears to take time for this problem to come up. I'll let you know when I have something.

Much appreciated! Occasionally nothing useful comes from the information, or windows decides to disable the debugger, but at least we have tried.

[crazyates]

I set it up, but it appears to take time for this problem to come up. I'll let you know when I have something.

Much appreciated! Occasionally nothing useful comes from the information, or windows decides to disable the debugger, but at least we have tried.

cgminer-db.exe caused an Access Violation at location 63656e6e Reading from location 63656e6e.

Registers:
eax=00000000 ebx=070fd26c ecx=070fd72d edx=070fd72e esi=6f43203a edi=070fd77c
eip=772015de esp=070fd258 ebp=00002746 iopl=0         nv up ei pl zr na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246

Call stack:
772015DE  ntdll.dll:772015DE  ZwRaiseException
771F014E  ntdll.dll:771F014E  KiUserExceptionDispatcher
070FD26C
070FD2BC

[-ck]

I set it up, but it appears to take time for this problem to come up. I'll let you know when I have something.

Much appreciated! Occasionally nothing useful comes from the information, or windows decides to disable the debugger, but at least we have tried.

cgminer-db.exe caused an Access Violation at location 63656e6e Reading from location 63656e6e.

Registers:
eax=00000000 ebx=070fd26c ecx=070fd72d edx=070fd72e esi=6f43203a edi=070fd77c
eip=772015de esp=070fd258 ebp=00002746 iopl=0         nv up ei pl zr na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246

Call stack:
772015DE  ntdll.dll:772015DE  ZwRaiseException
771F014E  ntdll.dll:771F014E  KiUserExceptionDispatcher
070FD26C
070FD2BC

Did it not give you the option to debug it when it crashed? 

[Krak]

I've been getting this a lot with 2.9.3. It seems to be mistakenly marking pools as down now. This is also the case with us1.ozco.in, but that one isn't showing as alive at all now.

Code:

[2012-11-12 21:21:30] Pool 2 http://mtred.com:8337 not responding!
[2012-11-12 21:21:31] Accepted 7e2684c5 Diff 2/1 GPU 0 pool 0
[2012-11-12 21:21:43] Accepted 066a52b0 Diff 39/1 GPU 1 pool 0
[2012-11-12 21:21:58] Accepted bcddcf15 Diff 1/1 GPU 1 pool 0
[2012-11-12 21:22:00] Accepted f9598f8b Diff 1/1 GPU 0 pool 0
[2012-11-12 21:22:05] Accepted b7fda617 Diff 1/1 GPU 1 pool 0
[2012-11-12 21:22:05] Accepted 1f56781f Diff 8/1 GPU 1 pool 0
[2012-11-12 21:22:07] Accepted e80c0acb Diff 1/1 GPU 1 pool 0
[2012-11-12 21:22:09] Accepted 5bc7ca5d Diff 2/1 GPU 0 pool 0
[2012-11-12 21:22:19] Accepted 680e27ba Diff 2/1 GPU 0 pool 0
[2012-11-12 21:22:20] Accepted 39c4a74f Diff 4/1 GPU 1 pool 0
[2012-11-12 21:22:29] Accepted 8fbc63d7 Diff 1/1 GPU 1 pool 0
[2012-11-12 21:22:34] Pool 2 http://mtred.com:8337 alive

[-ck]

I've been getting this a lot with 2.9.3. It seems to be mistakenly marking pools as down now. This is also the case with us1.ozco.in, but that one isn't showing as alive at all now.

Code:

[2012-11-12 21:21:30] Pool 2 http://mtred.com:8337 not responding!
[2012-11-12 21:21:31] Accepted 7e2684c5 Diff 2/1 GPU 0 pool 0
[2012-11-12 21:21:43] Accepted 066a52b0 Diff 39/1 GPU 1 pool 0
[2012-11-12 21:21:58] Accepted bcddcf15 Diff 1/1 GPU 1 pool 0
[2012-11-12 21:22:00] Accepted f9598f8b Diff 1/1 GPU 0 pool 0
[2012-11-12 21:22:05] Accepted b7fda617 Diff 1/1 GPU 1 pool 0
[2012-11-12 21:22:05] Accepted 1f56781f Diff 8/1 GPU 1 pool 0
[2012-11-12 21:22:07] Accepted e80c0acb Diff 1/1 GPU 1 pool 0
[2012-11-12 21:22:09] Accepted 5bc7ca5d Diff 2/1 GPU 0 pool 0
[2012-11-12 21:22:19] Accepted 680e27ba Diff 2/1 GPU 0 pool 0
[2012-11-12 21:22:20] Accepted 39c4a74f Diff 4/1 GPU 1 pool 0
[2012-11-12 21:22:29] Accepted 8fbc63d7 Diff 1/1 GPU 1 pool 0
[2012-11-12 21:22:34] Pool 2 http://mtred.com:8337 alive

It's not a mistake. Previously cgminer did not check the backup pools were working. Now it does check them even if not mining on them.

[Krak]

It's not a mistake. Previously cgminer did not check the backup pools were working. Now it does check them even if not mining on them.

I know that, but Mt. Red couldn't possibly be going down as often as cgminer is saying. Also, I'm pretty sure us1.ozco.in is currently running just fine.

[-ck]

It's not a mistake. Previously cgminer did not check the backup pools were working. Now it does check them even if not mining on them.

I know that, but Mt. Red couldn't possibly be going down as often as cgminer is saying. Also, I'm pretty sure us1.ozco.in is currently running just fine.

It is advantageous if a pool goes down for cgminer to not try to switch to another one that hasn't been working. 1 failed getwork is enough to do it. It's the same mechanism it uses on startup to see if a pool is alive. Overkill? Dunno, I wasn't expecting pools to fail sending getworks so often.

[monstrs]

Have no more crashes on win7 64bit, but i am using 2.8.7 cgminer.

[-ck]

Hi.
Small reminder: "Q:" is still very wrong.

Code:

 cgminer version 2.9.3 - Started: [2012-11-12 11:10:19]
--------------------------------------------------------------------------------
 (5s):14.55M (avg):14.63Mh/s | Q:4  A:31  R:6  HW:0  E:775%  U:0.2/m

It is p2pool, so longpool every 10sec, 21 new blocks in mean time but Q is only 4 and E is hitting roof on this small MH/s

Still no idea, but the fake "burst" in Q should have gone. It's still a low priority concern but I will investigate at some stage.

[Ginsley]

Hi,

at the moment i am trying to install CGMiner on a Raspberry Pi. As OS i am using the Wheezy and want to mine with a ZTex 1.15x board.
The problem is, CGMiner isnt recognizing my board - "All devices disabled, cannot mine!"

First i installed all needed packages:

Code:

sudo apt-get update
sudo apt-get install autoconf
sudo apt-get install libtool
sudo apt-get install libncurses-dev
sudo apt-get install yasm
sudo apt-get install curl
sudo apt-get install libcurl4-openssl-dev
sudo apt-get install pkg-config
sudo apt-get install libudev-dev
sudo apt-get install libusb-dev
sudo apt-get install libusb-1.0-0-dev

I tried it with a proposal from another thread too

Code:

sudo apt-get install build-essential git dh-autoreconf libcurl4-gnutls-dev libusb-1.0-0-dev libusb-dev libncurses-dev libudev-dev yasm screen

then i loaded CGMiner via git:

Code:

sudo git clone https://github.com/ckolivas/cgminer.git
cd cgminer

## Set the flags for the compiler
CFLAGS="-g -O2 -W -Wall"

Next step was autogen with ZTex enabled:

Code:

sudo ./autogen.sh --disable-opencl --enable-ztex

autogen doesnt write out any errors and says use for ztex is enabled after it finished.
So i build CGMiner via

Code:

sudo make clean
sudo make

After that i connect my ZTex to the RPi - but i dont get any ttyUSB* file in the /dev folder - so i do following steps:

Code:

sudo modprobe ftdi_sio vendor=0x211a product=0x0100
sudo chmod a+rw /dev/ttyUSB*

After that i have a ttyUSB* file in /dev - so far it worked as it seems.

Now i try to start cgminer - first without any option:

Code:

cgminer
All devices disabled, cannot mine!

Then i tried to start it with the option -S / --scan-serial

Code:

cgminer -S auto
[2012-11-12 16:56:29] cgminer: -S: unrecognized option

So i ask myself what i am doing wrong, that -S isnt recognized.
Can anyone in here help?

[kano]

ztex uses libusb not -S (serial USB) so the -S option wont be there with only --enable-ztex
(i.e. it doesn't use /dev/ttyUSB* at all)

It auto detects all ztex devices with IDVENDOR 0x221A and IDPRODUCT 0x0100

However, the ztex code doesn't call libusb_detach_kernel_driver() so your modprobe might have been the cause of it failing

Unload ftdi_sio manually or reboot and try without modprobe

Also cgminer -D -T --verbose will tell you what's being detected and what may have gone wrong

Edit: P.S. you don't need yasm

[crazyates]

Did it not give you the option to debug it when it crashed? 

It did, but that's all the Dr. Mingw window gave me.

It seems to happen more often when I set the priority to "Realtime", as I think I remember someone saying that can make a slight boost in hashrate. However, I havn't noticed a difference in the newer versions, so I'll stop doing that from now on, and see if the problem persists.

[mdude77]

Did it not give you the option to debug it when it crashed? 

It did, but that's all the Dr. Mingw window gave me.

It seems to happen more often when I set the priority to "Realtime", as I think I remember someone saying that can make a slight boost in hashrate. However, I havn't noticed a difference in the newer versions, so I'll stop doing that from now on, and see if the problem persists.

It crashes for me when my internet connection gets spotty or the pool I'm on gets spotty.  Seems to be stratum only.  I never change the priority.

M

[Roland68]

Sadly, under Windows for me, it's a stratum related problem ... used the -fix option solved the problem ...

Just hope, that pool don't stop supporting "normal" getwork protocol ..

[Ginsley]

ztex uses libusb not -S (serial USB) so the -S option wont be there with only --enable-ztex
(i.e. it doesn't use /dev/ttyUSB* at all)

It auto detects all ztex devices with IDVENDOR 0x221A and IDPRODUCT 0x0100

However, the ztex code doesn't call libusb_detach_kernel_driver() so your modprobe might have been the cause of it failing

Unload ftdi_sio manually or reboot and try without modprobe

Also cgminer -D -T --verbose will tell you what's being detected and what may have gone wrong

Edit: P.S. you don't need yasm

Thanks for your hints - i tried it the way you told me, but got no success in running my ZTex board.

Doing "cgminer -D -T --verbose" printed out the following:

Code:

pi@raspberrypi ~/cgminer $ cgminer -D -T --verbose
 [2012-11-13 16:42:43] Started cgminer 2.9.3                    
 [2012-11-13 16:42:43] Not a ZTEX device 1d6b:0002                    
 [2012-11-13 16:42:43] Not a ZTEX device 0424:9512                    
 [2012-11-13 16:42:43] Not a ZTEX device 0424:ec00                    
 [2012-11-13 16:42:43] Not a ZTEX device 05e3:0608                    
 [2012-11-13 16:42:43] Not a ZTEX device 05e3:0608                    
 [2012-11-13 16:42:43] Not a ZTEX device 046a:0023                    
 [2012-11-13 16:42:43] Ztex check device: Failed to open handle with error -3                    
 [2012-11-13 16:42:43] prepare device: -3                    
All devices disabled, cannot mine!

just to be sure the board is connected and recognized i did the following:

Code:

pi@raspberrypi ~/cgminer $ dmesg | grep -i ZTex
[    4.865489] usb 1-1.3.4.3: Manufacturer: ZTEX
pi@raspberrypi ~/cgminer $ dmesg | grep -i vendor
[    1.815407] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.613572] usb 1-1: New USB device found, idVendor=0424, idProduct=9512
[    3.063878] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    3.405179] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0608
[    3.899144] usb 1-1.3.1: New USB device found, idVendor=046d, idProduct=c03e
[    4.285279] usb 1-1.3.4: New USB device found, idVendor=05e3, idProduct=0608 
[    4.809482] usb 1-1.3.4.3: New USB device found, idVendor=221a, idProduct=0100
[    5.124495] usb 1-1.3.4.4: New USB device found, idVendor=046a, idProduct=0023
[ 3081.476601] usb 1-1.3.1: New USB device found, idVendor=046d, idProduct=c03e

As you can see there, the ZTex is connected and recognized by the RPi - vendor and productID is the one, cgminer should look for (as you said).
Any hints/help?

P.S.: I reinstalled my Wheezy OS and loaded the needed packages new (without yasm, as you said) - so far it should be clean.

[streetuff]

i had to add the following to /etc/udev/rules.d/90-ztex.rules

SUBSYSTEM=="usb", ATTR{idVendor}=="221a", ATTR{idProduct}=="0100", MODE="0660", GROUP="plugdev"

that enables you to run cgminer without beeing root with ztex devices.

[mdude77]

I cannot reproduce the windows crashes as the only machine I have that can run windows can barely mine at all.

If you are having windows crashes, I need your help to debug the issues.

See here for how you can help:
http://ck.kolivas.org/apps/cgminer/debug/

If you have a reliable test case that crashes cgminer then you are the person most likely to be able to help me fix it.

Here's what I get with the debug on win7 x64:

Code:

cgminer.exe caused an Access Violation at location 0040cb39 in module cgminer.exe Reading from location 00000000.

Registers:
eax=00000000 ebx=624836d0 ecx=74e02e09 edx=006cd8f8 esi=00000000 edi=00660eb0
eip=0040cb39 esp=0d9df460 ebp=08966908 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

Call stack:
0040CB39  cgminer.exe:0040CB39
004663A0  cgminer.exe:004663A0
00459208  cgminer.exe:00459208

I can reproduce this on demand.  Just point it to ozcoin:3333, let it run a min or two, then unplug the ethernet cable.  I'm going to see if Visual Studio debugger can give me anything more useful.

M

[kano]

i had to add the following to /etc/udev/rules.d/90-ztex.rules

SUBSYSTEM=="usb", ATTR{idVendor}=="221a", ATTR{idProduct}=="0100", MODE="0660", GROUP="plugdev"

that enables you to run cgminer without beeing root with ztex devices.

Ah thanks I'll have to add something along those lines to the FPGA-README (and the soon ASIC-README )
i.e. like I added about getting linux to stay away from the MMQ

I've rewritten the MMQ code to use libusb so I've been looking a lot at the libusb stuff lately
Hopefully have it ready soon (working on tidying up resource handling - my original code ignored resource handing - to first just get it working ... but of course final code can't ignore that and it's meant re-arranging a bit ... anyway I've been running the main USB code for quite a few days now so I know it's good to go once I fix up the resource handing ... but after I do windows testing ... which I always hate doing coz there's always some code that never seems to work properly on windows ...)