BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools

[dani]

Based on what you cut and pasted, that's not what appears to be the case.

yup, you're right    i was looking into it and find it to be restarted and the counter set to zero. I just cant tell why, because the card ist underclocked, not overclocked.
Is there a logfile where i can get further informations on why it crashed?

[1714068429]

1714068429

[1714068429]

1714068429

[lodcrappo]

Based on what you cut and pasted, that's not what appears to be the case.

yup, you're right    i was looking into it and find it to be restarted and the counter set to zero. I just cant tell why, because the card ist underclocked, not overclocked.
Is there a logfile where i can get further informations on why it crashed?

underclocking will crash cards too.  you may also have a situation where your over/underclocking of card A is making card B unstable.  messing with clocks is a loser's game in many cases.  you will just have to experiment until you find what works.

[lodcrappo]

So problems continues after new unexpected power down : xauth:  error in locking authority file /root/.Xauthority
message : read-only file system
Starting mining processes...: minestart_mining: starting mining processes
..muninrm: cannot remove `/etc/munin/plugins/gpuhash_all': Read-only file system
rm: cannot remove `/etc/munin/plugins/gputemp_all': Read-only file system
rm: cannot remove `/var/lib/munin/plugin-state': Read-only file system
ln: creating symbolic link `/var/lib/munin/plugin-state/run': File exists
..GPU 0..fan 0..OC 0..GPU 1..fan 1..OC 1..GPU 2..fan 2..OC 2.

I cant reboot machine, or start mining  

usb key has died.  might work if you reflash, might not, or might work for a day or two and die again.

[lodcrappo]

Well after a few hours of messing around with this, I had to shoehorn shit all over the place to make it mine on a machine that did NOT have an AMD card which BAMT seems not to work with...

Anyway I instrumented the newer cgminer restart problem in bamt and it is indeed in the /opt/bamt/mother monitoring file. The perl parsing of ps axu output fails to detect cgminer is there and it then calls /etc/init.d/mine restart . So it is in fact bamt that is restarting cgminer, and if I edit the mother script to parse the output of ps axu differently, it does NOT continually restart cgminer. Alas I don't really know perl, but it does seem to need fixing.

If you copy this file on top of mother in /opt/bamt it shouldn't restart on you (note this is not the correct fix and will probably not restart cgminer should it actually really crash):
http://ck.kolivas.org/apps/cgminer/temp/mother

BAMT is only for AMD gpu mining.  It is not designed to work without one.

If you use the cgminer included in BAMT, you'll not have this problem.  Newer versions of cgminer are not supported at this time.  If we release an update, we will adjust mother to work with the updated version.

[-ck]

Well after a few hours of messing around with this, I had to shoehorn shit all over the place to make it mine on a machine that did NOT have an AMD card which BAMT seems not to work with...

Anyway I instrumented the newer cgminer restart problem in bamt and it is indeed in the /opt/bamt/mother monitoring file. The perl parsing of ps axu output fails to detect cgminer is there and it then calls /etc/init.d/mine restart . So it is in fact bamt that is restarting cgminer, and if I edit the mother script to parse the output of ps axu differently, it does NOT continually restart cgminer. Alas I don't really know perl, but it does seem to need fixing.

If you copy this file on top of mother in /opt/bamt it shouldn't restart on you (note this is not the correct fix and will probably not restart cgminer should it actually really crash):
http://ck.kolivas.org/apps/cgminer/temp/mother

BAMT is only for AMD gpu mining.  It is not designed to work without one.

If you use the cgminer included in BAMT, you'll not have this problem.  Newer versions of cgminer are not supported at this time.  If we release an update, we will adjust mother to work with the updated version.

I was responding to the numerous requests from people as to why bamt keeps restarting the newer versions. We know you only support older versions but that doesn't mean that everyone out there will want to stick to them. I instrumented it because cgminer kept getting blamed, and I had no care about the AMD aspect; I was just explaining why it was hard to test it on hardware I had available to try it on (all of which have nvidia GPUs).

[BitMinerN8]

Well after a few hours of messing around with this, I had to shoehorn shit all over the place to make it mine on a machine that did NOT have an AMD card which BAMT seems not to work with...

