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

[-ck]

Minor heads up, there is a newer version of zadig, and I have uploaded it to my website, BUT it contains the same version of the WinUSB driver so it will not change the performance or the behaviour of the drivers once they're installed/assigned.

[1713491923]

1713491923

[1713491923]

1713491923

[1713491923]

1713491923

[1713491923]

1713491923

[kano]

...
One small thing. I had raspbian some semblance of running and I could use all 17 devices I have. Granted it lasted 1 hour to 3 minutes between crashes. On arch using all the same hardware I can only detect 13. The other 4 have been put on my dvr for now.
I have hub A attatched to the lower port on raspberry pi, Hub B on hub A port 1, Hub C on hub A port 3 one port doesn't work here.
Hub D is on the upper port of the raspberry pi, Hub E was hooked up to port 1 on Hub D. I have a keyboard also hooked  to hub D. Everything hooked up to hub D works except if I add either the last hub or another jalapeno by itself it will not detect. Nothing comes up, no errors, no found devices, nothing.

I  am curious does arch have less USB devices it can handle? I don't mind as I plan on running 8 per pi but I have to buy a couple more first. So far arch seems much more stable. Less GUI but much more stable.

I'm really not sure why it wouldn't see them all.
What do lsusb and ./cgminer -n say?
Pretty much it would be best to run a ./cgminer ... options ... -T -D --verbose 2> log.log also and stick the log.log in something like
http://pastebin.com/

[vayvanne]

TeckNet USB3.0 hub, BFL Jala 7.5GH, 8 BEs, Win7 x64, got zombied BEs few times. Was ok with 3.5.1.

[Trongersoll]

This may be burried somewhere in this thread, but i haven't seen it. what does the"CG" in CGminer stand for?

[-ck]

TeckNet USB3.0 hub, BFL Jala 7.5GH, 8 BEs, Win7 x64, got zombied BEs few times. Was ok with 3.5.1.

Did you try experimental .exes in the temp directory? Some fixes there.

[Askit2]

This may be burried somewhere in this thread, but i haven't seen it. what does the"CG" in CGminer stand for?

Cpu Gpu Miner I think.

[Askit2]

...
One small thing. I had raspbian some semblance of running and I could use all 17 devices I have. Granted it lasted 1 hour to 3 minutes between crashes. On arch using all the same hardware I can only detect 13. The other 4 have been put on my dvr for now.
I have hub A attatched to the lower port on raspberry pi, Hub B on hub A port 1, Hub C on hub A port 3 one port doesn't work here.
Hub D is on the upper port of the raspberry pi, Hub E was hooked up to port 1 on Hub D. I have a keyboard also hooked  to hub D. Everything hooked up to hub D works except if I add either the last hub or another jalapeno by itself it will not detect. Nothing comes up, no errors, no found devices, nothing.

I  am curious does arch have less USB devices it can handle? I don't mind as I plan on running 8 per pi but I have to buy a couple more first. So far arch seems much more stable. Less GUI but much more stable.

I'm really not sure why it wouldn't see them all.
What do lsusb and ./cgminer -n say?
Pretty much it would be best to run a ./cgminer ... options ... -T -D --verbose 2> log.log also and stick the log.log in something like
http://pastebin.com/

It figures now they work. I didn't change anything so I can't figure out why. Actually I did update Arch. Maybe that helped.

Code:

[root@cgminerPi1 ~]# lsusb
Bus 001 Device 022: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 021: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 020: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 011: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 019: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 018: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 017: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 016: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 010: ID 05e3:0612 Genesys Logic, Inc.
Bus 001 Device 015: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 014: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 013: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 012: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 009: ID 05e3:0612 Genesys Logic, Inc.
Bus 001 Device 005: ID 05e3:0612 Genesys Logic, Inc.
Bus 001 Device 027: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 026: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 025: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 024: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 023: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 008: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 007: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 001 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 004: ID 05e3:0612 Genesys Logic, Inc.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter / SMSC9512/9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[root@cgminerPi1 3.6.4]# ./cgminer -n
 [2013-10-23 15:47:10] USB all: found 27 devices - listing known devices
