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

Nothing, it's a normal part of the libusb check.

Just compiled from the git running good so far no issues no zombies. I did notice during the configure step that a line popped up showing

./configure: line 11925: -pthread: command not found

seems to be working without it ,but what would i need to get to fix this part.

Raspberry Pi Raspbian Wheezy 7.

when using Zadig, do you select the winusb driver or one of the others?

I think 3.1.1 was the last version to use COM.  I was using it on my mining rigs until very recently.

Thanks for the reminder on my sig, I fixed it.  One neat thing about sigs here is it always shows your current one.

M

Unofficial Mac binaries updated to 3.4.3 at http://spaceman.ca/cgminer.

Hopefully that works.  While it doesn't prove that the issue is compatibility between your chipset and libusb, it is an easier way to narrow things down significantly and a potential workaround at the same time.

Was 3.1.1 the last version to support COM functionality?

Oh, and side note: mdude, your sig is out of date.

Linux and I don't mix well.  Last time I tried it, one of us had to go, and you see who's still here.

I intend to try 3.1.1 which uses COM drivers and see if I can get it working that way.

M

New chipsets take time to be supported in *nix (and presumably libusb originates in *nix, translating to Windows).  It's unfortunate, but a reality.  That having been said, the easiest way to confirm a problem is a chipset vs libusb problem would be to try to run the cgminer binaries off of a live distro (presumably the same OS & version in use by the developers).  If cgminer doesn't detect the device there, it's definietly due to the version of libusb included with cgminer.  Also unfortunate, many other libusb versions cause mining problems as seen earlier in this thread, so even if the developer's OS of choice can detect the device on your machine, that doesn't mean cgminer can use it and be stable.  Presumably you would have to hack and compile on your own to be able to have cgminer use a newer libusb whilst not being stable.  Beyond that, all you can do in this scenario is hope that a future version of libusb comes out that is stable for mining, which also requires hoping the developers are trying new libusb versions.  However, the live distro test would at least allow you to know that so you don't waste additional time troubleshooting.

It's a fairly recent laptop.  It has a 3rd gen i7 processor in it.  Device manager is showing the "Intel 7 series C216 chipset".

Windows knows about the USB device.  It installed the drivers just fine (via Zadig).  It shows in device manager.  But cgminer is none the wiser.

M

That's some useful information that the developers can hopefully consider in some future build.  However, if that isn't the case, I think we need to know whether or not there is any indication that the device is visible in the OS and/or powered on since, as a general rule of thumb, I would expect underpowered ports to not power on devices that require more power than is available.  Sure, there may be some mining devices could see enough power to come on, but not enough to mine without errors.  I don't know whether or not there are, but even if there are, I would expect that to be an edge case, not something typical of underpowered USB ports (unless all underpowered USB ports provide the exact same less-than-spec amount of power for some mystical reason [or they are powered to spec and "underpowered" actually means "not overpowered"]).

I had the same issue. By any chance, is it a very recent PC, with a Z87 chipset? In my case, the conclusion was that my particular chipset or USB port wasn't supported by the libusb that cgminer uses. Windows was seeing the BE fine and loading the right drivers, but they still appeared invisible to cgminer. Ultimately I had to find a different platform to mine on.

Win7 x64, just like the PCs.

I could see them being underpowered.  But cgminer doesn't see them.  It's not like it sees them and they don't work, it's like they aren't there.

M

What OS is on your laptop?

Plugging them directly into the laptop?  If so, probably the reason they arent running.  Laptop ports are notoriously under powered.

I ran into a problem with the USB block erupters.  They work great under 3.4.2 on my main PC, plugged straight into my USB 3.0 ports.  They work great on one of my rigs, plugged into multiple USB 3.0/2.0 hubs.  No configuration, just the WinUSB driver and it "just works".

Not so on my laptop.   3.4.2 (and 3.4.3) do not find the miners.  WinUSB is installed.  It looks the same in device manager on my laptop as it does my PC.  But cgminer doesn't see them.

I'm going to try updating my drivers on the laptop.  They should be up to date, but I'm going to check anyhow.

Any ideas?

M

That's why the one Icarus driver does all 5 ICA, BLT, LLT, CMR, AMU
They all work the same way ... just different speeds and different core counts.

CMR does, however, also have a glasswalker bitream that has extra options, but the other 4 are ... well ... missing any useful functionality other than simply hash 4 billion times in a row.
That's why an AMU costs SFA to make and why Friedcat has literally made something like a million selling them.

Look for the specs on the Icarus FPGA since that is the interface BE use.  Seems plausible to me anyway.

New release: Version 3.4.3, 13th September 2013

Stable codebase, feature upgrade version - Proxy support on stratum and per pool quota support. I also sneaked onto my wife's laptop to get osx working.


Human readable changelog:

