HolyScott
|
 |
October 31, 2012, 04:29:22 PM |
|
2.9.1 Mining nicely on a Raspberry Pi, however I do get Comm Error disconnects randomly with 4x BFL Singles. Google search lead me to the issue board, and post discussing that this is due to the usb problems on the raspberry pi. I have a 512 MB RPi on order to see if the new reversion fixes the issue.
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
|
|
|
creativex
|
 |
October 31, 2012, 04:36:52 PM |
|
New version(2.9.1) does NOT crash windows 7 x64 for me. Current uptime with new version approximately 12hrs on W8x64 & 8hrs on W7x64. Previous version(2.8.2) crashed windoze within minutes. Whatever ya done, TY! Donation inbound.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
October 31, 2012, 06:22:20 PM |
|
2.9.1 Mining nicely on a Raspberry Pi, however I do get Comm Error disconnects randomly with 4x BFL Singles. Google search lead me to the issue board, and post discussing that this is due to the usb problems on the raspberry pi. I have a 512 MB RPi on order to see if the new reversion fixes the issue.
As I understand it, there's a way to upgrade the firmware on old revisions too.
|
|
|
|
BitMinerN8
|
 |
October 31, 2012, 07:20:18 PM |
|
2.9.1 Mining nicely on a Raspberry Pi, however I do get Comm Error disconnects randomly with 4x BFL Singles. Google search lead me to the issue board, and post discussing that this is due to the usb problems on the raspberry pi. I have a 512 MB RPi on order to see if the new reversion fixes the issue.
As I understand it, there's a way to upgrade the firmware on old revisions too. Raspberry Pi Update Tool https://github.com/Hexxeh/rpi-updateAnd there is a newer Raspbian build posted on 10/28. http://www.raspberrypi.org/downloads
|
|
|
|
|
DiCE1904
Legendary
Offline
Activity: 1102
Merit: 1000
NotPaidForMySig
|
 |
November 01, 2012, 07:52:26 PM |
|
2.9.1 fixed all the errors I was getting with 9.0
thank you!
|
|
|
|
HolyScott
|
 |
November 02, 2012, 02:02:19 AM |
|
I've switched off the RPi to a Dell Mini 9 Netbook running Lubuntu and all Comm Errors are gone, so still thinking it is a RPi issue.
|
|
|
|
thirdchance57
Full Member
 
Offline
Activity: 192
Merit: 100
★Bitvest.io★ Play Plinko or Invest!
|
 |
