Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 606. (Read 5806103 times)

In case anyone else runs into a similar situation...

I was wondering how to put multiple scan-serial command line arguments (for my icarus boards) into the cgminer config files so that I could stop including them on the command line.  After some experimentation, it seems the right way to do this is to use JSON array syntax to indicate the multiple values.  For example, here is a sample config file for my icarus devices (the line with scan-serial in it is the relevant line):

Code gets sent to git pull requests

We will try, mommy.

I'll be away for ~10 days. Behave while I'm away kids.

A few things ...

I'm wary of any code that includes "not sure if"

I guess I'll look at that windows stuff if I ever get around to fixing my windows compile and read up on the details of SetupComm, SetCommConfig and PurgeComm
... and find out what problems that PurgeComm could cause ...

As for the linux code:

Yes it is supposed to be a DEBUG, it is not an ERR.
I happens every time a work request doesn't have a share within the 'total' timeout
I changed it way back to DEBUG since it was originally a WARNING (always displayed).

Your read will write off the end of the buffer when there are more than 4 bytes available ...

My suggestion Post ideas, not code ...

The driver simply did not configure my 6970s at all so I had to manually add them. It was a basic blank configuration so all I had to do was find out what pci bus number they were and add them:

Changed:
Section "ServerLayout"
        Identifier     "aticonfig Layout"
        Screen      0  "aticonfig-Screen[0]-0" 0 0

to also have:
        Screen         "aticonfig-Screen[1]-0" RightOf "aticonfig-Screen[0]-0"
        Screen         "aticonfig-Screen[2]-0" RightOf "aticonfig-Screen[1]-0"
etc..


Changed
Section "Monitor"
        Identifier   "aticonfig-Monitor[0]-0"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"
EndSection

to have extra entries of:
Section "Monitor"
        Identifier   "aticonfig-Monitor[1]-0"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"
EndSection
etc...

Changed
Section "Device"
        Identifier  "aticonfig-Device[0]-0"
        Driver      "fglrx"
        BusID       "PCI:1:0:0"
EndSection

to have extra entries of:
Section "Device"
        Identifier  "aticonfig-Device[1]-0"
        Driver      "fglrx"
        BusID       "PCI:6:0:0"
EndSection
etc...

Note I manually figured out what PCI bus numbers to put in based on the output of:
lspci  | grep VGA
which reads:
01:00.0 VGA compatible controller: ATI Technologies Inc Device 6798
06:00.0 VGA compatible controller: ATI Technologies Inc Device 6718
07:00.0 VGA compatible controller: ATI Technologies Inc Device 6718
etc.

And finally
Section "Screen"
        Identifier "aticonfig-Screen[0]-0"
        Device     "aticonfig-Device[0]-0"
        Monitor    "aticonfig-Monitor[0]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

had extra entries of:

Section "Screen"
        Identifier "aticonfig-Screen[1]-0"
        Device     "aticonfig-Device[1]-0"
        Monitor    "aticonfig-Monitor[1]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection
etc..

So yeah not exactly a straight forward operation. It's supposed to work automatically with the command:
aticonfig --adapter=all --initial -f

but it didn't...

What is the specific changes needed in the xorg.conf file? Is there a link or resource somewhere?

TIA

Here is a link to the driver - kinda hard to find...

http://www2.ati.com/DRIVERS/hotfix/radeon_7900_series/amd-driver-installer-8.921-x86.x86_64.run

thx

This has been discussed before ...

cgminer will load the default cgminer.conf (if it finds it) no matter what you specify on the command line ... then it also does what you say on the command line.

The software should compile with osx. But since no one who uses osx is willing to compile it regularly and help me debug minor issues as they arise with osx, I can't tell you if it compiles or not. The software IS cross platform, but with no users what is there to say? The number of people building on osx is basically zero now. Mining on osx is expensive an inefficient; the hashrate is never as good as win/linux.

why in title contained osx ...? please delete or give answer how did it)))

Well, the windows side seems to have a collection of issues it would seem caused by windows and the windows USB driver.
I've not tried windows with my git code (as I mentioned above)

However, I'd again suspect it is the USB driver that is causing the problems (but as usual I could be wrong)
The reason is that the basic USB code is the same for BFL and Icarus.
The difference between them is the USB driver.

The cgminer code differences between BLF and Icarus are of course how you process work on each (and my changes I've done for Icarus)
But the basic I/O is the same.

If the code is seeing 2 COM ports then you need to look at the USB device list in device manager and see if that is OK or not.
Is anyone else using Icarus on Windows?
On seconds thoughts ... I should point out the obvious before assuming the complex ...
My guess is you are asking for COM5 twice.
Probably: once on the command line and again in cgminer.conf ...
(or twice in one or other of those?)

Edit: As for clearing the buffer, I might try that with the new golden_ob - however, the issue with doing anything is how long it takes.
If it takes a few seconds then that is no good.
Even 1/10 of a second can be painful if there is other initialisation related to it:
e.g. Xiangfu has a setup with 41 Icarus and then suddenly it becomes minutes to start cgminer if each device is a couple of seconds to setup, and that of course is no good.
A hack/workaround to resolve something that is caused outside cgminer's control that can also be resolved by the cause, is a last resort, not an early consideration.

I think you can add something like /noserialmice to boot.ini in WindowsXP to prevent that.  I don't remember if that is the right switch, but if you have XP, find the switches and you may solve the problem (not that flushing / clearing the buffer would be a bad thing to do in case something other than a Windows boot-up caused such a condition).  However, I wonder if doing this in cgminer could cause two mining applications to fight over the device.

On a related note, how does cgminer react when an FPGA device (Icarus, Single, etc.) unexpectedly 'goes away' (due to USB cable coming loose, for example)? Does it wait for the device to re-appear and starts mining again? Does it quit? Does it do something else?

I ask because I've read elsewhere that the Ufasoft miner supports 'hot plugging' (at least for FPGAs; not sure about GPUs). That is you can attach, disconnect, and re-attach devices and Ufasoft will automatically add them to the mining chain as they come available (and removing them when they detach). It does this automatically without any user intervention. Seems like a very elegant (and useful) feature.

Just wondering if cgminer has similar behavior. I don't have an FPGA yet to test with. Does anyone have any experience with this?

That's embarrassing lol

Thanks

No, each card shows up as only one ICA device.  If you are seeing two and only actually have one, I think something is wrong with the auto-detection. 

Upgrade your Windows.  GetLogicalProcessorInformation isn't available until Windows XP SP3. 

I have been using CGMiner for almost 9  months now, no problems whatsoever.

Moved 2 miners to a different Windows XP-32 bit pc and all of a sudden it won't work anymore....

It's a 5830 and a 6770

I get the following windows-error when I run CGMiner or CGMiner -n:

"The procedure entry point GetLogicalProcessorInformation could not be located in the dynamic link library KERNEL32.dll"

Any advice ? Have un-re-installed both drivers and OpenCL/SDK

Brat

Careful, you might just actually miss the important change ... ...
(and Xiangfu re-wrote it based on an early version of bitforce.c - I just helped with a few bugs - Con didn't write that code)

My git aborts the job if it detects an LP
The reason for setting the timeout to 0.1 seconds is coz that's the minimum value with the current code.
That means it will waste at most 0.1 seconds of processing, not 1 second, before aborting due to an LP.

Look at all the changes when you do a diff and post about it please.

Edit: the line is
No, changing it to 10 seconds wont help.

That most likely means that the data sent wasn't correct, thus got messed up in the transfer somehow (driver? settings?)

Also, I've found a 'golden_ob' that takes less than 1ms that I'm going to change it to soon
(once I successfully determine the golden_ob value correctly )