I wish I could help. I only have 7970s or I would try to troubleshoot it for you. With 7970s I have to upgrade the drivers and I think that's probably what's causing the issue. Have you tried using the AMD Catalyst™ 12.2 Proprietary Linux x86 Display Driver -> http://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.42&lang=English.
Topic: BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools - page 61. (Read 324169 times)
March 16, 2012, 05:40:40 PM
March 16, 2012, 05:10:30 PM
Installed BAMT 0.5c
Install amd-driver-installer-12-2-x86.x86_64.run --force
bamt.conf ->
cgminer: 1
cgminer_opts: --api-listen -I 10 -u [whatever] -p [moreso]
gpu0-3
disabled: 0
cgminer: 1
The machine has 4 x 7970
I changed your pearl script because it called with a DISPLAY= :0.0 when it should be calling DISPLAY = :0
Install amd-driver-installer-12-2-x86.x86_64.run --force
bamt.conf ->
cgminer: 1
cgminer_opts: --api-listen -I 10 -u [whatever] -p [moreso]
gpu0-3
disabled: 0
cgminer: 1
The machine has 4 x 7970
I changed your pearl script because it called with a DISPLAY= :0.0 when it should be calling DISPLAY = :0
my point is that it works correctly with :0.0 for most people. I am trying to ascertain in what situation it does not work correctly.
is this something that applies to 7970s only? perhaps because of the different driver you are using in that case?
and probably more importantly, if I change to :0, will it break things for everyone else? always tricky.
March 16, 2012, 05:07:28 PM
Installed BAMT 0.5c
Install amd-driver-installer-12-2-x86.x86_64.run --force
bamt.conf ->
cgminer: 1
cgminer_opts: --api-listen -I 10 -u [whatever] -p [moreso]
gpu0-3
disabled: 0
cgminer: 1
The machine has 4 x 7970
I changed your pearl script because it called with a DISPLAY= :0.0 when it should be calling DISPLAY = :0
Install amd-driver-installer-12-2-x86.x86_64.run --force
bamt.conf ->
cgminer: 1
cgminer_opts: --api-listen -I 10 -u [whatever] -p [moreso]
gpu0-3
disabled: 0
cgminer: 1
The machine has 4 x 7970
I changed your pearl script because it called with a DISPLAY= :0.0 when it should be calling DISPLAY = :0
March 16, 2012, 04:36:54 PM
Found the bug that caused cgminer to fail under BAMT. If you find cgminer not launching correctly you need to edit /opt/bamt/common.pl. Find the sub startCGMiner function and change the following line
$ENV{DISPLAY} = ":0.0";
to
$ENV{DISPLAY} = ":0";
$ENV{DISPLAY} = ":0.0";
to
$ENV{DISPLAY} = ":0";
What version/situation/etc does this apply to?
March 16, 2012, 04:09:50 PM
Found the bug that caused cgminer to fail under BAMT. If you find cgminer not launching correctly you need to edit /opt/bamt/common.pl. Find the sub startCGMiner function and change the following line
$ENV{DISPLAY} = ":0.0";
to
$ENV{DISPLAY} = ":0";
$ENV{DISPLAY} = ":0.0";
to
$ENV{DISPLAY} = ":0";
March 16, 2012, 02:40:33 PM
anyone have a link to 0.5c image?
there are download links for several mirrors on the download page... how can someone not find that?
Seems http://bamter.org/ was down that day was looking for another source. Trust me when i say I looked.
March 15, 2012, 12:56:31 PM
So would this be a good time to ask how much would be involved in getting BAMT to run with a 4800 series GPU? guiminer/Windows works on the same hardware, but BAMT doesn't.
BAMT's aticonfig sees the card, but clinfo does not. I can populate bamt.conf however I want, BAMT will only ever show "0 GPUs configured".
I'd love a quick fix, but I'm not prepared to sink a whole lot of time into making BAMT work on this machine.
BAMT's aticonfig sees the card, but clinfo does not. I can populate bamt.conf however I want, BAMT will only ever show "0 GPUs configured".
I'd love a quick fix, but I'm not prepared to sink a whole lot of time into making BAMT work on this machine.
i don't know what a 4800 series card needs that is different from newer cards, and I don't have any to test with here. at one time a friend of mine was using a 4850 with regular bamt, nothing special needed, but I don't recall what version.
March 15, 2012, 12:54:13 PM
So would this be a good time to ask how much would be involved in getting BAMT to run with a 4800 series GPU? guiminer/Windows works on the same hardware, but BAMT doesn't.
BAMT's aticonfig sees the card, but clinfo does not. I can populate bamt.conf however I want, BAMT will only ever show "0 GPUs configured".
I'd love a quick fix, but I'm not prepared to sink a whole lot of time into making BAMT work on this machine.
BAMT's aticonfig sees the card, but clinfo does not. I can populate bamt.conf however I want, BAMT will only ever show "0 GPUs configured".
I'd love a quick fix, but I'm not prepared to sink a whole lot of time into making BAMT work on this machine.
March 15, 2012, 11:12:21 AM
ok. anybody have a guess as to why a motherboard bios is looking at the type/contents of a partition at all? I am hesitant to change things until this is understood.
traditionally, the bios simply reads the mbr and has nothing to do with any of the partitions. why does changing the type make any difference? anybody know?
I think that question would be better directed to the maintainer or support group for SYSLINUX. As I understand it, and I probably should say nothing because I'm not well versed in this, booting is tricky. Booting from USB is much much worse. Until the kernel is loaded and gets off the ground, the very minimal (<512 bytes) mbr code is totally dependent on the BIOS for disk access, and I think most BIOSes actually provide some amount of knowledge of FAT too. This is even worse when dealing with USB, because the BIOS has to "emulate" an IDE drive (and geometry) from the USB device ("Legacy USB support"). Everything I just said also has to interact with the bootloader, in this case SYSLINUX. If any of this hodge-podge of different software layers misfires, the whole thing goes kaput. Motherboard vendors are not well-known for relentlessly pursuing and squashing bugs that don't hurt Windows.traditionally, the bios simply reads the mbr and has nothing to do with any of the partitions. why does changing the type make any difference? anybody know?
I'd actually be interested in hearing someone familiar with the workings of SYSLINUX comment on my little rant. I think I'm in the right ballpark though.
i guess the answer is "it's complicated".
i'd feel better if I understood the reasons for things here, at least in a general sense, but you're right that this forum isn't the best place to go asking for such info.
I usually just follow the Debian Live project's lead and do things the way they do, as the Debian folks tend to be much smarter than I am. They use fat16, so I probably should change back in all future images. As I recall the change to 32 didn't help the guy who asked for it anyway.
March 15, 2012, 11:03:19 AM
I'm gonna go out on a limb and guess its's a Gigabyte motherboard?
I think the gigabytes just don't boot at all. Two people recently found that older images would work on their systems but current images would not, and it seems to be because of the FAT partition being fat32 vs fat16.
Now I wonder if there are some systems that only work with fat32, and some that only work with 16, or if all works with 16 and a few don't work with 32, or what exactly the story is.
Also still don't understand why the BIOS is even looking at the partition type, but obviously it is.
This stuff is really not in my domain of experience or interest. Just want to make the image most likely to work for the biggest group and not waste a bunch of time on it.
March 15, 2012, 10:46:09 AM
I'm gonna go out on a limb and guess its's a Gigabyte motherboard?
March 15, 2012, 10:42:05 AM
ok. anybody have a guess as to why a motherboard bios is looking at the type/contents of a partition at all? I am hesitant to change things until this is understood.
traditionally, the bios simply reads the mbr and has nothing to do with any of the partitions. why does changing the type make any difference? anybody know?
I think that question would be better directed to the maintainer or support group for SYSLINUX. As I understand it, and I probably should say nothing because I'm not well versed in this, booting is tricky. Booting from USB is much much worse. Until the kernel is loaded and gets off the ground, the very minimal (<512 bytes) mbr code is totally dependent on the BIOS for disk access, and I think most BIOSes actually provide some amount of knowledge of FAT too. This is even worse when dealing with USB, because the BIOS has to "emulate" an IDE drive (and geometry) from the USB device ("Legacy USB support"). Everything I just said also has to interact with the bootloader, in this case SYSLINUX. If any of this hodge-podge of different software layers misfires, the whole thing goes kaput. Motherboard vendors are not well-known for relentlessly pursuing and squashing bugs that don't hurt Windows.traditionally, the bios simply reads the mbr and has nothing to do with any of the partitions. why does changing the type make any difference? anybody know?
I'd actually be interested in hearing someone familiar with the workings of SYSLINUX comment on my little rant. I think I'm in the right ballpark though.
March 15, 2012, 09:23:31 AM
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).
i looked through the image. the original "0.4" image used a fat16 partition, but the 0.5 uses a fat32. this was due to a request from someone who thought it would help their motherboard boot. as far as i know, it didn't make any difference.
maybe some motherboards can't deal with fat32? i don't know, but it is the only difference I can find between the two. i'll upload an image using fat16 later if someone wants to try it.
ok. anybody have a guess as to why a motherboard bios is looking at the type/contents of a partition at all? I am hesitant to change things until this is understood.
traditionally, the bios simply reads the mbr and has nothing to do with any of the partitions. why does changing the type make any difference? anybody know?
March 15, 2012, 09:19:42 AM
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).
i looked through the image. the original "0.4" image used a fat16 partition, but the 0.5 uses a fat32. this was due to a request from someone who thought it would help their motherboard boot. as far as i know, it didn't make any difference.
maybe some motherboards can't deal with fat32? i don't know, but it is the only difference I can find between the two. i'll upload an image using fat16 later if someone wants to try it.
March 15, 2012, 06:55:37 AM
anyone have a link to 0.5c image?
there are download links for several mirrors on the download page... how can someone not find that?
March 15, 2012, 04:26:46 AM
anyone have a link to 0.5c image?
March 14, 2012, 12:31:59 PM
otherboards can't deal with fat32? i don't know, but it is the only difference I can find between the two. i'll upload an image using fat16 later if someone wants to try it.
Yeah, that'd be great
March 14, 2012, 11:45:20 AM
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).
i looked through the image. the original "0.4" image used a fat16 partition, but the 0.5 uses a fat32. this was due to a request from someone who thought it would help their motherboard boot. as far as i know, it didn't make any difference.
maybe some motherboards can't deal with fat32? i don't know, but it is the only difference I can find between the two. i'll upload an image using fat16 later if someone wants to try it.
March 14, 2012, 10:11:25 AM
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).
i looked through the image. the original "0.4" image used a fat16 partition, but the 0.5 uses a fat32. this was due to a request from someone who thought it would help their motherboard boot. as far as i know, it didn't make any difference.
maybe some motherboards can't deal with fat32? i don't know, but it is the only difference I can find between the two. i'll upload an image using fat16 later if someone wants to try it.
March 14, 2012, 10:05:02 AM
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).
Jump to: