Bitcoin Forum
July 16, 2018, 09:52:11 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 [599] 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5756833 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
OtaconEmmerich
Full Member
***
Offline Offline

Activity: 234
Merit: 100



View Profile
August 16, 2013, 02:37:37 AM
 #11961

The Hub works perfectly fine on the PC, It spits out errors even with one BE is connected to the Hub. I'm thinking it's some kinda software issue as I don't have a normal Arch install.

BE draws way more power then most other devices. As I am sure you have read it is far over spec for usb1 and usb2. It might be in spec for usb3. People get around the power issue by wiring the hub in question to a higher current source like a computer PS. Then you just have to worry about the Vias on the board carrying the current without failing.

Good luck.
I don't think power is the issue, Like I said it works fine when plugged into the OTG cable alone. When I just plug just ONE BE into the Hub it spits out the errors till after a while a the BE's LED starts glowing green. I think it's a software (I'm running Linux on a tablet which is kinda iffy) or the hub acting weird. I'm gunna try running debug mode and figuring it out before tonight. I mostly want this setup so I can mine at night to save on power costs.
1531734731
Hero Member
*
Offline Offline

Posts: 1531734731

View Profile Personal Message (Offline)

Ignore
1531734731
Reply with quote  #2

1531734731
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1531734731
Hero Member
*
Offline Offline

Posts: 1531734731

View Profile Personal Message (Offline)

Ignore
1531734731
Reply with quote  #2

1531734731
Report to moderator
1531734731
Hero Member
*
Offline Offline

Posts: 1531734731

View Profile Personal Message (Offline)

Ignore
1531734731
Reply with quote  #2

1531734731
Report to moderator
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2576
Merit: 1110


Ruu \o/


View Profile WWW
August 16, 2013, 02:39:01 AM
 #11962

I don't think power is the issue, Like I said it works fine when plugged into the OTG cable alone. When I just plug just ONE BE into the Hub it spits out the errors till after a while a the BE's LED starts glowing green. I think it's a software (I'm running Linux on a tablet which is kinda iffy) or the hub acting weird. I'm gunna try running debug mode and figuring it out before tonight. I mostly want this setup so I can mine at night to save on power costs.
Could be overheating. Try a simple fan over them for a while as a straight forward test.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
OtaconEmmerich
Full Member
***
Offline Offline

Activity: 234
Merit: 100



View Profile
August 16, 2013, 02:48:38 AM
 #11963

Nope, I always run a fan on them. I've got one of the 92mm Antec USB ones and a Desktop fan for a backup. Like I said, it runs perfectly fine without the HUB. Gunna go work on debugging now.
kano
Legendary
*
Offline Offline

Activity: 2506
Merit: 1043


Linux since 1997 RedHat 4


View Profile
August 16, 2013, 02:51:28 AM
 #11964

Nope, I always run a fan on them. I've got one of the 92mm Antec USB ones and a Desktop fan for a backup. Like I said, it runs perfectly fine without the HUB. Gunna go work on debugging now.
https://bitcointalk.org/index.php?topic=28402.msg2938585#msg2938585

(the bit you ignored when you replied)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
OtaconEmmerich
Full Member
***
Offline Offline

Activity: 234
Merit: 100



View Profile
August 16, 2013, 02:59:04 AM
 #11965

Woops! I mis-read it before Kano, I just saw the edit now. Yeah, I'll get to running that.
Askit2
Hero Member
*****
Offline Offline

Activity: 986
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


View Profile
August 16, 2013, 03:07:15 AM
 #11966

May I ask why you don't use the normal cgminer binary with the -G flag ?
Because if you use standard CGMiner.exe and your only ASIC mining it will require OpenCL SDK/Runtime to be installed to run.  If you use CGMiner-nogpu.exe then you don't need any AMD software at all.

 Well that makes far too much sense. TIL. Thank you.

When I compile on Linux or windows I have 0 AMD software installed. It isn't required at all. You can run without having OpenCL. I do it frequently both pre and post the no GPU versions. Just use the switch for no gpu mining. I have run the official binaries built with support but it didn't matter except I could use it.

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
BTC-engineer
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250



View Profile
August 16, 2013, 02:23:23 PM
 #11967

I've a basic question about the impact of hw-errors inside cgminer and on the over-all mining result at a pool.

I'm just doing different firmware optimizations inside the current BFL firmware for my ASIC singles and want to make sure that my understanding of the hw-error counter inside cgminer is really correct.

Let's say I'm getting an average hashrate of 100GH with 0% hw-errors showing up inside cgminer and nothing else is going wrong (retries, network problems etc.). In this case I would assume that I've also have an average hashrate of 100GH at the pool, right?