November 04, 2012, 09:13:49 PM |
|
2.9.1 working great on win7 x64 cgminer=problems guiminer=problems
thanks
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
November 07, 2012, 07:05:25 PM |
|
NEW VERSION 2.9.2, NOVEMBER 7 2012I've also bumped the stable release to 2.8.5 including the fixes relevant to the 2.8.x versions. Human readable changelog:modminer & x6500: New bitstream, improving functional performance by about 10 Mh/s on average. You'll need to power cycle your device, or use the new --force-dev-init option to upload the new bitstream. (thanks wizkid057!)- x6500: Support for temperature sensors, including --temp-target & co.
- x6500: Extended per-FPGA details in RPC API.
- x6500: Support for older X6500 devices by manually specifying their serial numbers as --scan-serial x6500:serialnumber.
- Some basic stratum transparency checks to help keep pools accountable using new mining.get_transactions method.
Full changelog- Add endian swap defines for where missing.
- Only retarget stratum shares to new pool diff if diff has dropped.
- Bugfix: x6500: Use json_object_set_new to correctly count references to per-FPGA RPC data
- Bugfix: modminer: Use json_object_set_new to correctly count references to per-FPGA RPC data
- Bugfix: Only append newline when printing protocol data
- Bugfix: Use memchr to look for newlines in socket line data, since the buffer isn't null terminated
- Bugfix: Ensure GETWORK_MODE_GBT isn't replaced with GETWORK_MODE_POOL
- Count lost stratum share submits and increase message priority to warning.
- Show which pool untracked share messages have come from.
- Sleep 5 seconds before retrying submit.
- Changes to build prototypes to support building on FreeBSD 9.1-RC2 amd64
- Count lost shares with stratum as submit stale lost.
- Discard record of stratum shares sent and report lost shares on disconnection since they will never be reported back.
- Check that count of transactions received via stratum is reasonable
- Use realloc'd data_buffer to support stratum lines longer than 8 KB, and parse stratum responses during auth
- Use mining.get_transactions to check for stratum pool transparency (actual response ignored for now)
- ztex: Silence false "unexpected" hardware errors, and don't count them as hw errors
- README: Update build instructions to reflect current reality
- x6500: Expose per-FPGA details to RPC API
- x6500: Implement support for --temp-target
- x6500: Increase default clock frequency to 200 Mhz, now that new bitstream seems to run well around that
- x6500: Flush nonces in FPGA buffer at initialization to avoid false hw errors on restart
- x6500: Release device lock sooner during initialization, before logging initial frequency info
- x6500: Read temperature sensors after sending work, when enabled
- Bugfix: jtag: Fix optimized register reading code (it was reading an extra bit before the last, corrupting outside the buffer)
- Implement new --force-dev-init option to force bitstream upload to modminer and x6500 devices
- Bugfix: x6500: Include --scan-serial option even for x6500-only builds
- Bugfix: ztex: Include --scan-serial option even for ztex-only builds, so it can be used to disable autodetect if needed
- FPGA-README: Discuss X6500 --scan-serial usage of cases where it may be needed
- ft232r: If we are searching for a specific serial, pay no attention to the product id
- x6500: Try a more flexible approach to applying dynclock logic
- Bugfix: dynclock: Use standard C struct initializer to handle initialization, instead of memsetting memory to nulls
- x6500: Whenever we get a hardware error, purge buffers just in case of read/write desync
- Bugfix: x6500: When purging ft232r buffers (during bitstream upload), also clear JTAG delayed read counter to avoid any potential desync
- Bugfix: ft232r: Always flush writes before purging buffers, and empty local read buffer when flushing ftdi read buffer
- There is no need for addrinfo any more.
- Fix filename for x6500 bitstream to match previous commit's rename
- Rename x6500 bitstream to match existing licensing naming setup
- x6500 dual temp sensor support
- x6500 is far more stable with its own bitstream
|
|
|
|
creativex
|
 |
November 07, 2012, 07:23:37 PM |
|
2.9.2 up and running on W8x64 w/o incident.
|
|
|
|
vitruvio
|
 |
November 07, 2012, 08:13:11 PM |
|
Same issues with hashrate as version 2.9.0 and 2.9.1.
It happens only to me?
Regards
|
|
|
|
abracadabra
|
 |
