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

[jamesg]

lodcrappo,

Would BAMT somehow keep ftdi_sio from writing new devices it finds to the /dev folder?

Thanks,
gigavps

[jamesg]

lodcrappo,

Would BAMT somehow keep ftdi_sio from writing new devices it finds to the /dev folder?

Thanks,
gigavps

Upon further inspection of BAMT, it looks like the kernel mod ftdi_sio does not exist. According to luke-jr, this kmod is needed to allow the kernel to write /dev/ttyUSB* files when new USB devices are found.

[guinness]

I've had a problem using ssh on OSX to monitor miners. No problem with puTTY on Windoze. Go figure. The following allows ssh access to gpumon from OSX ( 10.6.8 ) ssh.

ssh -l root@<your_ip>
password: <your_user_password>
chmod uog+rw /dev/ati/card*
xauth merge /home/user/.Xauthority
export DISPLAY=:0
aticonfig --odgc --adapter=all

[gnar1ta$]

I've had a problem using ssh on OSX to monitor miners. No problem with puTTY on Windoze. Go figure. The following allows ssh access to gpumon from OSX (10.6. ssh.

ssh -X user@<your_ip>
password: <your_user_password>
sudo su
chmod uog+rw /dev/ati/card*
xauth merge /home/user/.Xauthority
export DISPLAY=:0
aticonfig --odgc --adapter=all

Wierd, I've always been using OSX and have had an issue the last week with a rig not mining and seg faulting.  I resolved it last night with something similiar, but I have not seen the error before that and have been using BAMT for quite some time.

[guinness]

I've had a problem using ssh on OSX to monitor miners. No problem with puTTY on Windoze. Go figure. The following allows ssh access to gpumon from OSX (10.6. ssh.

ssh -X user@<your_ip>
password: <your_user_password>
sudo su
chmod uog+rw /dev/ati/card*
xauth merge /home/user/.Xauthority
export DISPLAY=:0
aticonfig --odgc --adapter=all

Wierd, I've always been using OSX and have had an issue the last week with a rig not mining and seg faulting.  I resolved it last night with something similiar, but I have not seen the error before that and have been using BAMT for quite some time.

I have no problem with the 0.4 miners, just the one I've upgraded to 0.5b as a test.

[lodcrappo]

So I am trying this out, and at least one of the machines will just randomly reboot.

I don't mean it crashes and then does a hard reboot - the system does a graceful reboot and the console gives the System going down now, reboot message.  What gives?  Why is it doing this?  It's kind of annoying.

I don't think any machine should ever reboot on it's own unless explicitly set to do so, which I have not done.  how do I prevent it from doing this?

This happens when one of your GPUs locks up (almost always due to too much overclocking)

you can disable the recovery reboot by setting

  detect_defunct: 0

in settings section of bamt.conf

This is documented in the example bamt.conf and https://bitcointalk.org/index.php?topic=28967.msg755770#msg755770

However, this will just let your machine sit there with a locked up GPU.

Better to stop making your machine lock up in the first place.  Reduce overclocking.


PS - Generally I agree with you that machines should not reboot themselves.
However, after so many people using BAMT have locked up their machines over and over
and refuse to fix their overclocking, it seems the best approach to reduce complaints.

[lodcrappo]

lodcrappo,

Would BAMT somehow keep ftdi_sio from writing new devices it finds to the /dev folder?

Thanks,
gigavps

Upon further inspection of BAMT, it looks like the kernel mod ftdi_sio does not exist. According to luke-jr, this kmod is needed to allow the kernel to write /dev/ttyUSB* files when new USB devices are found.

bamt does include ftdi_sio

ls /lib/modules/2.6.32-5-686/kernel/drivers/usb/serial

aircable.ko    digi_acceleport.ko  io_ti.ko        kl5kusb105.ko  omninet.ko      siemens_mpi.ko       usb_wwan.ko
ark3116.ko     empeg.ko            ipaq.ko         kobil_sct.ko   opticon.ko      sierra.ko            visor.ko
belkin_sa.ko  ftdi_sio.ko         ipw.ko          mct_u232.ko    option.ko       spcp8x5.ko           whiteheat.ko
ch341.ko       funsoft.ko          ir-usb.ko       mos7720.ko     oti6858.ko      symbolserial.ko
cp210x.ko      garmin_gps.ko       iuu_phoenix.ko  mos7840.ko     pl2303.ko       ti_usb_3410_5052.ko
cyberjack.ko   hp4x.ko             keyspan.ko      moto_modem.ko  qcserial.ko     usb_debug.ko
cypress_m8.ko  io_edgeport.ko      keyspan_pda.ko  navman.ko      safe_serial.ko  usbserial.ko

[lodcrappo]

I've had a problem using ssh on OSX to monitor miners. No problem with puTTY on Windoze. Go figure. The following allows ssh access to gpumon from OSX (10.6. ssh.

ssh -X user@<your_ip>
password: <your_user_password>
sudo su
chmod uog+rw /dev/ati/card*
xauth merge /home/user/.Xauthority
export DISPLAY=:0
aticonfig --odgc --adapter=all