.USB dev 0: Bus 1 Device 22 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 1: Bus 1 Device 21 ID: 0403:6014
  Manufacturer: 'FTDI'
  Product: 'BitFORCE SHA256 SC'
.USB dev 2: Bus 1 Device 20 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 3: Bus 1 Device 19 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 4: Bus 1 Device 18 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 5: Bus 1 Device 17 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 6: Bus 1 Device 16 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 7: Bus 1 Device 15 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 8: Bus 1 Device 14 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 9: Bus 1 Device 13 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 10: Bus 1 Device 12 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 11: Bus 1 Device 27 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 12: Bus 1 Device 26 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 13: Bus 1 Device 25 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 14: Bus 1 Device 24 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 15: Bus 1 Device 8 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
.USB dev 16: Bus 1 Device 7 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
 [2013-10-23 15:47:10] 17 known USB devices
[root@cgminerPi1 3.6.4]#

[pazor]

i am running cgminer 3.6.4  with two bfl 1.2gh/s fpgas

when the pc started everything be fine. after about 10h i got

blf0: garbled response probably throttling, clearing buffer

or

bfl0: error: get temp return invalid/timed out (16: -7)

and the speed decrease

reboot solves the problem for the next 10 hours

any idea for solving ?

[OtaconEmmerich]

This may be burried somewhere in this thread, but i haven't seen it. what does the"CG" in CGminer stand for?

Cpu Gpu Miner I think.

I think it's short for Con Kolivas GPU Miner. CKGMiner doesn't quite roll of the tounge well so CGMiner.

[Askit2]

This may be burried somewhere in this thread, but i haven't seen it. what does the"CG" in CGminer stand for?

Cpu Gpu Miner I think.

I think it's short for Con Kolivas GPU Miner. CKGMiner doesn't quite roll of the tounge well so CGMiner.

I knew I should have guessed Constantly Great Miner.....

[Askit2]

i am running cgminer 3.6.4  with two bfl 1.2gh/s fpgas

when the pc started everything be fine. after about 10h i got

blf0: garbled response probably throttling, clearing buffer

or

bfl0: error: get temp return invalid/timed out (16: -7)

and the speed decrease

reboot solves the problem for the next 10 hours

any idea for solving ?

I have a question for you. What OS are you running?

I am guessing windows. Only because the BFL FPGA's gave me so many time related issues on windows and not on Linux before I traded mine in. If I am right I would still recommend a Raspberry pi, they are cheap and run Linux. Just learn arch initially not Raspbian.

[lano1106]

Con,

is your distributed version of libusbx a vanilla version from upstream known to work fine with cgminer or you have done some local modifs to it?

I am asking because the official version of cgminer from ArchLinux community repo is built with the system libs for libusbx and jansson (was also doing it as well since I need to recompile for ADL).

Version 3.6.4 and mining with 8 AM USB Eruptors, everything is extremely stable, except when I quit the application. At that point, all threads appear to be deadlocked. I have made a manual 'kill -11' to get a core. It is not very informative as the exec was stripped. I will recompile and keep symbols to get better stacks but for the moment, I am just shooting in the water in case you know right of the bat what happens:

