Bitcoin Forum
December 02, 2016, 10:26:11 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ... 80 »
  Print  
Author Topic: BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools  (Read 302579 times)
jamesg
VIP
Legendary
*
Offline Offline

Activity: 1330


AKA: gigavps


View Profile
February 27, 2012, 07:01:02 PM
 #141

lodcrappo,

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

Thanks,
gigavps
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480717571
Hero Member
*
Offline Offline

Posts: 1480717571

View Profile Personal Message (Offline)

Ignore
1480717571
Reply with quote  #2

1480717571
Report to moderator
jamesg
VIP
Legendary
*
Offline Offline

Activity: 1330


AKA: gigavps


View Profile
February 27, 2012, 07:28:53 PM
 #142

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
Newbie
*
Offline Offline

Activity: 20


View Profile
February 27, 2012, 08:17:11 PM
 #143

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$
Donator
Hero Member
*
Offline Offline

Activity: 756


View Profile
February 27, 2012, 08:34:13 PM
 #144

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.Cool 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.

Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.
guinness
Newbie
*
Offline Offline

Activity: 20


View Profile
February 27, 2012, 08:51:30 PM
 #145

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.Cool 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
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
February 27, 2012, 09:56:32 PM
 #146

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.



If you want to support further development of BAMT (http://bamter.org/):  1PoRYaGS56ksQmK7XXLurW3B2zwCAE8PRc
lodcrappo
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
February 27, 2012, 10:07:34 PM
 #147

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


If you want to support further development of BAMT (http://bamter.org/):  1PoRYaGS56ksQmK7XXLurW3B2zwCAE8PRc
lodcrappo
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
February 27, 2012, 10:09:26 PM
 #148

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.Cool 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.

If you want to support further development of BAMT (http://bamter.org/):  1PoRYaGS56ksQmK7XXLurW3B2zwCAE8PRc
guinness
Newbie
*
Offline Offline

Activity: 20


View Profile
February 27, 2012, 10:54:58 PM
 #149

That was in a root session. Like I said puTTY had no problem.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 27, 2012, 11:11:22 PM
 #150

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
Newbie
*
Offline Offline

Activity: 20


View Profile
February 27, 2012, 11:50:29 PM
 #151

Yes D&T you are correct. edited.
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
February 27, 2012, 11:58:56 PM
 #152

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.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
lodcrappo
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
February 28, 2012, 12:01:13 AM
 #153

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.

If you want to support further development of BAMT (http://bamter.org/):  1PoRYaGS56ksQmK7XXLurW3B2zwCAE8PRc
lodcrappo
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
February 28, 2012, 12:33:15 AM
 #154


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.


If you want to support further development of BAMT (http://bamter.org/):  1PoRYaGS56ksQmK7XXLurW3B2zwCAE8PRc
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
February 28, 2012, 01:34:31 AM
 #155

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


BitMinerN8
Hero Member
*****
Offline Offline

Activity: 626


Mining since May 2011.


View Profile
February 28, 2012, 01:54:30 AM
 #156

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.  Grin
jamesg
VIP
Legendary
*
Offline Offline

Activity: 1330


AKA: gigavps


View Profile
February 28, 2012, 07:26:32 PM
 #157

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

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
Sr. Member
****
Offline Offline

Activity: 346


View Profile
February 28, 2012, 08:11:53 PM
 #158

How can I set a static ip addres?

| Operating electrum.be & us.electrum.be |
jamesg
VIP
Legendary
*
Offline Offline

Activity: 1330


AKA: gigavps


View Profile
February 28, 2012, 08:22:52 PM
 #159

How can I set a static ip addres?

Use your router to set a static ip for the mac address.
tnkflx
Sr. Member
****
Offline Offline

Activity: 346


View Profile
February 28, 2012, 08:25:09 PM
 #160

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?

| Operating electrum.be & us.electrum.be |
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ... 80 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!