3

I am using geth 1.4.18-stable-c72f5459 on Win7.

I am starting my nodes with the following parameters:

geth.exe --datadir \work\eth\miner2 --nat none --nodiscover --networkid 1999 --mine --port 30304 --ipcpath miner2.ipc

After syncing with the other miner node on the same machine, the second miner crashes when it starts mining itself.

My best guess so far is that the two instances have a collision in AppData\Roaming\Ethash where the DAG is stored. I was looking for an option to pass a different location to geth, but it looks like this path is hard-coded.

panic: ethash_full_new IO or memory error

goroutine 387 [running]:
panic(0xbce660, 0xc0431f4b80)
        /usr/local/go/src/runtime/panic.go:500 +0x1af
github.com/ethereum/ethash.(*dag).generate.func1()
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:273 +0x695
sync.(*Once).Do(0xc0433b5860, 0xc043433bd0)
        /usr/local/go/src/sync/once.go:44 +0xe2
github.com/ethereum/ethash.(*dag).generate(0xc0433b5840)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:277 +0x53
github.com/ethereum/ethash.(*Full).getDAG(0xc0421de330, 0xa3, 0xc04343fc80)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:333 +0xa7
github.com/ethereum/ethash.(*Full).Search(0xc0421de330, 0x127d300, 0xc043438900, 0xc04349e240, 0x0, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:338 +0x7b
github.com/ethereum/go-ethereum/miner.(*CpuAgent).mine(0xc0433c3720, 0xc0433ac340, 0xc04349e240)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/agent.go:121 +0x13a
created by github.com/ethereum/go-ethereum/miner.(*CpuAgent).update
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/agent.go:90 +0x15a
1

as you 've guesed the problem comes from the DAG.

I think the geth instances are generating two DAG at the same time. so you could disable it by running geth --autodag=false or geth makedag 0 /ethdata/

  • 2
    note that --autodag=false does not work. Run geth with this parameter and you will still see the message Automatic pregeneration of ethash DAG ON. – Bokky WeAreAllAssange PooBah Oct 31 '16 at 0:05
1

I had same issue in my Remote Windows Azure VM

I solved it by

1) Checking for the geth bit (32/64 ) I had system of 64bit and ran geth of 32bit and hence faced this issue.

2) Checking for the Storage size I had a Azure VM whose internal memory/RAM size was just 3.5GB and which is not sufficient for DAG generated and stored.

1

--autodag=false doesn't work, because as soon as the miner is startet, automatic pregeneration is turned on. This also happens if I call miner.stopAutoDAG() via the console.

The problem seems to be that the second miner can not read the DAG file because the first miner is holding a lock on it. Via shell I tried to call md5sum on the DAG file while the first miner was running and I got md5sum: can't open 'full-R23-0000000000000000': Device or resource busy.

The only solution that worked for me so far is to start the second miner with a different Windows account.

0

After running 64bit geth it works fine. My windows is also 64bit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.