Bitcoin Forum
December 03, 2016, 07:02:58 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 »
  Print  
Author Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64  (Read 244923 times)
cdhowie
Full Member
***
Offline Offline

Activity: 182



View Profile WWW
July 27, 2012, 06:42:44 AM
 #141

After extracting the Windows binaries, AVG detects "PSW.KeyLogger.AVU" in pdcurses.dll.  Since the functionality of pdcurses is to read keystrokes, this doesn't surprise me terribly, but it is a bit disconcerting.  Can this be resolved somehow?
Report it to your AVG as a false positive?
I have sent it in already... though in my experience they usually don't do much without contact from someone involved in the production or compilation of the software.  :/

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480748578
Hero Member
*
Offline Offline

Posts: 1480748578

View Profile Personal Message (Offline)

Ignore
1480748578
Reply with quote  #2

1480748578
Report to moderator
cdhowie
Full Member
***
Offline Offline

Activity: 182



View Profile WWW
July 27, 2012, 02:15:52 PM
 #142

I have sent it in already... though in my experience they usually don't do much without contact from someone involved in the production or compilation of the software.  :/

Quote
AVG Research Lab has analyzed the file(s) you have sent from your AVG Virus Vault. Below you can find the results for each file. The final verdict on the file is either a correct detection or a false positive detection.

Further information about the verdicts are available at our website:
http://www.avg.com/faq-1184

"c:\Users\Chris Howie\Desktop\bfgminer-2.5.1-win32\pdcurses.dll" - detection is correct

Yeah, that's more or less what I expected.

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
July 27, 2012, 02:19:17 PM
 #143

I have sent it in already... though in my experience they usually don't do much without contact from someone involved in the production or compilation of the software.  :/

Quote
AVG Research Lab has analyzed the file(s) you have sent from your AVG Virus Vault. Below you can find the results for each file. The final verdict on the file is either a correct detection or a false positive detection.

Further information about the verdicts are available at our website:
http://www.avg.com/faq-1184

"c:\Users\Chris Howie\Desktop\bfgminer-2.5.1-win32\pdcurses.dll" - detection is correct

Yeah, that's more or less what I expected.
Wonder if you can zip up the source code for just pdcurses.dll and send them in together.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
cdhowie
Full Member
***
Offline Offline

Activity: 182



View Profile WWW
July 27, 2012, 02:21:28 PM
 #144

Wonder if you can zip up the source code for just pdcurses.dll and send them in together.
Their GUI only seems to allow for detected files to be submitted.  It doesn't detect the original ZIP file that I downloaded as containing anything malicious.

Maybe if I added the DLL with no compression...

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
July 27, 2012, 02:30:18 PM
 #145

Their GUI only seems to allow for detected files to be submitted.  It doesn't detect the original ZIP file that I downloaded as containing anything malicious.

Maybe if I added the DLL with no compression...
The link you sent says contact support.  Can you do that and then send them the source so maybe they can send it on for deeper analysis?
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 27, 2012, 05:31:29 PM
 #146

I have sent it in already... though in my experience they usually don't do much without contact from someone involved in the production or compilation of the software.  :/

Quote
AVG Research Lab has analyzed the file(s) you have sent from your AVG Virus Vault. Below you can find the results for each file. The final verdict on the file is either a correct detection or a false positive detection.

Further information about the verdicts are available at our website:
http://www.avg.com/faq-1184

"c:\Users\Chris Howie\Desktop\bfgminer-2.5.1-win32\pdcurses.dll" - detection is correct

Yeah, that's more or less what I expected.
Actually, on further thought, it is possible that file could be infected (though very unlikely). It is an exception to my general "compile everything" policy - I just used their official DLL binary.

Anyhow, here's what I sent to AVG:
Quote
One of my users is reporting that AVG insists my software is a virus, even after sending to you for review. Please correct your procedures to actually do proper checking and not flag innocent software.

The flagged file is pdcurses.dll, which I am using the official Windows binary distributed at:

http://voxel.dl.sourceforge.net/project/pdcurses/pdcurses/3.4/pdc34dllw.zip

If this official binary is indeed infected, please provide evidence so that it is removed from SourceForge (a highly respected software website).

