Topic: BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools - page 22. (Read 324169 times)

Try redoing the usb drive or using a new one.

Hi, I started up my rig again after taking the summer off.  It is mining, but munin isn't recording the data.  Is there anything I can do to fix this? Or do I have to reinstall it?

Hey hey!  easy now!

I am looking to the future.....not dying to run my 7970'a on BAMT at this second. 

I am going to transition all my 5970's to 7970's at somepoint and was just curious. 

Hugs!

Please let us know if you need any beta testers.

A new release is in the works.

Things may change, but it appears 0.6 will provide:

64 bit support (only)
bfgminer integration
amd 7xxx support
newer kernel (3.2) and more drivers for you wifi crazy bastards
better fpga support
a kinder, gentler mother

The official release date is "soon".   However, we will be holding the official release party on Wednesday regardless of actual release.  Anyone in south florida, or who wants to come to south florida on wednesday, contact me for the ultra exclusive details.

I am constantly amazed by the inability of people to do something so simple as update the SDK on a Linux machine. 

A few minutes on a search engine, and a few minutes using the shell, and you could have been using 7xxx cards months ago.

any word on release date?

daaaaamit!

a little birdie told me .6 should include 7xxx support

No, the official one does not.
But I think lodcrappo is cooking something big for the next release.

So BAMT still does not support 7970's straight outa the box? 

Glad to hear.

1150 was just a safe value one can use with 7970, (actually I use higher frequencies: 1185/1190) and the whole cgminer line in bamt.conf is just a template, you must modify it (intensity, memclock, powertune etc) according to your cards.
To be honest I only thought about 7970 cards, not 79xx series in general.

Cheers

It works. Thanks a lot.
But, by default in this modded image GPU0 enabled with frequency = 1150Mhz and this is to much for hd7950.

My rig setup:
5x Sapphire HD7950 (SKU ...01-40G)
PSU: Aerocool Strike-X 1100W
MB: Asrock 970 Extreme 4
2GB RAM
4x 1x-16x risers

Sorry for my english.

P.S. I'm seeding this torrent too.

In my practice each card is tested individually, then flash bios and after this is mounted on the rig.  I saw this error after new rig starting and maybe the problem was sticky PCE-eX1 extender. X server didn't start - waiting count and idle.

Hmm..  Yea I think the problem has been somewhat solved.  After way too long of configuration switching and trying different everythings, totally pulling my hair out, I decided to set up a workbench and test each and every card on their own.  There was a card in each of the two machines that were bunk, they would show up in linux and even mine but they did not display video on POST or anything if they were the primary card. 

Yeah, that would probably cause an Xauthority issue, no?  /facepalm

Have you thought about copying the .Xauthority file from one rig that has it to all the others that don't?

Thanks for this!  Definitely handy to know the command now, I'll save it in my notes!  It does just give me the same error again, but at least I can call the error now.


Yeah I put the start_mining_init_delay on all the boxes, it just seems like a good idea to put that there.

Interestingly, I can't connect a monitor to change the root password using the console.  When I have 5 cards on there, I can, but if I put the 6th on, there is absolutely *no* video, not even a post...  But the LED blinks, and the system boots, and I can log in via SSH but it can't merge the Xauthority.  Clearly if the thing can't light the screen up at all, that tells us something is wrong, and I'm positive it's hardware...  We're asking too much of these GD70's.  Having two identical boards, identical BIOS's, and identical settings and one will run 6 cards and the other will not?  Last night I came up with a theory: the box that can run 6 cards is running 6x 6870s, where 6x 5830s or 5850s is a no go, but 5 is.  Now that this has been brought to my brain's attention, they are not as identical as I was thinking.  Now I want to experiment with other BIOS versions, I figured if v1.6 can run 6 cards, it is the one to go with, but maybe another version can run 6x 5830s?  To be continued!

Thanks for your troubleshooting! 

Here is what happens at boot..

1 - normal linux stuff
2 - x windows config blown away
3 - ati device detection -> generate new x win config
4a - x starts in one thread
4b - mine_start starts in another thread, sleeps for start_delay
5 - X finally gets going
6 - default user logs in automatically to x session
7 - mine_start script runs xauth + to make the X server allow connections

now, in root's .bashrc there is a command: xauth merge /home/user/.Xauthority
this runs when you log in as root.  it gives root the ability to talk to the X server.

however, if you log in via ssh before step 6 completes, the .Xauthority file isn't there yet and you get no joy.
or if step 7 happens before step 5, you'll get no joy.

some USB keys are much, much slower than others.  same with cpu, etc.  having more GPUs means step 3 can take much longer.  some GPUs seem to make step 4a/5 take a really long time if no monitor is attached.  there are many variables here.  since the process splits in step 4, there isn't a strong tie between them and things can get out of order, or you can just be in a rush and logging in via ssh too soon.

the default timing works in most situations, but if it doesnt your best bet is to connect a monitor and change the root password using the console, after you can see that everything is started up.  open a root terminal and do passwd.  once you've done that, it will probably work fine.  if not, you may need to increase the startup delay, its the setting "start_mining_init_delay:" in the main section, see http://bamter.org/redmine/projects/bamt/wiki/Examples

Got it, thanks.

fix 20 is what causes this problem in the first place. It's mean to be a watchdog for when cgminer fails but on cgminer 2.6+ it actually kills cgminer instead. If you want to use the latest cgminer, you either don't apply fix 20, or use my temporary fix above if you've already applied it.