Ich verwende Geth 1.4.18-stable-c72f5459 unter Win7.
Ich starte meine Knoten mit den folgenden Parametern:
geth.exe --datadir \work\eth\miner2 --nat none --nodiscover --networkid 1999 --mine --port 30304 --ipcpath miner2.ipc
Nach der Synchronisierung mit dem anderen Miner-Knoten auf demselben Computer stürzt der zweite Miner ab, wenn er selbst mit dem Mining beginnt.
Meine beste Vermutung ist bisher, dass die beiden Instanzen eine Kollision in AppData\Roaming\Ethash haben, wo der DAG gespeichert ist. Ich habe nach einer Option gesucht, um einen anderen Ort an Geth zu übergeben, aber es sieht so aus, als wäre dieser Pfad fest codiert.
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
wie Sie erraten haben, kommt das Problem von der DAG.
Ich denke, die Geth-Instanzen generieren gleichzeitig zwei DAG. Sie können es also deaktivieren, indem Sie geth --autodag=falseoder ausführengeth makedag 0 /ethdata/
Ich hatte das gleiche Problem in meiner Remote-Windows-Azure-VM
Ich habe es durch gelöst
1) Suche nach dem Geth-Bit (32/64) Ich hatte ein 64-Bit-System und ließ Geth mit 32 Bit laufen und stand daher vor diesem Problem.
2) Überprüfung der Speichergröße Ich hatte eine Azure-VM, deren interne Speicher-/RAM-Größe nur 3,5 GB betrug und die nicht ausreicht, um DAG zu generieren und zu speichern.
--autodag=falsefunktioniert nicht, denn sobald der Miner gestartet wird, wird die automatische Vorgenerierung eingeschaltet. Das passiert auch, wenn ich miner.stopAutoDAG()über die Konsole anrufe.
Das Problem scheint zu sein, dass der zweite Miner die DAG-Datei nicht lesen kann, weil der erste Miner eine Sperre darauf hält. Über die Shell habe ich versucht, md5sumdie DAG-Datei aufzurufen, während der erste Miner lief, und ich habe md5sum: can't open 'full-R23-0000000000000000': Device or resource busy.
Die einzige Lösung, die bisher für mich funktioniert hat, ist, den zweiten Miner mit einem anderen Windows-Konto zu starten.
Nach dem Ausführen von 64-Bit-Geth funktioniert es einwandfrei. Mein Windows ist auch 64bit.
Datenschutz ist ein Menschenrecht.eth
--autodag=falsedies nicht funktioniert. FührengethSie mit diesem Parameter aus und Sie werden immer noch die Nachricht sehenAutomatic pregeneration of ethash DAG ON.