Anyway I instrumented the newer cgminer restart problem in bamt and it is indeed in the /opt/bamt/mother monitoring file. The perl parsing of ps axu output fails to detect cgminer is there and it then calls /etc/init.d/mine restart . So it is in fact bamt that is restarting cgminer, and if I edit the mother script to parse the output of ps axu differently, it does NOT continually restart cgminer. Alas I don't really know perl, but it does seem to need fixing.

If you copy this file on top of mother in /opt/bamt it shouldn't restart on you (note this is not the correct fix and will probably not restart cgminer should it actually really crash):
http://ck.kolivas.org/apps/cgminer/temp/mother

BAMT is only for AMD gpu mining.  It is not designed to work without one.

If you use the cgminer included in BAMT, you'll not have this problem.  Newer versions of cgminer are not supported at this time.  If we release an update, we will adjust mother to work with the updated version.

I was responding to the numerous requests from people as to why bamt keeps restarting the newer versions. We know you only support older versions but that doesn't mean that everyone out there will want to stick to them. I instrumented it because cgminer kept getting blamed, and I had no care about the AMD aspect; I was just explaining why it was hard to test it on hardware I had available to try it on (all of which have nvidia GPUs).

You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

[lodcrappo]

Well after a few hours of messing around with this, I had to shoehorn shit all over the place to make it mine on a machine that did NOT have an AMD card which BAMT seems not to work with...

Anyway I instrumented the newer cgminer restart problem in bamt and it is indeed in the /opt/bamt/mother monitoring file. The perl parsing of ps axu output fails to detect cgminer is there and it then calls /etc/init.d/mine restart . So it is in fact bamt that is restarting cgminer, and if I edit the mother script to parse the output of ps axu differently, it does NOT continually restart cgminer. Alas I don't really know perl, but it does seem to need fixing.

If you copy this file on top of mother in /opt/bamt it shouldn't restart on you (note this is not the correct fix and will probably not restart cgminer should it actually really crash):
http://ck.kolivas.org/apps/cgminer/temp/mother

BAMT is only for AMD gpu mining.  It is not designed to work without one.

If you use the cgminer included in BAMT, you'll not have this problem.  Newer versions of cgminer are not supported at this time.  If we release an update, we will adjust mother to work with the updated version.

I was responding to the numerous requests from people as to why bamt keeps restarting the newer versions. We know you only support older versions but that doesn't mean that everyone out there will want to stick to them. I instrumented it because cgminer kept getting blamed, and I had no care about the AMD aspect; I was just explaining why it was hard to test it on hardware I had available to try it on (all of which have nvidia GPUs).

You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

Yes, that seems to be the case.   I have heard others say that 2.5.0 works OK for them as well.  All complaints are with 2.6 as far as I know.

[kano]

...
You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

Yes, that seems to be the case.   I have heard others say that 2.5.0 works OK for them as well.  All complaints are with 2.6 as far as I know.

Then go look at it rather than calling my API buggy and trying to blame cgminer.

I think your forum name is appropriate ...

[lodcrappo]

...
You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

Yes, that seems to be the case.   I have heard others say that 2.5.0 works OK for them as well.  All complaints are with 2.6 as far as I know.

Then go look at it rather than calling my API buggy and trying to blame cgminer.

I think your forum name is appropriate ...

LOL

Are you seriously saying that cgminer hasn't been insanely buggy on nearly every release?

Do you have any idea how much of my time is wasted on cgminer bugs?  Or how many past versions of cgminer have been unusable in a remotely controlled system because simply by using the API cgminer will hang or exit?

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

[-ck]

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

Thing is I proved it is NOT DEAD. You are killing it. I instrumented a clear call to the API telling it to quit and went into mother to find out why. You call /etc/init.d/mine restart inappropriately on a running cgminer.

edit: Note I am NOT claiming bamt 0.4/0.5 was ever intended to run on 2.6.x cgminer, but it is not a failing cgminer issue.

[lodcrappo]

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

Thing is I proved it is NOT DEAD. You are killing it. I instrumented a clear call to the API telling it to quit and went into mother to find out why. You call /etc/init.d/mine restart inappropriately on a running cgminer.

I completely agree, that is the case with cgminer 2.6.0.  The function is only supposed to "restart" cgminer when cgminer has exited.  That function performs correctly with the included version of cgminer.  It does not work properly with 2.6.0