#0  0x00007ffb0eb9e07f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x0000000000408385 in ?? ()
#2  0x00007ffb0e7e8045 in __libc_start_main () from /usr/lib/libc.so.6
#3  0x0000000000408f59 in ?? ()
(gdb) info threads
  Id   Target Id         Frame
  15   Thread 0x7ffb0d2fd700 (LWP 15595) 0x00007ffb0e8b947d in poll () from /usr/lib/libc.so.6
  14   Thread 0x7ffaed7f2700 (LWP 15617) 0x00007ffb0eba092c in __lll_lock_wait ()
   from /usr/lib/libpthread.so.0
  13   Thread 0x7ffaee7f4700 (LWP 15622) 0x00007ffb0eba092c in __lll_lock_wait ()
   from /usr/lib/libpthread.so.0
  12   Thread 0x7ffaf17fa700 (LWP 15609) 0x00007ffb0eba092c in __lll_lock_wait ()
   from /usr/lib/libpthread.so.0
  11   Thread 0x7ffaf07f8700 (LWP 15611) 0x00007ffb0eba092c in __lll_lock_wait ()
   from /usr/lib/libpthread.so.0
  10   Thread 0x7ffaf2ffd700 (LWP 15606) 0x00007ffb0eba092c in __lll_lock_wait ()
   from /usr/lib/libpthread.so.0
  9    Thread 0x7ffb057ca700 (LWP 15602) 0x00007ffb0e8bac53 in select () from /usr/lib/libc.so.6
  8    Thread 0x7ffaf1ffb700 (LWP 15608) 0x00007ffb0eba092c in __lll_lock_wait ()
   from /usr/lib/libpthread.so.0
  7    Thread 0x7ffaf27fc700 (LWP 15607) 0x00007ffb0eba092c in __lll_lock_wait ()
   from /usr/lib/libpthread.so.0
  6    Thread 0x7ffb05fcb700 (LWP 15601) 0x00007ffb0eb9e07f in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0
  5    Thread 0x7ffaeeff5700 (LWP 15614) 0x00007ffb0eb9e07f in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0
  4    Thread 0x7ffb04fc9700 (LWP 15603) 0x00007ffb0eb9e07f in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0
  3    Thread 0x7ffaf3fff700 (LWP 15604) 0x00007ffb0e8bac53 in select () from /usr/lib/libc.so.6
  2    Thread 0x7ffb0dafe700 (LWP 15594) 0x00007ffb0e8b947d in poll () from /usr/lib/libc.so.6
* 1    Thread 0x7ffb101a57c0 (LWP 15593) 0x00007ffb0eb9e07f in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /usr/lib/libpthread.so.0

[-ck]

Con,

is your distributed version of libusbx a vanilla version from upstream known to work fine with cgminer or you have done some local modifs to it?

I am asking because the official version of cgminer from ArchLinux community repo is built with the system libs for libusbx and jansson (was also doing it as well since I need to recompile for ADL).

Version 3.6.4 and mining with 8 AM USB Eruptors, everything is extremely stable, except when I quit the application. At that point, all threads appear to be deadlocked. I have made a manual 'kill -11' to get a core. It is not very informative as the exec was stripped. I will recompile and keep symbols to get better stacks but for the moment, I am just shooting in the water in case you know right of the bat what happens:

3.6.4 ONLY builds with the jansson and libusb included in cgminer (which is libusb-1.0.16-rc10, NOT libusbx). It ignores any installed libraries on your machine since it's the only way I can guarantee people are using the most stable libraries. As for it hanging on closing, it's a clusterfuck that I've never been able to completely fix due to millions of threads going wild and no clean way to shut it down with some things never returning. Blame me.

[pazor]

i am running cgminer 3.6.4  with two bfl 1.2gh/s fpgas

when the pc started everything be fine. after about 10h i got

blf0: garbled response probably throttling, clearing buffer

or

bfl0: error: get temp return invalid/timed out (16: -7)

and the speed decrease

reboot solves the problem for the next 10 hours

any idea for solving ?

I have a question for you. What OS are you running?

I am guessing windows. Only because the BFL FPGA's gave me so many time related issues on windows and not on Linux before I traded mine in. If I am right I would still recommend a Raspberry pi, they are cheap and run Linux. Just learn arch initially not Raspbian.

it is linux (debian) on a ibm t23.

[-ck]

Con,

is your distributed version of libusbx a vanilla version from upstream known to work fine with cgminer or you have done some local modifs to it?

I am asking because the official version of cgminer from ArchLinux community repo is built with the system libs for libusbx and jansson (was also doing it as well since I need to recompile for ADL).

Version 3.6.4 and mining with 8 AM USB Eruptors, everything is extremely stable, except when I quit the application. At that point, all threads appear to be deadlocked. I have made a manual 'kill -11' to get a core. It is not very informative as the exec was stripped. I will recompile and keep symbols to get better stacks but for the moment, I am just shooting in the water in case you know right of the bat what happens:

3.6.4 ONLY builds with the jansson and libusb included in cgminer (which is libusb-1.0.16-rc10, NOT libusbx). It ignores any installed libraries on your machine since it's the only way I can guarantee people are using the most stable libraries. As for it hanging on closing, it's a clusterfuck that I've never been able to completely fix due to millions of threads going wild and no clean way to shut it down with some things never returning. Blame me.

