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

[boozer]

I made some syntax mistake in the bamt.conf file and the gpumon doesn't start (I get that funny error message), so I wanted to edit the file at etc/bamt/bamt.conf but.. why do I have writing permission disabled? I'm logged as a root and did not change any permissions, only thing I did was set a password. Any ideas?

I had the Live/Image locked as read only for some reason once too... That it readable by windows, so I plugged it into windows and deleted the file I needed to and then it was mount read-write next time I booted BAMT... However, since you want to edit the /etc/bamt/bamt.conf, Windows wont e able to read that... in that case, here are some things to try... might not be the best answer, but would give you something to do until someone else answers... I assuming you are using a USB drive?  If so:

Do you have another box running BAMT?  If so, you can stick the USB drive in there and try to edit the file....
If not, do you have a spare USB drive?  If so, you can load another BAMT default image on it to boot the computer, then stick your other drive in and modify the file. 
Finally, a more complicated way if you only have one rig and one USB drive.... you could download vmware player (free) and load some small version of linux on it (I used Puppy slackware since its pretty small), and plug the usb drive into your computer and you should be able to modify it from there.

[1714954471]

1714954471

[1714954471]

1714954471

[1714954471]

1714954471

[1714954471]

1714954471

[boozer]

1 - There is no reason to attach a monitor to the rig.  Much easier to do everything via ssh.  If you aren't doing this, start and you'll be glad you did.

2 - Most of the time the monitor is detected at boot, so make sure your monitor is attached and powered on from the moment you turn the rig on for the best chance of it being detected.  But please see point #1

3 - You can tell bamt not to regenerate the xorg.conf using a control file, please see /live/image/BAMT/readme.txt 

Well, network connectivity would freeze before I could get in via ssh, or shortly after, however, I would still be able to modify things via directly connected keyboard/monitor/mouse..... i got it working now and normally use ssh, it just tough for me sometimes via SSH when I'm testing overclocking... Thanks for the info!

[abracadabra]

I made some syntax mistake in the bamt.conf file and the gpumon doesn't start (I get that funny error message), so I wanted to edit the file at etc/bamt/bamt.conf but.. why do I have writing permission disabled? I'm logged as a root and did not change any permissions, only thing I did was set a password. Any ideas?

I had the Live/Image locked as read only for some reason once too... That it readable by windows, so I plugged it into windows and deleted the file I needed to and then it was mount read-write next time I booted BAMT... However, since you want to edit the /etc/bamt/bamt.conf, Windows wont e able to read that... in that case, here are some things to try... might not be the best answer, but would give you something to do until someone else answers... I assuming you are using a USB drive?  If so:

Do you have another box running BAMT?  If so, you can stick the USB drive in there and try to edit the file....
If not, do you have a spare USB drive?  If so, you can load another BAMT default image on it to boot the computer, then stick your other drive in and modify the file.  
Finally, a more complicated way if you only have one rig and one USB drive.... you could download vmware player (free) and load some small version of linux on it (I used Puppy slackware since its pretty small), and plug the usb drive into your computer and you should be able to modify it from there.

You can utilize the FROM and TO directories in windows to edit/modify the bamt.conf file.

they can be found at \BAMT\CONFIG

FROM = the existing bamt.conf used on the image.
TO = the bamt.conf the image will pull to use on next mine start

\BAMT also contains 2 other useful directories.  CONTROL and STATUS.  All described in the readme.txt in the \BAMT directory.

You'll need to use an editor on windows that doesn't add a CR/LF to the end of the line, or use a hex editor.

[malevolent]

Thanks for answering.
I could access it with vi and emacs.. but when I tried with nano, it created a new file and I couldn't save it ('file doesn't exist' or sth like that msg).
When I plugged the key to my windows rig to edit it from there and saved the changes, only some of the changes are saved when bamt boots. So I'll give a try with a new key.

[boozer]

You can utilize the FROM and TO directories in windows to edit/modify the bamt.conf file.

they can be found at \BAMT\CONFIG

FROM = the existing bamt.conf used on the image.
TO = the bamt.conf the image will pull to use on next mine start

\BAMT also contains 2 other useful directories.  CONTROL and STATUS.  All described in the readme.txt in the \BAMT directory.

You'll need to use an editor on windows that doesn't add a CR/LF to the end of the line, or use a hex editor.

Ahh.... well that's handy as hell     Thanks.  Will save me a lot of time... I obviously need to read the docs more thoroughly 