Now let's say cgminer is showing me 1% hw-errors. My basic understanding of software like cgminer is, that it's checking the mining result of the mining device and if the result is wrong, this result will not be forwarded to the pool and the hw-error counter is going up. Is my assumption correct, that in this case the average hashrate at the pool will be 99GH? Or is there anything else (relevant overhead, etc.) caused by hw-errors which has to be kept in mind when thinking about the over-all mining result at a pool?
 

                             █         
                             ▀██       
                              ███▄     
                              █████     
                 ▄██████████   █████   
            ▄███████████████   █████▄   
         ▄██████████████████   ██████   
       █████████████████████  ███████   
     ██████████████████████   ████████ 
   ▄████████▀                █████████ 
  ██████    ▄██████         ██████████ 
 ███▀    ▄██████████      ███████████   
██       ████████████    ████████████   
          █████████████   ██████████   
            █████████████   ███████     
              █████████████▄    ██▀     
                 ██████████████         
                    ▀███████████████▄   
                          ▀███████████▀

FLUX 

  VALVE      UBISOFT     GAMING ECOSYSTEM      Origin      GAMELOFT 
                   WEBSITE WHITEPAPER MEDIUM TWITTER FACEBOOK TELEGRAM █       


  17 - 24 April
   Public Sale
os2sam
Legendary
*
Offline Offline

Activity: 2464
Merit: 1001


Think for yourself


View Profile
August 16, 2013, 02:33:33 PM
 #11968

In this case I would assume that I've also have an average hashrate of 100GH at the pool, right?

It sounds like your implying that the pools estimate of your hash rate is correct??  If so it is not!

The pool has no idea what your hash rate is.  It's just an estimate.

With most pools you can change the time period which the hash rate is estimated for which will influence how fast and how accurate your estimate will be.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
BTC-engineer
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250



View Profile
August 16, 2013, 02:39:36 PM
 #11969

In this case I would assume that I've also have an average hashrate of 100GH at the pool, right?

It sounds like your implying that the pools estimate of your hash rate is correct??  If so it is not!

The pool has no idea what your hash rate is.  It's just an estimate.

With most pools you can change the time period which the hash rate is estimated for which will influence how fast and how accurate your estimate will be.

No, I don't imply this. I know about the pool hashrate estimation based on shares during a specified time period.

My questions are regarding the impact of the hw-error counter.

                             █         
                             ▀██       
                              ███▄     
                              █████     
                 ▄██████████   █████   
            ▄███████████████   █████▄   
         ▄██████████████████   ██████   
       █████████████████████  ███████   
     ██████████████████████   ████████ 
   ▄████████▀                █████████ 
  ██████    ▄██████         ██████████ 
 ███▀    ▄██████████      ███████████   
██       ████████████    ████████████   
          █████████████   ██████████   
            █████████████   ███████     
              █████████████▄    ██▀     
                 ██████████████         
                    ▀███████████████▄   
                          ▀███████████▀

FLUX 

  VALVE      UBISOFT     GAMING ECOSYSTEM      Origin      GAMELOFT 
                   WEBSITE WHITEPAPER MEDIUM TWITTER FACEBOOK TELEGRAM █       


  17 - 24 April
   Public Sale
chanson
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
August 16, 2013, 03:50:32 PM
 #11970

I've been away for a while and decided to give 3.3 another shot since kano et al are singing its praises everywhere.

3.3.4 using libusb-1.0.16-rc10 compiled from sourceforge still shuts down half of my 4x AM USB eruptors when running on Debian amd64 with USB disconnects. If there's some sort of logs you would like let me to post, let me know what you would like to see, but compiling a newer libusb absolutely *does not* solve the problem.

Back to 3.1.1 where everything works fine.
xyzzy099
Legendary
*
Offline Offline

Activity: 1027
Merit: 1000



View Profile
August 16, 2013, 04:44:07 PM
 #11971

I've been away for a while and decided to give 3.3 another shot since kano et al are singing its praises everywhere.

3.3.4 using libusb-1.0.16-rc10 compiled from sourceforge still shuts down half of my 4x AM USB eruptors when running on Debian amd64 with USB disconnects. If there's some sort of logs you would like let me to post, let me know what you would like to see, but compiling a newer libusb absolutely *does not* solve the problem.

Back to 3.1.1 where everything works fine.

I seem to be having a similar problem on Win7x64 with WinUSB (via Zadig).  I have 10 BEs, and every couple of hours, at least one will stop working with an error like this:

Code:
AMU0: Comms error (werr=-7 amt=0)

I tried using different hubs and tried using no more than 4 BEs in each 7-port HUB, in case it was a power issue, but nothing helps.

I have not tried using 3.1.1 yet, but I guess that is my next step.  This is very frustrating.

[Edit: I should add that if CGMiner is restarted, it will not pick up the BE that apparently failed.  It will seem to be OK, in that Windows says it is OK, and working, but the LED will stay on steady, and I have to manually unplug and replug it to get it to be seen by CGMINER.]

Libertarians:  Diligently plotting to take over the world and leave you alone.
Karin
Member
**
Offline Offline

Activity: 109
Merit: 10



View Profile WWW
August 16, 2013, 06:06:02 PM
 #11972

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

This directly relates to the whole libusb monologue I've been having in here over the last month
That specifically means your libusb on your mac is bugged - the timeout option when doing I/O isn't working
The README says how to build with a working libusb and it works on Linux and Windows - no idea about a Mac ...
Tell whoever Karin is to read the README ...

Karin, read the README  Tongue
I'm Karin! Cheesy

I keep a very close eye on the readme's (even following their changes on github), and I've tried using rc10 but if I recall it had no effect on this bug on Macs, so I instead include the latest libusb in my builds.

Kano makes it sounds like the error confidently lies within libusb, so I'll do a full spectrum of tests with various libusb versions.  If I can find a version that works I will update cgminer for Mac OS X and Asteroid (my Mac GUI to cgminer) accordingly.

Otherwise, we'll have to dig deeper into libusb, and any errors generated from cgminer (and what the community can help with) would be our best bet in figuring out the issue with libusb + Macs.  I'll try and do these test builds tonight and will post back with what I find.

Easiest to use bitcoin/litecoin miner for Mac: AsteroidApp.com | @AsteroidApp | Bitcointalk forum thread
Unofficial cgminer for Mac OS X | sgminer for Mac OS X
ISAWHIM
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
August 16, 2013, 07:03:17 PM
 #11973

I have an issue with the latest CGMINER...

Instead of showing the number of "Accepted" and "Rejected" A: 2 R:1 HW: 0... it shows the "last diff" of the last accepted block for accepted and rejected, eg, for my scrypt-coins it shows...
A: 70687 R :68799 (Wow, great, 70687 accepted blocks and only 68799 rejects! From submitting two blocks!) lol

Those are the DIFFs of the coins I am mining, 70.7K and 68.8K were the two found.

Why did this change, and how do I get it back to show the NUMBER of accepted so I can see when ACCEPTED vs REJECTED, to gauge the effectiveness of the coins I am mining. Without knowing the number of accepted coins, that stat is useless. Why would we care what the DIFF was, in the stats?

This is not what it should be showing us... something is wrong... as per the readme and sample screen-shots...
Quote
Each column is as follows:
5s:  A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
Q:   The number of requested (Queued) work items from the pools
A:   The number of Accepted shares
R:   The number of Rejected shares
HW:  The number of HardWare errors
E:   The Efficiency defined as number of shares returned / work item
U:   The Utility defined as the number of shares / minute

I also notice it is throwing-off other stats... hope this throw-off isn't going to change the way the program makes judgement about connections...

Note: This is the windows compiled version 3.3.4, mining bottlecaps at the moment version 1.4.1.
Skitzzo
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
August 16, 2013, 08:33:42 PM
 #11974

I'm Karin! Cheesy

I keep a very close eye on the readme's (even following their changes on github), and I've tried using rc10 but if I recall it had no effect on this bug on Macs, so I instead include the latest libusb in my builds.

Kano makes it sounds like the error confidently lies within libusb, so I'll do a full spectrum of tests with various libusb versions.  If I can find a version that works I will update cgminer for Mac OS X and Asteroid (my Mac GUI to cgminer) accordingly.

Otherwise, we'll have to dig deeper into libusb, and any errors generated from cgminer (and what the community can help with) would be our best bet in figuring out the issue with libusb + Macs.  I'll try and do these test builds tonight and will post back with what I find.
I appreciate it! Let me know if you figure anything out. I'd be happy to help in any way I can and/or send you a small tip for your time as I'm basically sitting dead in the water until I can get this sorted.
kano
Legendary
*
Offline Offline

Activity: 2506
Merit: 1043


Linux since 1997 RedHat 4


View Profile
August 16, 2013, 10:48:02 PM
 #11975

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

This directly relates to the whole libusb monologue I've been having in here over the last month
That specifically means your libusb on your mac is bugged - the timeout option when doing I/O isn't working
The README says how to build with a working libusb and it works on Linux and Windows - no idea about a Mac ...
Tell whoever Karin is to read the README ...

Karin, read the README  Tongue
I'm Karin! Cheesy

I keep a very close eye on the readme's (even following their changes on github), and I've tried using rc10 but if I recall it had no effect on this bug on Macs, so I instead include the latest libusb in my builds.

