OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 198.

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: -ck on October 24, 2013, 12:26:44 AM

Quote from: lano1106 on October 24, 2013, 12:14:05 AM

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.

pazor

legendary

Activity: 966

Merit: 1000

Quote from: Askit2 on October 23, 2013, 11:48:42 PM

Quote from: pazor on October 23, 2013, 07:17:45 PM

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: lano1106 on October 24, 2013, 12:14:05 AM

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.

lano1106

member

Activity: 112

Merit: 10

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

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

Quote from: pazor on October 23, 2013, 07:17:45 PM

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.

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

Quote from: OtaconEmmerich on October 23, 2013, 08:04:47 PM

Quote from: Askit2 on October 23, 2013, 03:01:15 PM

Quote from: Trongersoll on October 23, 2013, 01:33:52 PM

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

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.....

OtaconEmmerich

full member

Activity: 235

Merit: 100

Quote from: Askit2 on October 23, 2013, 03:01:15 PM

Quote from: Trongersoll on October 23, 2013, 01:33:52 PM

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

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.

pazor

legendary

Activity: 966

Merit: 1000

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 ?

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

Quote from: kano on October 23, 2013, 05:43:14 AM

Quote from: Askit2 on October 22, 2013, 08:57:22 PM

...
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]#

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

Quote from: Trongersoll on October 23, 2013, 01:33:52 PM

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

Cpu Gpu Miner I think.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: vayvanne on October 23, 2013, 01:02:07 PM

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.

Trongersoll

hero member

Activity: 490

Merit: 501

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

vayvanne

full member

Activity: 217

Merit: 101

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Askit2 on October 22, 2013, 08:57:22 PM

...
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/

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

Quote from: kano on October 22, 2013, 05:44:28 PM

Quote from: Askit2 on October 22, 2013, 05:11:14 PM

Quote from: kano on October 21, 2013, 08:13:35 AM

...
The basics of RPi Arch setup:
http://www.kano-kun.net/?p=87

I apparently have the wrong version of arch. Well not version as much as wrong image dated file. Mine was 2013-7-22. The partition is kinda messing me up. I know I can't partition as you did with 3 partitions.

Code:

[root@alarmpi ~]# fdisk -ls

Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes, 31116288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00057540

        Device Boot         Start          End            Blocks       Id   System
/dev/mmcblk0p1          2048         186367       92160       c     W95 FAT32 (LBA)
/dev/mmcblk0p2          186368     3667967     1740800    5    Extended
/dev/mmcblk0p5          188416     3667967     1739776    83   Linux
[root@alarmpi ~]#

I think but can't be sure that /dev/mmcblk0p5 is the one I want to delete and recreate. I am a little confused by the extended and Linux partitions using the same space. It looks wrong to me to have two partitions sharing space.

Yeah I never updated that did I

I actually have one of these sitting on an SD card on an RPi next to me (switched off) that I've not got around to resizing.

p5 is inside p2
Let me think ... I'm pretty sure it is:
so you need to remember both 186368 and 188416
delete them both
create a new extended p2 from 186368 to the end
then create a new Linux partition p5 from 188416 to the end
~~then continue as before.~~ Edit: no I should say, resize2fs /dev/mmcblk0p5

Let me know how it goes then I'll add it to the blog.

It worked great. I didn't go to the end. I wanted to make a swap partition but it is incomplete. Both deleted, Recreated one at a time, extended to the calculated last sector then the Linux partition to the end of the extended partition. Restart, no FS crash, and resize2fs /dev/mmcblk0p5 seems to have worked. Shows up as 6% used on the root partition.

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: techman05 on October 22, 2013, 08:20:00 PM

what does higher resolution timeouts mean? Does that mean that cgminer has more time to work itself out if something goes wrong with a device hardware or in cgminer software?

Thanks

Whenever we wait for something in code we tell it to sleep. By default in windows, the sleep time can be accurate to only +/-15ms best case scenario (and is often worse). This may or may not be relevant depending on how critical the timing is on the device. With the experimental changes I've been able to bring it down to +/-0.1μs. Also because there are less layers of code between cgminer and the operating system now, there are less potential points of failure in the code.

techman05

hero member

Activity: 546

Merit: 500

what does higher resolution timeouts mean? Does that mean that cgminer has more time to work itself out if something goes wrong with a device hardware or in cgminer software?

Thanks

aigeezer

legendary

Activity: 1450

Merit: 1013

Cryptanalyst castrated by his government, 1952

Quote from: -ck on October 22, 2013, 06:01:45 PM

To the various windows ~~victims~~ valued testers out there, I have uploaded new experimental binaries that now use windows' own low level clocks and timers to support higher resolution timeouts and hopefully be more reliable than using mingw's wrappers. I also found a bug in the windows code while working on these. For people with timeout issues on windows, please grab one of the exes from this directory and put it into your current cgminer directory:
http://ck.kolivas.org/apps/cgminer/temp/

Trying it now. No problems in first two minutes.

Thanks for working on it!

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