[jamesg]

I have just upgraded my entire farm after testing 0.5 on 4 rigs and it seems to solve most issues cgminer was having!

Thanks lodcrappo!

[lodcrappo]

I have just upgraded my entire farm after testing 0.5 on 4 rigs and it seems to solve most issues cgminer was having!

Thanks lodcrappo!

That is good to hear.

Although I am not 100% positive about this, it seems the issues some people reported with cgminer are now resolved.

Two changes have been made:

First, we've brought cgminer up to version 2.3.1.  This version is reported to be more stable than previous versions.  

Second, I reduced the number of calls BAMT makes to the cgminer API.  It may be simply that too many calls to the API causes cgminer crashes, and that is why some people had problems with stability.   This would explain why people with more GPUs saw more trouble, since more GPUs = more calls to the API.  It would also explain why disabling the BAMT monitoring allowed cgminer to run better on an otherwise unchanged platform.  The theory seems possible, but I cannot be sure of this.

In any case, it seems BAMT 0.5c (or an earlier image with fixes through 14) is providing a stable cgminer platform.

[Intention]

I'm not sure if this was ever resolved since aside from being a Linux noob I think this kind of trailed off as far as I could follow.

None of the overclocking configurations in the bamt.conf work on my HIS 5850.  They tweak my Sapphire 5830 fine and when I used to only run the 5850 under and older version of BAMT I think it was 0.3? the settings worked correctly.

--[ Debug info for O/C on GPU 0 ]------------------------------------------------

GPU is enabled, overclocking is enabled

OC command - profile 0: DISPLAY=:0.0 /usr/local/bin/atitweak -P 0 -A 0 -e 800 -m 300 -v 1.125

Results:
Setting performance level 0 on adapter 0: engine clock 800MHz, memory clock 300MHz, core voltage 1.125VDC
ADL_Overdrive5_ODPerformanceLevels_Set failed.


OC command - profile 1: DISPLAY=:0.0 /usr/local/bin/atitweak -P 1 -A 0 -e 850 -m 300 -v 1.125

Results:
Setting performance level 1 on adapter 0: engine clock 850MHz, memory clock 300MHz, core voltage 1.125VDC
ADL_Overdrive5_ODPerformanceLevels_Set failed.


OC command - profile 2: DISPLAY=:0.0 /usr/local/bin/atitweak -P 2 -A 0 -e 900 -m 300 -v 1.125

Results:
Setting performance level 2 on adapter 0: engine clock 900MHz, memory clock 300MHz, core voltage 1.125VDC
ADL_Overdrive5_ODPerformanceLevels_Set failed.

[lodcrappo]

I'm not sure if this was ever resolved since aside from being a Linux noob I think this kind of trailed off as far as I could follow.

None of the overclocking configurations in the bamt.conf work on my HIS 5850.  They tweak my Sapphire 5830 fine and when I used to only run the 5850 under and older version of BAMT I think it was 0.3? the settings worked correctly.

--[ Debug info for O/C on GPU 0 ]------------------------------------------------

GPU is enabled, overclocking is enabled

OC command - profile 0: DISPLAY=:0.0 /usr/local/bin/atitweak -P 0 -A 0 -e 800 -m 300 -v 1.125

Results:
Setting performance level 0 on adapter 0: engine clock 800MHz, memory clock 300MHz, core voltage 1.125VDC
ADL_Overdrive5_ODPerformanceLevels_Set failed.


OC command - profile 1: DISPLAY=:0.0 /usr/local/bin/atitweak -P 1 -A 0 -e 850 -m 300 -v 1.125

Results:
Setting performance level 1 on adapter 0: engine clock 850MHz, memory clock 300MHz, core voltage 1.125VDC
ADL_Overdrive5_ODPerformanceLevels_Set failed.


OC command - profile 2: DISPLAY=:0.0 /usr/local/bin/atitweak -P 2 -A 0 -e 900 -m 300 -v 1.125

Results:
Setting performance level 2 on adapter 0: engine clock 900MHz, memory clock 300MHz, core voltage 1.125VDC
ADL_Overdrive5_ODPerformanceLevels_Set failed.

The other person with a problem like this just had bad parameters in their config.

Is there a reason you are setting voltage?  Especially why set it in all 3 profiles?  This may be the problem
You also don't need to set the GPU clock in profiles 0 and 1. 

Try removing the voltage entirely and the GPU clock except for profile 2.

[boozer]