Kano makes it sounds like the error confidently lies within libusb, so I'll do a full spectrum of tests with various libusb versions.  If I can find a version that works I will update cgminer for Mac OS X and Asteroid (my Mac GUI to cgminer) accordingly.

Otherwise, we'll have to dig deeper into libusb, and any errors generated from cgminer (and what the community can help with) would be our best bet in figuring out the issue with libusb + Macs.  I'll try and do these test builds tonight and will post back with what I find.
Yes the problem is clearly libusb.
As I have already stated, I can run two different libusb versions on the same architecture and one works while the other doesn't.
The test problem that I've mentioned in here a few times is standalone code (bits and pieces of the code I've written in cgminer - but modified) and that shows if timeouts are working ... and if they are matching the expected values also.

https://bitcointalk.org/index.php?topic=28402.msg2817682;topicseen#msg2817682
https://bitcointalk.org/index.php?topic=28402.msg2846296;topicseen#msg2846296
https://bitcointalk.org/index.php?topic=28402.msg2938585;topicseen#msg2938585

That specific version - libusb-1.0.16-rc10 - works on Linux and Windows
I've seen other 1.0.16 versions that don't work ... thus using the 'latest' libusb is not guaranteed to solve it.
Also, libusb has 2 sources: libusb and libusbx, and some OSs provide libusbx instead of libusb

The README also states how to use the libusb mentioned

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Trongersoll
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500



View Profile
August 17, 2013, 05:00:41 PM
 #11976

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
August 17, 2013, 05:16:09 PM
 #11977

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.

resize the window.  click on the box in top left, click properties.  go to layout and increase the window height.  you may need to restart it for it to take effect.  (I assume you're talking windows)

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
Trongersoll
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500



View Profile
August 17, 2013, 05:30:39 PM
 #11978

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.

resize the window.  click on the box in top left, click properties.  go to layout and increase the window height.  you may need to restart it for it to take effect.  (I assume you're talking windows)

M
actually, i'm using linux. I know how to resize the window, the question is how to cope when the biggest window that will fit on the screen doesn't have enough rows.
easynote
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


ELYSIAN | Pre-TGE 5.21.2018 | TGE 6.04.2018


View Profile
August 17, 2013, 05:51:11 PM
 #11979

I cant put this program work on my Win 8 64bits... its strange!

it shutdown after I put the data of pool, user and pass...

HERO/LEGENDARY




████████████████     ██                ██              ██    ▄████████████████      ████████████████     ▄████████████████▄    █████████████████▄
                     ██                ██              ██                                                                ██                    ██
                     ██                ██              ██                                                                ██                    ██
                     ██                ▀████████████████▀    ▄████████████████▄            ██             █████████████████     ██             ██
█████████████        ██                        ██                            ██            ██             ██             ██     ██             ██
██                   ██                        ██                            ██            ██             ██             ██     ██             ██
██                   ██                        ██                            ██            ██             ██             ██     ██             ██
██                   ██                        ██                            ██            ██             ██             ██     ██             ██
████████████████     ████████████████          ██             ████████████████▀     ████████████████      ██             ██     ██             ██
 
█     █
█    █
█    █
█    █
█    █
█    █
█    █
   
█    █
█    █
█    █
█    █
█    █
█    █
█     █

█     █
█    █
█    █
█    █
█    █
█    █
█    █
   
█    █
█    █
█    █
█    █
█    █
█    █
█     █
▄▄█████████▄▄
▄█████████████████▄
▄█████████████████████▄
████████████████▀▀  █████
█████████████▀▀      ██████
██████████▀▀    ▄     ███████
███████▀▀     ▄█▀     █████████
███▀▀      ▄██▀       █████████
█████▄    ██▀        ██████████
████████ █          █████████
███████ █ ▄███▄▄   ████████
████████████████▄▄███████
▀█████████████████████▀
▀█████████████████▀
▀▀█████████▀▀
TOKEN GENERATION EVENT
JUNE 4 UNTIL JUNE 24  [ WHITEPAPER ]
[TWITTER] [FACEBOOK] [REDDIT] [STEEMIT]
twmz
Hero Member
*****
Offline Offline

Activity: 737
Merit: 500



View Profile
August 17, 2013, 06:21:07 PM
 #11980

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.

resize the window.  click on the box in top left, click properties.  go to layout and increase the window height.  you may need to restart it for it to take effect.  (I assume you're talking windows)

M
actually, i'm using linux. I know how to resize the window, the question is how to cope when the biggest window that will fit on the screen doesn't have enough rows.

Use --compact mode and stop get per device statistics from the API (some kind of dashboard, etc) instead of by looking at the screen.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
Pages: « 1 ... 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 [599] 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 ... 847 »
  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!