November 08, 2012, 12:15:31 AM |
|
Trying to use bfgminer 2.9.2 with an x6500 Have installed WinUSB driver (v6.1.7600.16385) I will usually get the following upon a bfgminer start: 5s: 0.0 avg: 0.0 u: 0.0 kh/s | A:0 R:0 HW:0 E:0% U:0.0/m TQ: 0 ST: 11 SS: 0 DW: 5 NB: 2 GW: 6 LW: 28 GF: 0 RF: 0 Connected to us.ozco.in with LP as user abracadabra.xxx Block: 0000024c01b18842d9142711... Started: [18:11:31] Best share: 0 -------------------------------------------------------------------------------- [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit OCL 0: | OFF / 0.0/ 0.0kh/s | A:0 R:0 HW:0 U:0.00/m XBS 0: | 0.0/ 0.0/ 0.0kh/s | A:0 R:0 HW:0 U:0.00/m --------------------------------------------------------------------------------
[2012-11-07 18:08:58] XBS 0.0: FPGA not programmed [2012-11-07 18:08:58] XBS 0: Programming AH00WPJ0... [2012-11-07 18:09:14] XBS 0: Programming AH00WPJ0... 25% complete... [2012-11-07 18:09:30] XBS 0: Programming AH00WPJ0... 50% complete... [2012-11-07 18:09:46] XBS 0: Programming AH00WPJ0... 75% complete... [2012-11-07 18:10:01] XBS 0: Programming AH00WPJ0... 100% complete... [2012-11-07 18:10:02] XBS 0: Done programming AH00WPJ0 [2012-11-07 18:11:31] LONGPOLL from pool 0 detected new block [2012-11-07 18:11:36] XBS 0.0: Flushed 2251 nonces from buffer at init [2012-11-07 18:11:36] XBS 0.0: Frequency set to 200 Mhz (range: 2-250) [2012-11-07 18:11:36] XBS 0: JTAG detect returned -1 [2012-11-07 18:11:36] Thread 3 failure, exiting
then sometimes: bfgminer version 2.9.2 - Started: [2012-11-07 18:12:31] - [ 0 days 00:00:09] -------------------------------------------------------------------------------- 5s: 0.0 avg: 0.0 u: 0.0 kh/s | A:0 R:0 HW:0 E:0% U:0.0/m TQ: 0 ST: 5 SS: 0 DW: 0 NB: 1 GW: 1 LW: 8 GF: 0 RF: 0 Connected to us.ozco.in with LP as user abracadabra.yiannaki Block: 0000024c01b18842d9142711... Started: [18:12:31] Best share: 0 -------------------------------------------------------------------------------- [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit OCL 0: | OFF / 0.0/ 0.0kh/s | A:0 R:0 HW:0 U:0.00/m XBS 0: | 0.0/ 0.0/ 0.0kh/s | A:0 R:0 HW:0 U:0.00/m --------------------------------------------------------------------------------
[2012-11-07 18:12:30] Probing for an alive pool [2012-11-07 18:12:31] Long-polling activated for http://us.ozco.in:8332/LP (get work) [2012-11-07 18:12:31] Disabling extra threads due to dynamic mode. [2012-11-07 18:12:31] Tune dynamic intensity with --gpu-dyninterval [2012-11-07 18:12:31] XBS 0: JTAG error reading user code [2012-11-07 18:12:31] Thread 2 failure, exiting [2012-11-07 18:12:31] XBS 0: JTAG detect returned -2 [2012-11-07 18:12:31] Thread 3 failure, exiting
after a power cycle I'll sometimes get: bfgminer version 2.9.2 - Started: [2012-11-07 18:13:38] - [ 0 days 00:00:15] -------------------------------------------------------------------------------- 5s: 0.0 avg: 0.0 u: 0.0 kh/s | A:0 R:0 HW:0 E:0% U:0.0/m TQ: 0 ST: 5 SS: 0 DW: 0 NB: 1 GW: 1 LW: 8 GF: 0 RF: 0 Connected to us.ozco.in with LP as user abracadabra.yiannaki Block: 0000024c01b18842d9142711... Started: [18:13:38] Best share: 0 -------------------------------------------------------------------------------- [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit OCL 0: | OFF / 0.0/ 0.0kh/s | A:0 R:0 HW:0 U:0.00/m XBS 0: | 0.0/ 0.0/ 0.0kh/s | A:0 R:0 HW:0 U:0.00/m --------------------------------------------------------------------------------
[2012-11-07 18:13:38] Probing for an alive pool [2012-11-07 18:13:38] Long-polling activated for http://us.ozco.in:8332/LP (get work) [2012-11-07 18:13:39] Disabling extra threads due to dynamic mode. [2012-11-07 18:13:39] Tune dynamic intensity with --gpu-dyninterval [2012-11-07 18:13:39] XBS 0: JTAG detect returned -1 [2012-11-07 18:13:39] Thread 2 failure, exiting [2012-11-07 18:13:39] XBS 0: JTAG detect returned -1 [2012-11-07 18:13:39] Thread 3 failure, exiting
then after multiple restarts of bfgminer I'll get: bfgminer version 2.9.2 - Started: [2012-11-07 18:14:06] - [ 0 days 00:00:39] -------------------------------------------------------------------------------- 5s: 0.0 avg: 0.0 u: 0.0 kh/s | A:0 R:0 HW:0 E:0% U:0.0/m TQ: 0 ST: 5 SS: 0 DW: 0 NB: 1 GW: 1 LW: 8 GF: 0 RF: 0 Connected to us.ozco.in with LP as user abracadabra.yiannaki Block: 0000024c01b18842d9142711... Started: [18:14:06] Best share: 0 -------------------------------------------------------------------------------- [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit OCL 0: | OFF / 0.0/ 0.0kh/s | A:0 R:0 HW:0 U:0.00/m XBS 0: 60% | 0.0/ 0.0/ 0.0kh/s | A:0 R:0 HW:0 U:0.00/m --------------------------------------------------------------------------------
[2012-11-07 18:14:06] Probing for an alive pool [2012-11-07 18:14:06] Long-polling activated for http://us.ozco.in:8332/LP (get work) [2012-11-07 18:14:06] Disabling extra threads due to dynamic mode. [2012-11-07 18:14:06] Tune dynamic intensity with --gpu-dyninterval [2012-11-07 18:14:06] XBS 0: JTAG detect returned -1 [2012-11-07 18:14:06] Thread 2 failure, exiting [2012-11-07 18:14:06] XBS 0.1: FPGA not programmed [2012-11-07 18:14:06] XBS 0: Programming AH00WPJ0... [2012-11-07 18:14:23] XBS 0: Programming AH00WPJ0... 25% complete... [2012-11-07 18:14:39] XBS 0: Programming AH00WPJ0... 50% complete... [2012-11-07 18:14:50] LONGPOLL from pool 0 requested work restart [2012-11-07 18:14:54] XBS 0: Programming AH00WPJ0... 75% complete... [2012-11-07 18:15:09] XBS0: Idle for more than 60 seconds, declaring SICK! [2012-11-07 18:15:09] XBS0: Attempting to restart [2012-11-07 18:15:10] XBS 0: Programming AH00WPJ0... 100% complete... [2012-11-07 18:15:11] Thread 3 failure, exiting [2012-11-07 18:15:12] XBS0: Idle for more than 60 seconds, declaring SICK! [2012-11-07 18:15:12] XBS0: Attempting to restart
Any help?
|
|
|
|
HolyScott
|
 |
November 08, 2012, 04:00:11 PM |
|
Git hub still compiling as 2.9.1
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
November 08, 2012, 06:36:23 PM |
|
Git hub still compiling as 2.9.1
It's important to re-run autogen.sh
|
|
|
|
purelithium
|
 |
November 10, 2012, 08:10:51 PM |
|
After running 2.9.2 for a little over 2 days, I haven't noticed any hashing improvement with my MMQ.
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
November 10, 2012, 08:22:24 PM |
|
After running 2.9.2 for a little over 2 days, I haven't noticed any hashing improvement with my MMQ. Did you reprogram it? You need to either power cycle the MMQ (to clear the programming) or use --force-dev-init
|
|
|
|
purelithium
|
 |
November 10, 2012, 10:48:49 PM |
|
Yeah I did. It's still hashing at 840mhash, my U is at about 11.4/min It was in that area before, too.
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
November 10, 2012, 10:53:44 PM |
|
Yeah I did. It's still hashing at 840mhash, my U is at about 11.4/min It was in that area before, too. Maybe it only works up to a point. I've never seen 840 Mh/s myself.
|
|
|
|
purelithium
|
 |
November 10, 2012, 11:06:05 PM |
|
Hmm... interesting. I've never had an issue getting it to clock up to 210mhz. The u is usually around 816-817mhash though.
|
Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2366
Merit: 1001
|
 |
November 10, 2012, 11:13:05 PM |
|
Hmm... interesting. I've never had an issue getting it to clock up to 210mhz. The u is usually around 816-817mhash though.
Well, I let it get rather hot here too; usually at least 80 F.
|
|
|
|
|