In the meantime, want to see if it detects one I compile myself?
http://luke.dashjr.org/tmp/code/pdcurses.dll
e8bc66188d8f0503a5850bb11340e0eb8d60491a827ce27add2b460b65096780  pdcurses.dll

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 29, 2012, 04:50:14 PM
 #147

NEW VERSION 2.5.2, JULY 29 2012

2.6.0 with scrypt support will follow soon, but since it potentially introduces many new bugs, I felt it prudent to release 2.5.2 first.

Human readable changelog:
  • Found and fixed a major bug where --failover-only would flood your current pool with requests if a secondary one longpolled first
  • Refactored stale detection algorithm to only flag shares that are actually stale
  • For BitFORCE devices, abandon nonce searches at the expense of any shares found in them, only if shares found would be guaranteed to be stale anyway; this is similar to how CGMiner abandons searches on any work restart, but shouldn't lose any valid shares
  • If you have more devices than fit in your BFGMiner console window, you can scroll them with the Up/Down arrow keys. This obviously also means it no longer crashes on Windows Wink
  • Moved the "Q" (requested getworks) in the overall curses summary to the second status line as "GW", since it makes more sense there (and balances better on the screen)
  • Improved config file parsing - you can use real JSON Numbers and false (for boolean options) now
  • New "poolpriority" RPC command that can be used to set the priority order of failover - this is mainly for improved handling of failover with Puppet Master
  • Submit stale shares, even during failure retries, if the user or pool wants them
  • Many various other minor bugfixes

Full changelog
  • Limit total number of curls recruited per pool to the number of mining threads to prevent blasting the network when we only have one pool to talk to.
  • Bugfix: Skip writing configuration of range-limited int options with negative values
  • Bugfix: Correctly attempt to load ~/.bfgminer/bfgminer.conf or ~/.cgminer/cgminer.conf as defaults
  • Send X-Minimum-Wait header on longpolls, to explicitly inform pools we will handle a response with no delay
  • bitforce: Abandon (only) stale searches for work restarts
  • Keep a counter of enabled pools and use that instead of iterating over the pool list. Use that value to ensure we don't set the last remaining active pool to the rejecting state.
  • bitforce: Skip out of sending work if work restart requested
  • RPC: Writeup on poolpriority command usage
  • Bugfix: API: Report errors from poolpriority command
  • RPC: New "poolpriority" command to set the order of pool priorities
  • strtok_ts: Thread-safe strtok that work on POSIX or Windows
  • Bugfix: Supress "caught up" event when first switching to a pool
  • Announce and restart work immediately when current pool has caught up to the current block
  • Bugfix: Don't consider work stale due to other pools' longpolls, if --failover-only is active
  • Refactor stale_work function to only flag actual stale shares
  • stale_work: Don't factor getwork delay into expiry for shares (only for work itself)
  • Bugfix: Use pool number rather than numeric pointer to strict pool, in block found notice
  • Accept JSON Numbers in config file parameters
  • Improve readability of OPT_HASARG in parse_config
  • Allow JSON false as a valid value for strictly boolean options
  • Include scan-serial in example configuration file
  • fpgautils: add support for 57.6 kBd serial
  • miner.php add a socket RCV timeout for if cgminer is hung and the API thread is still running
  • BFL force all code to timeout to avoid hanging
  • Detach pthread from within the api thread in case it is terminated due to not being instantiated before pthread_cancel is called from main, leading to a segfault.
  • Initialise mdplatform.
  • Find the gpu platform with the most devices and use that if no platform option is passed.
  • Allow more platforms to be probed if first does not return GPUs.
  • Bugfix: It is not a hardware error if nonces returned from modminer don't meet the pool target
  • bitforce & icarus: Log detection failures at debug log level, so we don't confuse users who have different devices (which is why these drivers are failing detection!)
  • Show "WAIT" (LIFE_WAIT status) if a cgpu is idle waiting for work (pool slow/dead)
  • Instead of quitting on failing N retries, just discard the share
  • Bugfix: Don't discard stale shares after submission failure, if user or pool wants stales submitted
  • Bugfix: Record discard-during-retry shares in the sharelog
  • Bugfix: Only show Algorithm in RPC summary if CPU mining is actually active
  • OpenCL: Remove intensity from statline, since it overflowed
  • Move "Q" (requested getworks) to second status line as "GW" to balance out better
  • Bugfix: Use a mutex to control non-curses output
  • Simplify code to a single vprintf path for curses-less printing
  • Move opt_quiet check to my_log_curses, so it works for curses-less builds
  • Use log_generic for vapplog to cut down on code duplication
  • Add space to log output now that there is more screen real estate available.
  • Bugfix: Copy argv[0] given to dirname()
  • Find the gpu platform with the most devices and use that if no platform option is passed.
  • Allow more platforms to be probed if first does not return GPUs.
  • Detach pthread from within the api thread in case it is terminated due to not being instantiated before pthread_cancel is called from main, leading to a segfault.
  • Debug output per thread hashrate is out by a factor of 1000.
  • Don't check if CPUs are sick since they can't be.
  • Calculate midstate in separate function and remove likely/unlikely macros since they're dependent on pools, not code design.
  • Display in debug mode when we're making the midstate locally.
  • Bugfix: Document --no-adl and --gpu-platform
  • Bugfix: Remove redundant documentation of --auto-fan and --auto-gpu (they are in GPU-specific options)
  • CPU mining may not be included in binaries, but it's not deprecated for BFGMiner either
  • Bugfix: Restore case-insensitivity to input
  • Scroll the device list with up/down arrow keys, if it is overflowed
  • Use select statement to handle input
  • Bugfix: Actually check that the device fits in the individual summary window before trying to print it
  • Bugfix: Fix build without curses but with OpenCL
  • Bugfix: Don't show a Temperature key if it isn't known
  • BFGMiner-specific NEWS fix

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
July 29, 2012, 06:23:48 PM
 #148

Trying to run 2.5.2 I get the following error message under Win7/64: 'the program cannot start because zlib1.dll is missing from your computer'.

Bfgminer 2.5.1 runs fine. Neither the 2.5.1 or 2.5.2 archives contain zlib1.dll, so it seems to be runtime dependency introduced in 2.5.2.  Sad

I also checked cgminer 2.6.0 (on which bfgminer 2.5.2 is largely based, except for scrypt) and it runs fine.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 29, 2012, 07:15:29 PM
 #149

Trying to run 2.5.2 I get the following error message under Win7/64: 'the program cannot start because zlib1.dll is missing from your computer'.

Bfgminer 2.5.1 runs fine. Neither the 2.5.1 or 2.5.2 archives contain zlib1.dll, so it seems to be runtime dependency introduced in 2.5.2.  Sad
Can you try replacing libcurl-4.dll with the one from 2.5.1?

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
July 29, 2012, 07:19:02 PM
 #150

Trying to run 2.5.2 I get the following error message under Win7/64: 'the program cannot start because zlib1.dll is missing from your computer'.

Bfgminer 2.5.1 runs fine. Neither the 2.5.1 or 2.5.2 archives contain zlib1.dll, so it seems to be runtime dependency introduced in 2.5.2.  Sad
Can you try replacing libcurl-4.dll with the one from 2.5.1?

Yes, that fixed the issue. Thanks, Luke.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 29, 2012, 07:29:01 PM
 #151

NEW VERSION 2.5.3, JULY 29 2012

Human readable changelog:
  • This should fix the issue Epoch reported Smiley

Full changelog
  • Bugfix: Add zlib1.dll to Win32 release archive
  • Bugfix: SICK low-hashrate is now determined by being under 1/3 the runtime average hashrate
  • Bugfix: cpu_set_t is never #defined, so use CPU_ZERO which is a macro

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 29, 2012, 07:52:38 PM
 #152

NEW VERSION 2.6.1, JULY 29 2012

Note that this does not have CGMiner's scrypt "sick" bug, and only adds scrypt support (2.5.3 has everything else).

Human readable changelog:
  • Major feature upgrade: Scrypt support. This is non-trivial to get working well and I suggest reading the SCRYPT-README included before asking any questions. While I do not in general support other currencies to bitcoin, with a large enough bitcoin bounty Con added this feature; see: https://bitcointalk.org/index.php?topic=92887.0