Wierd, I've always been using OSX and have had an issue the last week with a rig not mining and seg faulting.  I resolved it last night with something similiar, but I have not seen the error before that and have been using BAMT for quite some time.

I have no problem with the 0.4 miners, just the one I've upgraded to 0.5b as a test.

ssh as root, and you should not need to do any of that.

[guinness]

That was in a root session. Like I said puTTY had no problem.

[DeathAndTaxes]

That was in a root session. Like I said puTTY had no problem.

How is this a root session?

Code:

ssh -X user@<your_ip>
password: <your_user_password>
sudo su

This is a root session.  

Code:

ssh -x root@192.168.0.181
passwrod: root password
there is no sudo su because you are root.

[guinness]

Yes D&T you are correct. edited.

[Inaba]

So I am trying this out, and at least one of the machines will just randomly reboot.

I don't mean it crashes and then does a hard reboot - the system does a graceful reboot and the console gives the System going down now, reboot message.  What gives?  Why is it doing this?  It's kind of annoying.

I don't think any machine should ever reboot on it's own unless explicitly set to do so, which I have not done.  how do I prevent it from doing this?

This happens when one of your GPUs locks up (almost always due to too much overclocking)

you can disable the recovery reboot by setting

  detect_defunct: 0

in settings section of bamt.conf

This is documented in the example bamt.conf and https://bitcointalk.org/index.php?topic=28967.msg755770#msg755770

However, this will just let your machine sit there with a locked up GPU.

Better to stop making your machine lock up in the first place.  Reduce overclocking.


PS - Generally I agree with you that machines should not reboot themselves.
However, after so many people using BAMT have locked up their machines over and over
and refuse to fix their overclocking, it seems the best approach to reduce complaints.

I was coming to that conclusion as well and planned on testing it tonight.  Good deal... although I would suggest either a broadcast warning message that explains WHY it's rebooting, possibly a log file containing that info written to persistent storage, and possibly I would say disable it by default and make a note in the config file on enabling it. 

In my case, it would have been better for the machine to lock up, since I have no idea which GPU locked up and needs fixin' ... if it was locked up, at least then I could see which GPU caused the error.

[lodcrappo]

So I am trying this out, and at least one of the machines will just randomly reboot.

I don't mean it crashes and then does a hard reboot - the system does a graceful reboot and the console gives the System going down now, reboot message.  What gives?  Why is it doing this?  It's kind of annoying.

I don't think any machine should ever reboot on it's own unless explicitly set to do so, which I have not done.  how do I prevent it from doing this?

This happens when one of your GPUs locks up (almost always due to too much overclocking)

you can disable the recovery reboot by setting

  detect_defunct: 0

in settings section of bamt.conf

This is documented in the example bamt.conf and https://bitcointalk.org/index.php?topic=28967.msg755770#msg755770

However, this will just let your machine sit there with a locked up GPU.

Better to stop making your machine lock up in the first place.  Reduce overclocking.


PS - Generally I agree with you that machines should not reboot themselves.
However, after so many people using BAMT have locked up their machines over and over
and refuse to fix their overclocking, it seems the best approach to reduce complaints.

I was coming to that conclusion as well and planned on testing it tonight.  Good deal... although I would suggest either a broadcast warning message that explains WHY it's rebooting, possibly a log file containing that info written to persistent storage, and possibly I would say disable it by default and make a note in the config file on enabling it. 

In my case, it would have been better for the machine to lock up, since I have no idea which GPU locked up and needs fixin' ... if it was locked up, at least then I could see which GPU caused the error.

You will find in

/live/image/BAMT/CONTROL/ACTIVE/ 

some files that disable overclocking and explain when/why, if bamt could determine which GPU caused the trouble.
sometimes it cannot.

[lodcrappo]

To try and deal with the crazy mess that forum threads seem to lead to, we are going to use a dedicated site for bug tracking and support or feature requests.

http://bamter.org/redmine/projects/bamt

This is also where I will announce new versions, new fixes, and other things that might matter to BAMT users.

I think it will be much more organized than we have been in the past.

[Red Emerald]

Wow. I wish I had switched to using BAMT earlier. It's awesome.

[BitMinerN8]

Wow. I wish I had switched to using BAMT earlier. It's awesome.

Yeah, once it's setup it just works. I've had a couple rigs go several weeks now without issue.

Remember to donate to keep development going. 

[jamesg]

BAMT + cgminer is now working with the BFL single!!!!     

Thanks for lodcrappo for putting up with my linux n00b bull poopy and helping me to get this figured out.

Looks like he made a new fix for 0.5 that takes care of this for all the fellow BAMTer's!

Thanks again lodcrappo!!!

P.S. gpumon and mgpumon do not show any stats on the single.

[tnkflx]

How can I set a static ip addres?

[jamesg]

How can I set a static ip addres?

Use your router to set a static ip for the mac address.

[tnkflx]

How can I set a static ip addres?

Use your router to set a static ip for the mac address.

Is that the only way? I thought it was possible to set a static ip address in BAMT 0.5?