Not a huge deal, but something I have noticed is if I make config changes through gpumon, then hit Shift-R to restart the processes... randomly it does a reboot instead (I hit shift-r, it stops the processes and says "the system is going down for reboot now" during that time).  it comes back up with the new config and it works fine... Any ideas?

[Intention]

The other person with a problem like this just had bad parameters in their config.

Is there a reason you are setting voltage?  Especially why set it in all 3 profiles?  This may be the problem
You also don't need to set the GPU clock in profiles 0 and 1. 

Try removing the voltage entirely and the GPU clock except for profile 2.

Alright so (each line is two spaces then command):
gpu0:

  # remove disabled: or set it to 0 to actually use this card..

  disabled: 0
  debug_oc: 1
  #core_speed_0: 800
  #core_speed_1: 850
  core_speed_2: 900

 # mem_speed_0: 300
 # mem_speed_1: 300
  mem_speed_2: 300

 #core_voltage_0: 1.125
 #core_voltage_1: 1.125
 #core_voltage_2: 1.125

Restarting gets:

--[ Debug info for O/C on GPU 0 ]------------------------------------------------

GPU is enabled, overclocking is enabled

OC command - profile 2: DISPLAY=:0.0 /usr/local/bin/atitweak -P 2 -A 0 -e 900 -m 300

Results:
Setting performance level 2 on adapter 0: engine clock 900MHz, memory clock 300MHz
ADL_Overdrive5_ODPerformanceLevels_Set failed.

[lodcrappo]

The other person with a problem like this just had bad parameters in their config.

Is there a reason you are setting voltage?  Especially why set it in all 3 profiles?  This may be the problem
You also don't need to set the GPU clock in profiles 0 and 1.  

Try removing the voltage entirely and the GPU clock except for profile 2.

Alright so (each line is two spaces then command):
gpu0:

  # remove disabled: or set it to 0 to actually use this card..

  disabled: 0
  debug_oc: 1
  #core_speed_0: 800
  #core_speed_1: 850
  core_speed_2: 900

 # mem_speed_0: 300
 # mem_speed_1: 300
  mem_speed_2: 300

 #core_voltage_0: 1.125
 #core_voltage_1: 1.125
 #core_voltage_2: 1.125

Restarting gets:

--[ Debug info for O/C on GPU 0 ]------------------------------------------------

GPU is enabled, overclocking is enabled

OC command - profile 2: DISPLAY=:0.0 /usr/local/bin/atitweak -P 2 -A 0 -e 900 -m 300

Results:
Setting performance level 2 on adapter 0: engine clock 900MHz, memory clock 300MHz
ADL_Overdrive5_ODPerformanceLevels_Set failed.