Further to this discussion, I've put a concerted effort into making shutdown and restart even more reliable, and am now unable to get it to hang on any of my own workloads on the git master tree. Please give it a go if you're building from git.

[Askit2]

I'm not sure what happened. I checked and no mining was taking place on my pools. I was worried Arch had hung on me.

Arch was still running ok on my pi. Something else went wrong. All hashing units where marked as DEAD. Still this is a great improvement over locked up Raspbian. Unfortunately I didn't have logging on so I can't get more info then copying the output to the clipboard and it would seem that it is at least an hour after it would be useful but here is what I have. I am using quotas and failover only enabled.

Code:

[root@cgminerPi1 ~]# screen -r -x cgminer
 (5s):0.000 (avg):75.42Gh/s | A:2150459  R:30463  HW:14696  WU:1047.7/m
 ST: 3  SS: 0  NB: 331  LW: 2313387  GF: 7  RF: 0
 Connected to multiple pools with block change notify
 Block: 0003b4fc27ef24fc...  Diff:268M  Started: [10:33:46]  Best share: 668K
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BAJ  0:  max 43C 3.57V | DEAD  /4.632Gh/s | A:131015 R:1470 HW:   2 WU: 64.6/m
 BAJ  1:  max 42C 3.91V | DEAD  /4.922Gh/s | A:142279 R:2149 HW:   8 WU: 68.8/m
 BAJ  2:  max 43C 3.82V | DEAD  /5.003Gh/s | A:142971 R:2087 HW:   7 WU: 69.8/m
 BAJ  3:  max 44C 3.47V | DEAD  /4.914Gh/s | A:139776 R:2058 HW:  18 WU: 68.7/m
 BAJ  4:  max 39C 4.13V | DEAD  /5.521Gh/s | A:157598 R:2280 HW:   5 WU: 77.4/m
 BAJ  5:  max 39C 3.31V | DEAD  /4.597Gh/s | A:128550 R:2002 HW:5407 WU: 61.8/m
 BAJ  6:  max 43C 3.47V | DEAD  /4.888Gh/s | A:137059 R:1983 HW:2244 WU: 67.4/m
 BAJ  7:  max 42C 3.54V | DEAD  /5.107Gh/s | A:144443 R:2096 HW:   8 WU: 71.5/m
 BAJ  8:  max 39C 3.95V | DEAD  /5.138Gh/s | A:151119 R:1945 HW:   5 WU: 71.7/m
 BAJ  9:  max 43C 2.42V | DEAD  /5.305Gh/s | A:152625 R:2218 HW:   3 WU: 74.3/m
 BAJ 10:  max 42C 3.85V | DEAD  /5.054Gh/s | A:146923 R:2257 HW:   2 WU: 70.6/m
 BAJ 11:  max 42C 3.86V | DEAD  /5.244Gh/s | A:151094 R:2196 HW:   4 WU: 73.4/m
 BAJ 12:  max 41C 3.84V | DEAD  /5.174Gh/s | A:141698 R:1875 HW:5819 WU: 69.9/m
 BAJ 13:  max 34C 3.59V | DEAD  /4.507Gh/s | A: 69622 R:1053 HW:1160 WU: 61.7/m
 BAJ 14:  max 37C 3.69V | DEAD  /4.487Gh/s | A: 65162 R: 869 HW:   1 WU: 62.7/m
 BAJ 15:  max 41C 4.09V | DEAD  /4.844Gh/s | A: 75049 R:1184 HW:   1 WU: 67.8/m
 BAJ 16:  max 38C 3.21V | DEAD  /4.747Gh/s | A: 73476 R: 709 HW:   2 WU: 66.0/m