BAMT is not tested with 2.6.0, and does not support 2.6.0.  There may be additional problems as well, I could not guess.   We use the specific version of cgminer that BAMT provides because it has been tested and found stable in a large number of environments.  If you replace that with something else, all bets are off.  cgminer 2.5.0 seems to work fine, although that is based entirely on user feedback, I have not verified this myself.

[lodcrappo]

Let me add that I do apologize for suggesting that cgminer was exiting due to API use.

You've got to understand that several times in the past this has been the case.  In fact the reason we quit putting out updates with new cgminer versions is that every time we did, all sorts of problems turned up.  When 2.3f or whatever it is we use seemed to be stable, we stuck with it and suddenly the number of "BAMT problems" drastically dropped.
  
This time it is not the case, but without any information on the problem, I just assumed it was the same type of problem we've had in the past.  I know it sucks to be blamed for a problem that isn't on your end, believe me.

[kano]

...
You know what is strange though, I upgraded the stock cgminer to 2.5.0 some time ago and it has been very stable for me, (2) AMD GPU and (4) BFL on one rig. So is this issue just with 2.6.x versions I wonder?

Yes, that seems to be the case.   I have heard others say that 2.5.0 works OK for them as well.  All complaints are with 2.6 as far as I know.

Then go look at it rather than calling my API buggy and trying to blame cgminer.

I think your forum name is appropriate ...

LOL

Are you seriously saying that cgminer hasn't been insanely buggy on nearly every release?

Do you have any idea how much of my time is wasted on cgminer bugs?  Or how many past versions of cgminer have been unusable in a remotely controlled system because simply by using the API cgminer will hang or exit?

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

Yeah and he paid you 50 BTC for a crap regex that you call fix '20'

Well since you have NEVER reported any details of one of these mystical API bugs that I apparently have written so many of ...

Try doing that for once ... or is that all just total bullshit?

Only discussions I've ever had with you in IRC were
4-Feb you asking for a change that isn't really possible (though I did implement what was possible)
13-Feb discussing casper/cow issues
23-Feb discussing the risks of using a one-man supplied OS

However I will also add, software is buggy, INCLUDING yours, and pretending you are some magical unicorn who doesn't write bugs but just blame someone else is mind numbingly stupid

[lodcrappo]

LOL

Are you seriously saying that cgminer hasn't been insanely buggy on nearly every release?

Do you have any idea how much of my time is wasted on cgminer bugs?  Or how many past versions of cgminer have been unusable in a remotely controlled system because simply by using the API cgminer will hang or exit?

Case in point:  The problem we are seeing now with 2.6.0 is due to a dead cgminer function in BAMT.. a function that only exists because cgminer kept crashing for Gigavps!

Yeah and he paid you 50 BTC for a crap regex that you call fix '20'

I don't recall the exact details, but Gigavps has indeed been very generous in supporting BAMT.  Many of the features are a direct result of his donations.  I believe he would back me up in saying that I generally try to discourage him from donating so much, quite the opposite of what you seem to be suggesting.

Well since you have NEVER reported any details of one of these mystical API bugs that I apparently have written so many of ...

Try doing that for once ... or is that all just total bullshit?

I have often and repeatedly directed cgminer users to the cgminer irc channel and forum thread for assistance with problems.  I do not use cgminer myself so do not have these issues or know the details other than as a 3rd party.  I typically rely on the larger farms using BAMT for reports of issues, and I believe they have followed through and worked with you on several issues.

Only discussions I've ever had with you in IRC were
4-Feb you asking for a change that isn't really possible (though I did implement what was possible)
13-Feb discussing casper/cow issues
23-Feb discussing the risks of using a one-man supplied OS

Yes, the impression I got from those conversations was that you were against the very idea of BAMT, and generally uninterested in changing cgminer to let it do all the things Phoenix could do with BAMT.

However I will also add, software is buggy, INCLUDING yours, and pretending you are some magical unicorn who doesn't write bugs but just blame someone else is mind numbingly stupid

I must have missed where I did anything like that.  If you read through the fix descriptions to find #20, surely you noticed all the places where I specifically talked about my own bugs.  I'll freely admit I jumped to a conclusion based on past experience, and this time it was not correct.  I apologized already, and I apologize again.  

[kano]

...

Only discussions I've ever had with you in IRC were
4-Feb you asking for a change that isn't really possible (though I did implement what was possible)
13-Feb discussing casper/cow issues
23-Feb discussing the risks of using a one-man supplied OS

