Thank you!  I'll continue to use CGMiner.

--E

From reading the change log it seems that CGMiner will support Butterfly Labs Monarch's, but when I look at the Monarch specifications, it says it only supports BFGMiner.  Why is that?  I'd prefer to stay with CGMiner for my Monarch's.

Specifications are here:
  http://www.butterflylabs.com/upload/manuals/monarch_specifications_and_setup_guide.pdf

--E

How does one determine the firmware version in a Jalapeno?  Do you need a JTAG device?

--E

Anyone offering flashing service in the Los Angeles or San Jose area?  I have two Jalapeno's running at 5Ghs each.

--E

Thank you so much!

This worked like a charm for me.  I upgraded my rig from BAMT to something more modern and ran into this problem.
I'm now successfully running the following configuration with hash results as near as I can remember from before.

• AMD/ATI Radeon 5770
• Linux Kernel 3.8.0-29-generic x64 (Ubuntu)
• Catalyst 13.101 (experimental)
• AMD-APP-SDK-V2.8

-E

I've been using cgminer v3.3.0 with my ATI/Radeon 5700 successfully since 3.3.0 was released.  Recently, the cpu was pegged at 100% and the system very sluggish as a result.  I rebooted and now I can't get cgminer to startup.  If I disable-gpu, it will start, otherwise it hangs with the following messages:

    cgminer --verbose -D -T -c cgminer.conf.empty
    [2013-08-22 13:33:00] Started cgminer 3.3.0                   
    [2013-08-22 13:33:00] Loaded configuration file cgminer.conf.empty                   
    [2013-08-22 13:33:00] RES: thread starting


Additionally "./cgminer --ndevs" will hang.

The system runs linux (bamt) and the GUI looks o.k., but I'm afraid that my GPU is dying.

What else can I try?

--E

What FPGA/ASIC is used in the BlockErupter?

-E

@Envite, did you compile cgminer yourself or download it?  If you compiled yourself, can you post the output of the ./configure command?  Also, can you run 'cgminer --help' to show what version is running and what was compiled into cgminer?

--E

ASIC-README says to use the file 01-cgminer.rules, but this file is not found in the built 64bit Linux archive:  http://ck.kolivas.org/apps/cgminer/cgminer-3.2.0-x86_64-built.tar.bz2

I see I can get it from git:  https://github.com/ckolivas/cgminer/blob/master/01-cgminer.rules

But, am I missing something obvious (again) or should the file be in that archive?

-E

Let us know when it's in Armory and we can push for this to be placed into the standard bitcoin client.

--E

They all say beta.  See:  https://bitcointalk.org/index.php?topic=219504.msg2315179#msg2315179
I got the same messages with qmake.  I don't know what they mean, but it didn't seem like a problem.

-E

It seems to me the Bitcoin-qt 'Sign Message' feature is a little harder to use than it should be.  Once all of the fields are filled in, it would be more convenient to output a block of text that contains all of the information that should be pasted in to a message.  Also a simple parser that expects this format should be put into the Verify Message side of things.  For example (taken from a PGP Signed message):

-----BEGIN BITCOIN SIGNED MESSAGE-----
Address:  1Bitcoinasdfasdfsadfsadfsadf

Because anyone can claim to be me. There's no validation of the user
name or email address when someone posts a comment. While I do try to
remove imposters, some may slip through. By signing my comments using
this technique, anyone can independently verify that I was the author of
the message by validating the signature.
-----BEGIN BITCOIN SIGNATURE-----
Version: Bitcoin-qt (1.0)

iD8DBQFFxqRFCMEe9B/8oqERAqA2AJ91Tx4RziVzY4eR4Ms4MFsKAMqOoQCgg7y6e5AJIRuLUIUikjNWQIW
-----END BITCOIN SIGNATURE-----


--E

I'm getting a segmentation fault when I mine FreiCoin in the "http://pool.freico.in:9638" pool.  When I mine BitCoins or scrypt I don't see any issues.  I'm running 3.1.1 that I compiled on a 32bit Debian installation.  This is the same behavior I experienced on 3.1.0.  Hopefully I haven't missing something in the README, this time.

Here's the log:


e@miner:~/cgminer-3.1.1# ./cgminer -D -T --verbose  --config ~/.cgminer/cgminer.conf.frc
 [2013-05-21 19:43:05] Started cgminer 3.1.1
 [2013-05-21 19:43:05] Loaded configuration file /home/e/.cgminer/cgminer.conf.frc
 [2013-05-21 19:43:05] CL Platform 0 vendor: Advanced Micro Devices, Inc.
 [2013-05-21 19:43:05] CL Platform 0 name: AMD Accelerated Parallel Processing
 [2013-05-21 19:43:05] CL Platform 0 version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
 [2013-05-21 19:43:05] Platform 0 devices: 1
 [2013-05-21 19:43:05]  0       Juniper
 [2013-05-21 19:43:05] ADL Initialisation Error! Error -1!
 [2013-05-21 19:43:05] USB scan devices: checking for BAS devices
 [2013-05-21 19:43:05] BAS looking for BAS 0403:6014 but found 1d6b:0002 instead
 [2013-05-21 19:43:05] BAS looking for BAS 0403:6014 but found 1d6b:0002 instead
 [2013-05-21 19:43:05] BAS looking for BAS 0403:6014 but found 1d6b:0001 instead
 [2013-05-21 19:43:05] BAS looking for BAS 0403:6014 but found 1d6b:0001 instead
 [2013-05-21 19:43:05] BAS looking for BAS 0403:6014 but found 13fe:1d00 instead
 [2013-05-21 19:43:05] Probing for an alive pool
 [2013-05-21 19:43:05] Popping work to stage thread
 [2013-05-21 19:43:05] Testing pool http://pool.freico.in:9638
 [2013-05-21 19:43:05] Probing for GBT support
 [2013-05-21 19:43:05] JSON-RPC call failed: {
   "message": "Method not found",
   "data": null,
   "code": -32601
}
 [2013-05-21 19:43:05] Failed to connect in json_rpc_call
 [2013-05-21 19:43:05] No GBT coinbase + append support found, using getwork protocol
 [2013-05-21 19:43:05] X-Roll-Ntime expiry set to 10
 [2013-05-21 19:43:05] Successfully retrieved and deciphered work from pool 0 http://pool.freico.in:9638
 [2013-05-21 19:43:05] Pushing pooltest work to base pool
 [2013-05-21 19:43:05] Network diff set to 148K
 [2013-05-21 19:43:05] New block: 2df2b55a03d059e4... diff 148K
 [2013-05-21 19:43:05] Pushing work to getwork queue
 [2013-05-21 19:43:05] Popping work to stage thread
 [2013-05-21 19:43:05] Pool 0 http://pool.freico.in:9638 alive
 [2013-05-21 19:43:05] Long-polling activated for http://pool.freico.in:9638/long-polling
 [2013-05-21 19:43:05] X-Roll-Ntime expiry set to 10
 [2013-05-21 19:43:05] LONGPOLL from pool 0 requested work restart
 [2013-05-21 19:43:05] Work stale due to block mismatch
 [2013-05-21 19:43:05] Discarded work
 [2013-05-21 19:43:05] Discarded 1 stales that didn't match current hash
 [2013-05-21 19:43:05] Pushing rolled converted work to stage thread
 [2013-05-21 19:43:05] Pushing work from pool 0 to hash queue
 [2013-05-21 19:43:05] Successfully rolled work
 [2013-05-21 19:43:05] Successfully rolled work
 [2013-05-21 19:43:05] Pushing rolled converted work to stage thread
 [2013-05-21 19:43:05] Pushing work from pool 0 to hash queue
 [2013-05-21 19:43:05] Successfully rolled work
 [2013-05-21 19:43:05] Successfully rolled work
 [2013-05-21 19:43:05] Pushing rolled converted work to stage thread
 [2013-05-21 19:43:05] Pushing work from pool 0 to hash queue
 [2013-05-21 19:43:05] Successfully rolled work
 [2013-05-21 19:43:05] Successfully rolled work
 [2013-05-21 19:43:05] Pushing work from pool 0 to hash queue
 [2013-05-21 19:43:05] Pushing converted work to stage thread
 [2013-05-21 19:43:05] Pushing work from pool 0 to hash queue
 [2013-05-21 19:43:05] Converted longpoll data to work
 [2013-05-21 19:43:06] Pushing ping to thread 0
 [2013-05-21 19:43:06] Init GPU thread 0 GPU 0 virtual GPU 0
 [2013-05-21 19:43:06] CL Platform vendor: Advanced Micro Devices, Inc.
 [2013-05-21 19:43:06] CL Platform name: AMD Accelerated Parallel Processing
 [2013-05-21 19:43:06] CL Platform version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
 [2013-05-21 19:43:06] List of devices:
 [2013-05-21 19:43:06]  0       Juniper
 [2013-05-21 19:43:06] Selected 0: Juniper
 [2013-05-21 19:43:06] Preferred vector width reported 4
 [2013-05-21 19:43:06] Max work group size reported 256
 [2013-05-21 19:43:06] Max mem alloc size is 134217728
 [2013-05-21 19:43:06] Loaded binary image phatk121016Juniperv2w128l4.bin
 [2013-05-21 19:43:06] Initialising kernel phatk121016.cl with bitalign, 2 vectors and worksize 128
 [2013-05-21 19:43:06] initCl() finished. Found Juniper
 [2013-05-21 19:43:06] Pushing ping to thread 1
 [2013-05-21 19:43:06] Init GPU thread 1 GPU 0 virtual GPU 0
 [2013-05-21 19:43:06] CL Platform vendor: Advanced Micro Devices, Inc.
 [2013-05-21 19:43:06] CL Platform name: AMD Accelerated Parallel Processing
 [2013-05-21 19:43:06] CL Platform version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
 [2013-05-21 19:43:06] List of devices:
 [2013-05-21 19:43:06]  0       Juniper
 [2013-05-21 19:43:06] Selected 0: Juniper
 [2013-05-21 19:43:06] Popping ping in miner thread
 [2013-05-21 19:43:06] Popping work from get queue to get work
 [2013-05-21 19:43:06] Got work from get queue to get work for thread 0
 [2013-05-21 19:43:08] [thread 0: 268435456 hashes, 220189.5 khash/sec]
Segmentation fault


Here's the config file:
{
"pools" : [
        {
                "url" : "http://pool.freico.in:9638",
                "user" : "1...",
                "pass" : "x"
        }
]
,
"intensity" : "12",
"vectors" : "2",
"worksize" : "128",
"kernel" : "phatk",
"lookup-gap" : "0",
"thread-concurrency" : "0",
"shaders" : "0",
"gpu-engine" : "0-0",
"gpu-fan" : "0-0",
"gpu-memclock" : "0",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "0",
"temp-target" : "0",
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "2",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "60",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

Let me know if this is unsupported, but I think I found a bug (or my misunderstanding of the capabilities) in cgminer.  I'm running cgminer on BAMT with a GPU mining bitcoins and everything works just fine 24/7. 

I wanted to check out some FreiCoin (sha256d), so I added a second pool to my list of pools in cgminer.conf and then set rotate to 5 minutes.  My expectation is that every five minutes I would alternate between mining BitCoins and FreiCoins.  Everything seemed to work the first day, but the second day the BitCoin pool had some connection problems (stratum connection interrupted) and it kept switching between the pools.  Unfortunately it seemed that it would submit BitCoin work to the FreiCoin pool and vice-versa.  I got quite a few strange errors, including 'H not zero' replies from the pools.  Sorry, I don't have a good log right now.

Is this supposed to work?  Is there a better way to achieve this goal of mining two types of coins on the same hardware?

-E

P.S.  Thanks for the great software.

I'm interested in 1.  What's the price of 1 with shipping?

--E

Yes, the guide worked great.  Now I'm trying to use a Wireless PCI card and can't figure out where to start.

I can see wlan0 in 'iwconfig', but I don't see any GUI in the System Tray or Menu to set the SSID/key.  I can change /etc/network/interfaces, but that gets overwritten each boot because this is a live USB.

Any suggestions?

--E

How to 'reset your blockchain' in Bitcoin-qt v0.8.0.0?

From advice here:  http://code.google.com/p/bitcoin-wallet/wiki/UnstickLowFeeTransactions

I'd like to reset my blockchain....how?

--E

How to 'reset your blockchain' in Bitcoin-qt v0.8.0.0?

From advice here:  http://code.google.com/p/bitcoin-wallet/wiki/UnstickLowFeeTransactions

I'd like to reset my blockchain....how?

--E

Just to confirm my own code changes...Are you logging the ip from the 'inv' or the 'tx' message?  I originally logged the 'tx', but realized that the 'inv' message comes first.

--E

I can easily get 400 connections with a simple setup and some minor code changes.  How many people would need to have the same setup and then pool the data to have 90% confidence that they know the ip address of the initial transaction?  Is that even possible?

Suppose there were 'n' computers with this setup, each with ~400 connections that log the time they first see a transaction.  The one 'n' computer that saw the transaction first would most likely know the originating ip.

Alternatively, Could/Would you have to map out the network (i.e. know who is connected to whom) to figure it out?

I agree that once a client has 8 connections it won't connect again, but I believe that disconnections are fairly common.  Just check the 'debug.log' file in your bitcoin client data directory and look for 'disconnecting node'.

--E