Full changelog
  • Autoselect --scrypt iff all pools send scrypt work
  • Adapt SCRYPT-README to BFGMiner (directing Bitcoin donations the correct direction to reach Con)
  • Remove mentions of Litecoin specifically
  • Bugfix: Fix build without OpenCL but with scrypt
  • make-release: Add SCRYPT-README
  • Bump version 2.6.0, adding SCRYPT README to makefile.
  • Smarter autogen.sh script.
  • Sleeping on intensity decrease is broken, remove it.
  • Sleep only the extra amount of time we overran the dynamic interval in dynamic mode.
  • Add scrypt documentation in the form of a separate readme.
  • Fix build error without scrypt enabled.
  • Limit thread concurrency for scrypt to 5xshaders if shaders is specified.
  • Simplify repeated use of gpus[gpu]. in ocl.c
  • Find the nearest power of 2 maximum alloc size for the scrypt buffer that can successfully be allocated and is large enough to accomodate the thread concurrency chosen, thus mapping it to an intensity.
  • Don't make opt_scrypt mandatory blocking with opencl code.
  • Update kernel versions reflecting changes in the API.
  • Make the thread concurrency and lookup gap options hidden on the command line and autotune parameters with a newly parsed --shaders option.
  • Fix target testing with scrypt kernel as it would have been missing shares below target.
  • Always create the largest possible padbuffer for scrypt kernels even if not needed for thread_concurrency, giving us some headroom for intensity levels.
  • Use the detected maximum allocable memory on a GPU to determine the optimal scrypt settings when lookup_gap and thread_concurrency parameters are not given.
  • Check the maximum allocable memory size per opencl device.
  • Add debugging output if buffer allocation fails for scrypt and round up bufsize to a multiple of 256.
  • Nonce testing for btc got screwed up, leading to no accepted shares. Fix it.
  • Display size of scrypt buffer used in debug.
  • Allow intensities up to 20 if scrypt is compiled in.
  • Add name to scrypt kernel copyright.
  • Allow lookup gap and thread concurrency to be passed per device and store details in kernel binary filename.
  • Ignore negative intensities for scrypt.
  • Change the scale of intensity for scrypt kernel and fix a build warning.
  • Correct target value passed to scrypt kernel.
  • Use 256 output slots for kernels to allow 1 for each worksize.
  • Test the target in the actual scrypt kernel itself saving further calculations.
  • Reinstate GPU only opencl device detection.
  • Decrease lookup gap to 1. Does not seem to help in any way being 2.
  • Fix build.
  • Make pad0 and pad1 local variable in scrypt kernel.
  • Constify input variable in scrypt kernel.
  • Send correct values to scrypt kernel to get it finally working.
  • Create command queue before compiling program in opencl.
  • Fix external scrypt algo missing.
  • Limit scrypt to 1 vector.
  • Handle KL_SCRYPT in config write.
  • Get rid of stuff.
  • Don't enqueuewrite buffer at all for pad8 and pass work details around for scrypt in dev_blk.
  • Set the correct data for cldata and prepare for pad8 fixes.
  • Get rid of spaces in arrays in scrypt kernel.
  • Start with smaller amount of hashes in cpu mining to enable scrypt to return today sometime.
  • Free the scratchbuf memory allocated in scrypt and don't check if CPUs are sick since they can't be. Prepare for khash hash rates in display.
  • Add cpumining capability for scrypt.
  • Set scrypt settings and buffer size in ocl.c code to be future modifiable.
  • Cope with when we cannot set intensity low enough to meet dynamic interval by inducing a forced sleep.
  • Make dynamic and scrypt opencl calls blocking.
  • Fix nonce submission code for scrypt.
  • Make sure goffset is set for scrypt and drop padbuffer8 to something manageable for now.
  • Set up buffer8 for scrypt.
  • Build fix for opt scrypt.
  • Don't check postcalc nonce with sha256 in scrypt.
  • Don't test nonce with sha and various fixes for scrypt.
  • Make scrypt buffers and midstate compatible.
  • Use specific output array entries in scrypt kernel.
  • Provide initial support for the scrypt kernel to compile with and mine scrypt with the --scrypt option.
  • Enable completely compiling scrypt out.
  • Begin import of scrypt opencl kernel from reaper.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
July 29, 2012, 10:58:21 PM
 #153

poolpriority has 2 bugs in it - yes there was a reason why I rewrote it ...
Don't forget to get the code from the master git

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 29, 2012, 11:15:29 PM
 #154

poolpriority has 2 bugs in it - yes there was a reason why I rewrote it ...
What bugs are those? From what I saw you just removed the thread-race crash-resistence and went to effort to handle errors nicer. I'm planning to merge your changes into 0.6.2 regardless since you are the RPC maintainer, but I'm still curious as to what bugs there were.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
July 29, 2012, 11:49:19 PM
 #155

poolpriority has 2 bugs in it - yes there was a reason why I rewrote it ...
What bugs are those? From what I saw you just removed the thread-race crash-resistence and went to effort to handle errors nicer. I'm planning to merge your changes into 0.6.2 regardless since you are the RPC maintainer, but I'm still curious as to what bugs there were.
1) If there is a problem with the parameter, it will still change the pools and then report an error
(shouldn't change anything until it's sure it's OK)
2) If you specify the same pool twice it leaves a gap in the pool priority numbers
(should just report an error and do nothing)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 29, 2012, 11:54:17 PM
 #156

poolpriority has 2 bugs in it - yes there was a reason why I rewrote it ...
What bugs are those? From what I saw you just removed the thread-race crash-resistence and went to effort to handle errors nicer. I'm planning to merge your changes into 0.6.2 regardless since you are the RPC maintainer, but I'm still curious as to what bugs there were.
1) If there is a problem with the parameter, it will still change the pools and then report an error
(shouldn't change anything until it's sure it's OK)
2) If you specify the same pool twice it leaves a gap in the pool priority numbers (unless it's the last priority pool)
(should just report an error and do nothing)
OK, nothing major then...
  • the first one was intentional (the alternative is slower, not that it matters much)
  • both issues only matter when the caller uses it wrong anyway
  • neither problem can cause any real problems

Thanks Kano, I have to admit you deserve more credit than I give you sometimes...

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
July 30, 2012, 04:48:22 PM
 #157

There are reports of BFL Single support being broken in the current build of bfgminer (and cgminer). See messages surrounding:

https://bitcointalk.org/index.php?topic=28402.msg1065423#msg1065423

I have experienced issues with the current build across 3 machines running Singles; generally takes several minutes, perhaps up to an hour, for these issues to surface. Rolling back to a previous build resolved this.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 30, 2012, 05:10:10 PM
 #158

There are reports of BFL Single support being broken in the current build of bfgminer (and cgminer). See messages surrounding:

https://bitcointalk.org/index.php?topic=28402.msg1065423#msg1065423

I have experienced issues with the current build across 3 machines running Singles; generally takes several minutes, perhaps up to an hour, for these issues to surface. Rolling back to a previous build resolved this.
Could you open an Issue with as much details as possible, please? Especially useful is:
  • Can anything be done to trigger it (as opposed to "it just happens eventually")?
  • What messages appear in the log immediately before and when it goes SICK?
  • Which versions did you find are working, and which ones have the problem?

Thanks!

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
July 30, 2012, 05:33:58 PM
 #159

There are reports of BFL Single support being broken in the current build of bfgminer (and cgminer). See messages surrounding:

https://bitcointalk.org/index.php?topic=28402.msg1065423#msg1065423

I have experienced issues with the current build across 3 machines running Singles; generally takes several minutes, perhaps up to an hour, for these issues to surface. Rolling back to a previous build resolved this.
Could you open an Issue with as much details as possible, please? Especially useful is:
  • Can anything be done to trigger it (as opposed to "it just happens eventually")?
  • What messages appear in the log immediately before and when it goes SICK?
  • Which versions did you find are working, and which ones have the problem?

Thanks!
Understood. I will collect detailed information this evening.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
July 30, 2012, 05:37:51 PM
 #160

There are reports of BFL Single support being broken in the current build of bfgminer (and cgminer). See messages surrounding:

https://bitcointalk.org/index.php?topic=28402.msg1065423#msg1065423

I have experienced issues with the current build across 3 machines running Singles; generally takes several minutes, perhaps up to an hour, for these issues to surface. Rolling back to a previous build resolved this.
Could you open an Issue with as much details as possible, please? Especially useful is:
  • Can anything be done to trigger it (as opposed to "it just happens eventually")?
  • What messages appear in the log immediately before and when it goes SICK?
  • Which versions did you find are working, and which ones have the problem?

Thanks!
Understood. I will collect detailed information this evening.
If you can reproduce it, making the log with --debug enabled may be helpful. You'll need to be sure to redirect it to a log file so it doesn't just scroll off the screen, by adding 2>logfile to your commandline.

Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!