turn mem_speed back on for 0 and 1.   your card probably has a default speed higher than 300 in profile 1, if not 0.  that will prevent you from setting 2 to 300.  higher profile cannot have lower values than lower profile, basic rule of overclocking (some cards don't care, some do).

[malevolent]

Not a huge deal, but something I have noticed is if I make config changes through gpumon, then hit Shift-R to restart the processes... randomly it does a reboot instead (I hit shift-r, it stops the processes and says "the system is going down for reboot now" during that time).  it comes back up with the new config and it works fine... Any ideas?

Doesn't happen to me unless the OC is unstable.

[lodcrappo]

Not a huge deal, but something I have noticed is if I make config changes through gpumon, then hit Shift-R to restart the processes... randomly it does a reboot instead (I hit shift-r, it stops the processes and says "the system is going down for reboot now" during that time).  it comes back up with the new config and it works fine... Any ideas?

Doesn't happen to me unless the OC is unstable.

that would make sense.

there is only one condition which will cause an automatic system reboot: a phoenix process stuck in the DEFUNCT state.

the only way I know of to make phoenix enter the defunct state is to lock up your GPU.

when overclocking is right on the edge of stability, sometimes the very process of stopping phoenix causes the GPU to lock up.  
i was helping another user with exactly that problem yesterday (GPUs that hang when phoenix exits).  reducing overclocking made the problem go away.

maybe its the sudden drop in temperature, maybe its something with how phoenix exits, maybe something else.. but it seems to be enough to push a card teetering on the edge of a crash right on over into crazy town.

if you're seeing this only occasionally, try backing off 5mhz or so.  it will probably go away, and you might avoid having a system that locks up "for no reason" every few weeks.

[boozer]

Not a huge deal, but something I have noticed is if I make config changes through gpumon, then hit Shift-R to restart the processes... randomly it does a reboot instead (I hit shift-r, it stops the processes and says "the system is going down for reboot now" during that time).  it comes back up with the new config and it works fine... Any ideas?

Doesn't happen to me unless the OC is unstable.

that would make sense.

there is only one condition which will cause an automatic system reboot: a phoenix process stuck in the DEFUNCT state.

the only way I know of to make phoenix enter the defunct state is to lock up your GPU.

when overclocking is right on the edge of stability, sometimes the very process of stopping phoenix causes the GPU to lock up.  
i was helping another user with exactly that problem yesterday (GPUs that hang when phoenix exits).  reducing overclocking made the problem go away.

maybe its the sudden drop in temperature, maybe its something with how phoenix exits, maybe something else.. but it seems to be enough to push a card teetering on the edge of a crash right on over into crazy town.

if you're seeing this only occasionally, try backing off 5mhz or so.  it will probably go away, and you might avoid having a system that locks up "for no reason" every few weeks.

Cool, thx!  Just thought it was weird that it did it on the restart of the process.  I'll adjust the clocks and see if it keeps it from going into "crazy town" 

[boozer]

What does it mean when mother puts noGPUx in the ACTIVE directory, I found out that was the card I was having issues with... I reset it to stock speeds and a short time later it rebooted and put noGPUx in the ACTIVE directory.  I assume this is going badly for me and this core....  Especially since it happened at stock speeds.

[gnar1ta$]

That is good to hear.

Although I am not 100% positive about this, it seems the issues some people reported with cgminer are now resolved.

Two changes have been made:

First, we've brought cgminer up to version 2.3.1.  This version is reported to be more stable than previous versions.  

Second, I reduced the number of calls BAMT makes to the cgminer API.  It may be simply that too many calls to the API causes cgminer crashes, and that is why some people had problems with stability.   This would explain why people with more GPUs saw more trouble, since more GPUs = more calls to the API.  It would also explain why disabling the BAMT monitoring allowed cgminer to run better on an otherwise unchanged platform.  The theory seems possible, but I cannot be sure of this.

In any case, it seems BAMT 0.5c (or an earlier image with fixes through 14) is providing a stable cgminer platform.

I've been running 2.3.1 on a 6 card rig with BAMT .4 for 12 days with no issues, so if the amount of API calls changed from .4 to .5 that may have been the issue, otherwise it may just be 2.3.1 is more stable.

[lodcrappo]

That is good to hear.

Although I am not 100% positive about this, it seems the issues some people reported with cgminer are now resolved.

Two changes have been made:

First, we've brought cgminer up to version 2.3.1.  This version is reported to be more stable than previous versions.  

Second, I reduced the number of calls BAMT makes to the cgminer API.  It may be simply that too many calls to the API causes cgminer crashes, and that is why some people had problems with stability.   This would explain why people with more GPUs saw more trouble, since more GPUs = more calls to the API.  It would also explain why disabling the BAMT monitoring allowed cgminer to run better on an otherwise unchanged platform.  The theory seems possible, but I cannot be sure of this.

In any case, it seems BAMT 0.5c (or an earlier image with fixes through 14) is providing a stable cgminer platform.

I've been running 2.3.1 on a 6 card rig with BAMT .4 for 12 days with no issues, so if the amount of API calls changed from .4 to .5 that may have been the issue, otherwise it may just be 2.3.1 is more stable.

yeah it might just be 2.3.1 that has brought peace to the realm.  the reduction in api calls I made only yesterday, or maybe it was the day before.  anyway long past any 0.4 version.

[lodcrappo]

What does it mean when mother puts noGPUx in the ACTIVE directory, I found out that was the card I was having issues with... I reset it to stock speeds and a short time later it rebooted and put noGPUx in the ACTIVE directory.  I assume this is going badly for me and this core....  Especially since it happened at stock speeds.

yeah that is not good.  actually never heard of it happening at stock speeds.  your fan still turning and whatnot?

the presence of that file means phoenix went defunct, which means your GPU went insane as far as I know.  when the GPU stops responding, phoenix tends to become very upset.

might want to inspect that something isn't burning up on the card.  the temp sensor is not all knowing.  it only knows temp in one place.
if you have another card exhausting onto that one, it could be crazy hot in a place the sensor doesn't really read, stuff like that.

or.. could just be borken

[dmcurser]

OK I know this is problem a noob? But the configuration file that comes up at startup is that cgminer. File or do I have to set it up to use cgminer?