- Build fixes for cgminer releases to build on OSX (building from git still requires massaging).
- Fix for an extremely rare cause of crashes.
- Updated the screen to show when there is block change notification with multipool strategies and stratum.
- Don't show the "waiting for work" message unless it is longer than it takes to switch pools during lag periods.
- Cope with trailing slashes being used on stratum based URLs.
- miner.php updates.
- Native proxy support on stratum for http1.0, http1.1, socks4, socks4a, socks5 and socks5h proxies without using libcurl for maximum stability.
- A completely rewritten load-balance strategy that now supports per pool quota support. See the following from the updated documentation to see how it works:

LOAD BALANCE:
This strategy sends work to all the pools on a quota basis. By default, all
pools are allocated equal quotas unless specified with --quota. This
apportioning of work is based on work handed out, not shares returned so is
independent of difficulty targets or rejected shares. While a pool is disabled
or dead, its quota is dropped until it is re-enabled. Quotas are forward
looking, so if the quota is changed on the fly, it only affects future work.
If all pools are set to zero quota or all pools with quota are dead, it will
fall back to a failover mode. See quota below for more information.

The failover-only flag has special meaning in combination with load-balance
mode and it will distribute quota back to priority pool 0 from any pools that
are unable to provide work for any reason so as to maintain quota ratios
between the rest of the pools.

QUOTAS

The load-balance multipool strategy works off a quota based scheduler. The
quotas handed out by default are equal, but the user is allowed to specify any
arbitrary ratio of quotas. For example, if all the quota values add up to 100,
each quota value will be a percentage, but if 2 pools are specified and pool0
is given a quota of 1 and pool1 is given a quota of 9, pool0 will get 10% of
the work and pool1 will get 90%. Quotas can be changed on the fly by the API,
and do not act retrospectively. Setting a quota to zero will effectively
disable that pool unless all other pools are disabled or dead. In that
scenario, load-balance falls back to regular failover priority-based strategy.
While a pool is dead, it loses its quota and no attempt is made to catch up
when it comes back to life.

To specify quotas on the command line, pools should be specified with a
semicolon separated --quota(or -U) entry instead of --url. Pools specified with
--url are given a nominal quota value of 1 and entries can be mixed.

For example:
Will give poola 1/3 of the work and poolb 2/3 of the work.

Writing configuration files with quotas is likewise supported. To use the above
quotas in a configuration file they would be specified thus:



Full changelog:

- Put corefoundation and iokit separate in ldflags for darwin.
- Add rules for libusb Makefile.am building on osx
- Add flags for building libusb statically on osx.
- Find the greatest common denominator in quotas and use the smallest number of
consecutive work items per pool in quota load balance mode to smooth hashrate
across pools with large quotas. Give excess quota to priority pool 0 instead of
pool 0.
- Avoid dynamically adding stack memory for nonce2 in the stratum send thread
and check the pool's nonce2_len will not cause an overflow.
- Add subdir-objects to automake options.
- Use inet_addr instead of inet_network to fix windows build.
- Remove unused pbase variable.
- Add support for socks4/4a proxies with stratum, and drop back to socks4
support via the global --socks-proxy command to not break previous
configurations.
- Fix warning on mingw build.
- Only show long-poll message in pool summary if it's not using stratum.
- Increase the time for the waiting for work message to be given to be greater
than that required for a pool swap in the scheduler which is set to 5s.
- Change message in status when using a balanced pool strategy to notify if
there's a stratum pool as well.
- Use the --failover-only flag to have special meaning in combination with
load-balance mode to distribute any unused quota back to pool 0 to maintain
ratios amongst other pools.
- Display quota and allow it to be modified via the pool menu.
- Add API commands and modify output to support pool quota displaying and
changing.
- Change message in status when using a balanced pool strategy to notify if
there's a stratum pool as well.
- Add quota support to configuration files.
- Rotate pools on all failures to set a pool in select_pool.
- Use quotas for load-balance pool strategy.
- Provide a mechanism for setting a pool quota to be used by load-balance.
- Use the --socks-proxy option with stratum, changing it to defaulting to socks5
and give appropriate message should it fail to connect.
- Cope with trailing slashes in stratum urls.
- Add more debugging messages when negotiating with proxies for stratum.
- Test specifically for socks5h in socks support for stratum.
- Add support for socks5 proxy with stratum
- Provide support for negotiating a stratum connection via http proxies.
- Connect to the proxy URL and port if specified for stratum sockets instead of
the pool directly.
- Extract any proxy url and port to be used by sockaddr if possible using
extract_sockaddr.
- Make extract_sockaddr set variables passed to it rather than pool struct
members.
- miner.php sort the mcast rigs so they are always in the same relative order
- miner.php allow sending the muticast message multiple times
- miner.php mcast ignore duplicate replies

cgminer version 3.1.1