--------------------------------------------------------------------------------
 [2013-10-23 15:39:01] Pool 2 difficulty changed to 29.213822
 [2013-10-24 09:05:08] Stratum from pool 3 detected new block
 [2013-10-24 09:05:20] Stratum from pool 0 requested work restart
 [2013-10-24 09:05:30] Stratum from pool 0 detected new block
 [2013-10-24 09:05:31] Stratum connection to pool 3 interrupted
 [2013-10-24 09:07:47] Stratum from pool 0 detected new block
 [2013-10-24 09:14:34] Stratum from pool 3 detected new block
 [2013-10-24 09:16:42] Stratum from pool 0 requested work restart
 [2013-10-24 09:18:38] Stratum from pool 3 detected new block
 [2013-10-24 09:18:43] Stratum from pool 0 requested work restart
 [2013-10-24 09:25:49] Stratum connection to pool 3 interrupted
 [2013-10-24 09:31:32] Stratum from pool 3 detected new block
 [2013-10-24 09:31:35] Stratum from pool 0 requested work restart
 [2013-10-24 09:32:21] Stratum from pool 2 detected new block
 [2013-10-24 09:34:44] Stratum from pool 3 detected new block
 [2013-10-24 09:36:43] Stratum from pool 0 requested work restart
 [2013-10-24 09:46:01] Stratum connection to pool 3 interrupted
 [2013-10-24 10:01:22] Stratum from pool 3 detected new block
 [2013-10-24 10:01:58] Stratum from pool 3 detected new block
 [2013-10-24 10:03:20] Stratum from pool 0 requested work restart
 [2013-10-24 10:06:04] Stratum connection to pool 3 interrupted
 [2013-10-24 10:06:28] Stratum from pool 3 detected new block
 [2013-10-24 10:08:28] Stratum from pool 0 requested work restart
 [2013-10-24 10:09:44] Stratum from pool 0 detected new block
 [2013-10-24 10:13:30] Stratum from pool 3 detected new block
 [2013-10-24 10:13:31] Stratum from pool 0 requested work restart
 [2013-10-24 10:26:15] Stratum connection to pool 3 interrupted
 [2013-10-24 10:26:24] Stratum from pool 0 detected new block
 [2013-10-24 10:32:12] Stratum from pool 3 detected new block
 [2013-10-24 10:33:03] Stratum from pool 0 requested work restart
 [2013-10-24 10:33:46] Stratum from pool 3 detected new block
 [2013-10-24 10:33:53] Stratum from pool 0 requested work restart
 [2013-10-24 10:46:35] Stratum connection to pool 3 interrupted
 [2013-10-24 11:06:46] Stratum connection to pool 3 interrupted

[-ck]

I'm not sure what happened. I checked and no mining was taking place on my pools. I was worried Arch had hung on me.

Arch was still running ok on my pi. Something else went wrong. All hashing units where marked as DEAD. Still this is a great improvement over locked up Raspbian. Unfortunately I didn't have logging on so I can't get more info then copying the output to the clipboard and it would seem that it is at least an hour after it would be useful but here is what I have. I am using quotas and failover only enabled.

If they all failed it looks like a major USB failure of some sort, check your kernel logs for errors.

[Askit2]

unless Arch is hiding a kernel log from root I don't see it. That or I am in the wrong place.

Code:

[root@cgminerPi1 log]# pwd
/var/log
[root@cgminerPi1 log]# dir
btmp  faillog  journal  lastlog  old  pacman.log  wtmp
[root@cgminerPi1 log]#

Journal has a file in it but I can't seem to type the alpha neumeric code correctly to open it.

[-ck]

unless Arch is hiding a kernel log from root I don't see it. That or I am in the wrong place.

Code:

[root@cgminerPi1 log]# pwd
/var/log
[root@cgminerPi1 log]# dir
btmp  faillog  journal  lastlog  old  pacman.log  wtmp
[root@cgminerPi1 log]#

Journal has a file in it but I can't seem to type the alpha neumeric code correctly to open it.

dmesg

[Askit2]

unless Arch is hiding a kernel log from root I don't see it. That or I am in the wrong place.

Code:

[root@cgminerPi1 log]# pwd
/var/log
[root@cgminerPi1 log]# dir
btmp  faillog  journal  lastlog  old  pacman.log  wtmp
[root@cgminerPi1 log]#

Journal has a file in it but I can't seem to type the alpha neumeric code correctly to open it.

dmesg

Sorry No log file. Apparently it isn't setup. I will look into that next I guess.
Restarting cgminer was all I had to do to get them running again though. It didn't seem that bad.