Yes, the impression I got from those conversations was that you were against the very idea of BAMT, and generally uninterested in changing cgminer to let it do all the things Phoenix could do with BAMT.

Oh, so the fact that I made that change based on your request, with nothing but a request and no donation, is me being generally uninterested in changing cgminer for you.

Fuck off.

However I will also add, software is buggy, INCLUDING yours, and pretending you are some magical unicorn who doesn't write bugs but just blame someone else is mind numbingly stupid

I must have missed where I did anything like that.  If you read through the fix descriptions to find #20, surely you noticed all the places where I specifically talked about my own bugs.  I'll freely admit I jumped to a conclusion based on past experience, and this time it was not correct.  I apologized already, and I apologize again.  

... and again you have repeated it - that's the point of my whole post you quoted from - what are these past API bugs that you have directly claimed to other people are there and are your excuse for accusing the API in this issue.

As you have stated

Code:

... cgminer's buggiest part is the api that gpumon uses ...

Your response is simply to excuse yourself based on never reported (by anyone) API bugs.

Meh.

[lodcrappo]

Fuck off.

Are you 12 years old? 

I made a snap judgement call in an IRC conversation with some random person, and I was wrong.

Are we done? 

If not, please clearly state what it is you want from me.  What are you trying to accomplish here? 

[-ck]

Calm down. There's no doubt there were dud cgminer releases along the way, and I tried to get bugfixes out asap. Move on, nothing more to see here.

[kano]

Fuck off.

Are you 12 years old? 

I made a snap judgement call in an IRC conversation with some random person, and I was wrong.

Are we done? 

If not, please clearly state what it is you want from me.  What are you trying to accomplish here? 

12 - yeah that would be good if I was again

Meh.

Stop replying, you just keep digging the hole deeper.

[lodcrappo]

Fuck off.

Are you 12 years old?  

I made a snap judgement call in an IRC conversation with some random person, and I was wrong.

Are we done?  

If not, please clearly state what it is you want from me.  What are you trying to accomplish here?  

12 - yeah that would be good if I was again

Meh.

Stop replying, you just keep digging the hole deeper.

I'll reply if I feel like it.

There is no hole.  There is merely a bad assumption on my part, an apology from me, and all kinds of inappropriate responses, accusations, and general douchebaggery from you.

I don't use cgminer.  My knowledge of it is limited to a few tests and feedback from users.  It is not the default miner nor the preferred miner for use with BAMT.  The limited support BAMT has for cgminer is provided basically as a favor to a few key BAMT supporters.

In the past, I've had to waste my time helping users who found cgminer would lock up or crash any time the API was accessed.
In these situations, the tell-tale sign is that cgminer works fine if you don't run gpumon (a monitoring utility that talks to cgminer via the API).

I reduced the number and frequency of calls gpumon made to the API, and users reported improved stability, but still some issues until we found version 2.3f which seemed to have the magic mix required for stable operation.  A bit later, gigavps found that 2.3f would sometimes just exit with no clear indication of why.  He was desperate for a fix, and I believe contacted you guys, posted on the cgminer forum, etc.  When no solution was forthcoming, he asked me if I could hack mother to detect that it had exited and start it back up.  So I did.

This bit of code in mother doesn't work properly with version 2.6.0.  Frankly, it was never meant to, as 2.6.0 did not exist when it was written.  It is meant to start version 2.3f if it exits (which it does).

Now... some guy comes into the IRC channel and says "I think BAMT is restarting cgminer".  I've never heard of this before.  BAMT does have code that restarts Phoenix in certain situations, but nothing that restarts cgminer - except the code that detects when cgminer just isn't running.  He then tells me it only happens when he runs gpumon.  An exact duplicate of the problems we had in older versions.  To be clear, this was bad information, as ckolivas has found this problem will happen whether or not gpumon is running.  But that isn't the information I was given.  Because his symptoms exactly matched things we've seen before, I told him it was probably the same issue we've had before.  Make sense?

I have admitted I made a bad call.  I have apologized.  I hope you can understand why and how this happened.  I have been nothing but polite with you.  Show me the same courtesy and explain yourself.  Why are you so upset about this?

[rjk]

When Kano gets a chip on his shoulder, it's almost impossible to remove and usually results in major collateral damage to anything or anyone within a large radius.
It's a shame.