|
not used openwrt, so can't say.
If you have time and want to try it, go ahead. Otherwise go for dd-wrt, as I have the guide for that.
|
|
|
|
Half an hour so far with no problems on either machine. Going to bed soon, so I'll just lettem do their thing and report in the morning.
Following up on this, everything seems to be great. Across 11 Singles nothing has hung over night, and all measurements seem to be up to par or better. Excellent work. So, sabotage?  |
|
|
|
|
That's pretty specific.
A cron job is probably best suited for this, since all you asking you can control with the API.
|
|
|
|
The latest build seems to mess with something on one of my machines. After about 2 to 4 minutes, the temperature for "BFL 1" disappears, and it starts saying error: temperature celsius or something of the sort. It also starts saying send work reports: errunknown! It then goes down to 0 hashrate. It (seems) to always be the same Single. I'd blame the Single itself, but no previous build does this. It's also present in BFG's 2.6.1. Using Win7x64, and if it matters, the operating host's environment is 1x7970, 3x5850, and 7 BFL Singles in one prompt.
EDIT: Seems my other machine has fallen to this as well, it just took longer to happen. For this one, it's BFL 2, and it gives the same errors:
error: get result reports: OK
error: send block data reports: ERR:UNKNOWN!
error: send work reports: temperature <celsius>
error: send block data reports: temperature <celsius>
After the <celsius>, it will actually have a number that seems to be the correct temperature. But the temperature is not shown above, and it won't show any hash rate, and it's not being declared sick.
Maybe something's messed with the mutex there. Seems the 'get temp', which is on the watchdog thread, is interfering with the hashing thread. I'm sticking with 2.5.0... Have a solid 7 days non-stop operation at the moment. Those with FPGAs really have little use for scrypt in >2.6.0 I'll have a look at what Con/Kano did to the code at some point, but not soon. FAR too busy right now. |
|
|
|
I compiled 2.6.1 for Windows and I've got it running now with 2 BFL Singles.
It looks like it tries to restart now if I pull the power plug on the Singles.
It was always supposed to... missing -> attempt to reconnect. It's a little touchy if it tries to restart while the BFLs are still booting up (the first time I tried, only one of them restarted). On a second try they both restarted, though.
Not a problem. cgminer won't interfere with the single's own boot up routine. |
|
|
|
|
Looks to me like there's a rally going on and a dark wall at 8.92 is being gobbled up.
|
|
|
|
|
Hmmm, all I can say is... you need to charge your phone.
|
|
|
|
Doesn't 4 words go against the rules of having a dictionary word?
No, as it's 4 of them. No. words in dictionary * No. words in dictionary * No. words in dictionary * No. words in dictionary = big number |
|
|
|
|
Perhaps I should spray-paint it all bronze/brass/copper, hide the wires in copper pipes, and add random rivets.
Steam-punk mining.
|
|
|
|
Yes it will make a great conversation piece and a coffee warmer. Question again is does this box require the assistance of a PC to operate?
Yes. |
|
|
|
Great! well done  1)  2) Yep. When I get time I'll look into hotswap stuff. It really shouldn't be TOO difficult. As it is, when you unplug a device and plug it back in it enumerates to a different serial port. Since you start CGMiner with set ports, it'll only look at those, and so will miss the new port created when you plug the device back in. 3) I've had some over heating issues now the really hot weather has kicked in, but my router just reset. The only time I had trouble with the radio stopping was when I used the most recent firmware. Its a shame to used such a cludge like that script, but if it works... Edit: 2) Thinking about it, scanning the serial ports is very system specific. I would have to cater for other devices too in cgminer. An easier option may be just to edit the start up script cgminer.sh... If you move the DEVS='...' line to inside the while loop, then all you need to do is quit cgminer via a api command (as opposed to service restart). Next time around the loop the new serial port will be picked up by the script and used in the cmd line. You can also reduce the sleep time so it comes back up quicker. |
|
|
|
Motherboard designers are not dumb. If it's fused with a 1.5 Amp fuse, the fuse will blow before the trace burns through or the motherboard incinerates. That's precisely why the fuse is there in the first place.
Else it's pretty fucking useless fuse!  |
|
|
|
|
AAaaaaand... it came back to life.
Weird.
|
|
|
|
|
POOP!
I moved my Asus RT-N16 over to be my host as the e3000 was over heating in the hot weather.
The asus was also occasional resetting (though nowhere near as often) so decided to 'mod' it and ad a fan.
Well somewhere something went wrong and now it's bricked.
My guess is that in removing the existing heatsink I broke some of the BGAs or something.
Very annoying.
|
|
|
|
Quiet mode didn't work. Real-quiet mode did, thanks for the help. Any idea why this is happening? I'd like to be able to see the standard cgminer output. I've tried increasing the prompt defaults gradually to ridiculous sizes (extending off the display on 1920x1080 resolution) with no success. Maybe I'm misunderstanding the cause of the crash still.
Darn, but yes the displaying library pdcurses is the issue. You can try the old fashioned -T mode which is just plain text. At least you'll have some output. -T works as well, and gives me enough info to see what's going on, thanks. Enable windows error reporting (WER), if the C05 exception is in cgminer, re-compile it and create a mapfile for it. Post the WER report and your map file. WER report should tell you if exception is in one of the dlls or the cgminer exe. The offset should tell you where it crashed, unless the stack is blown...
Here's the windows error log. I submitted a pull request to attempt to fix this. It works if I overflow with CPU devices, so hopefully it will help you. Here is a (temporary) debug build of BFGMiner with the fix applied (sorry, I can't build CGMiner for Windows with OpenCL support...). Thanks for submitting the request. I tried the debug build of bfgminer you linked and it crashed as well in the same way as cgminer. For the first time I've hooked up all 6 of my BFLs to a windoze machine and it does the same. I don't have much time right now to investigate, but I will if I can. |
|
|
|
|
website back up, everything looks correct for me.
|
|
|
|
Much mangling to get the dependencies compiled, but I've got: Boost (1.50) - after a flight miniupnpc (1.6) - had to manually copy some h files. Neither 1.5 nor 1.7 worked at all OpenSSL 1.0.1c - Manged to find mipsel table entries for ./Configure and edited them to my needs. Had to disable all ASM, even though mips asm exists db-4.8.30.NC - which was actually easy! ifaddrs.h is not in my library, trying what was mentioned here: https://bitcointalk.org/?topic=573.0I got a va_args not defined in util.h - fixed by adding include stdarg.h (which I'm sure is not a good thing to do) Now I have: bitcoinrpc.cpp:116: error: reference to ‘int32_t’ is ambiguous . . . No idea how to fix that. Hope you get your version up and Running Mathew. Maybe as some point I could help. Don't have the time or knowledge now. This is really not portable at all  |
|
|
|
|
I wish it didn't depend so much on this boost crap.
I've been trying to compile it for the mipsel architecture, but I'm stopped at every turn due it using very specific (that is recent) functions , and not being written in a terribly portable way. For example, I managed to get boost 1.35 to compile, but even though it says it uses 1.37, 1.35 is not up to date enough :/
|
|
|
|
|
Yep, bad luck... all things being equal I should have hit 4 blocks.
|
|
|
|
|
Show Posts
