Share This

Share This

I reinstalled the 680i chipset drivers I had downloaded from ASUS web site again and again with no luck. I had also some issues with my USB2.0 speeds.

I came across with the nvidia web site and I tried to download my drivers from that place . I chose the proper combination of product and OS and my system now fires up in a couple of seconds and after watching 5 movies I have not noticed that lagging.

I am not sure whether there is any difference in the driver, as they seem identical, but I thought of posting thisexpereince in case that helps someone who has similar issues.

Share This

In this article I demonstrate a way to achieve this using rdiff-backup, assuming that both (the workstation and backup server) can be accessed via ssh through their gateways. In this case both source and destination have ssh server installed which are simply not accessible directly from the outside world. However you can reach them if you first ssh to their gateways and then ssh to the final destination.

(Note: The easy solution would be to setup some sort of forwarding to one of the firewalls but if the IT support is incompetent to do so, afraid not.)

rdiff-backup is an excellent tool to perform incremental backups of your valuable data. The basic function of rdiff-backup is to copy all the data from a source directory to the target and subsequently only records differences (diffs) of the files/directories which have changed and creates a snapshot. It is important to understand its advantage over other backup methods such as rsync and this is that it does not only syncs the two directories, but it also keeps the history of the changed files, in case you want to retrieve an older snapshot of your data. Finally the tool would not be so useful if it could not operate over that network.

A typical rdiff-backup command would look like this:

rdiff-backup source destination

The source and destination can either be a a local directory (/path/to/directory) or remote directory (hostname::/path/to/directory) the source and destination arguments are same as those used in scp but you must use double colon character to separate the host name from the path when defining remote directories.

For the discussion purposes let’s assume that the back-up server initiates the backup, retrieves the snapshot and exits. The host name of the workstation we have the original data is workstation and that of the remote gateway is remoteGateway. A command like this will fail because the workstation can not be accessed directly with ssh.

rdiff-backup workstation::/path/to/original/data /path/to/backup

The trick is to use ssh tunnels to reach the workstation. On the back-up server open a terminal and run the command

ssh remoteGateway -L localhost:8000:workstation:22

This will create an interface to the workstation’s ssh server on the backup server (localhost) which operates on port 8000 instead of 22 where ssh normally runs. This command creates a tunnel and any traffic send to localhost port 8000 will be forward through the ssh tunnel between the back-up server and the remoteGateway to the workstation. Hence if you open another terminal and issue the following command you will reach the workstation’s ssh server.

ssh -p8000 localhost

So now you can run rdiff-backup on localhost port 8000 which is actually the workstation. But you need one more trick to make it work. You have to tell rdiff-backup that the ssh sever runs on port 8000. This is done using the switch remote-schema. A command similar to this one will start the back-up process.

rdiff-backup -v6 –print-statistics –remote-schema ’ssh -p8000 %s rdiff-backup –server’ localhost::/path/to/original/data /path/to/backup

To automate the process you can create a bash script to open the tunnel for you and then run the rdiff-command. You can put it in your crontab to schedule daily backups.

#!/bin/sh
ssh remoteGateway -L localhost:8000:workstation:22 -N &
sshpid=$!
sleep 5; # Allow some time for tunnel to get established.

rdiff-backup -v6 –print-statistics –remote-schema ’ssh -p8000 %s rdiff-backup –server’ localhost::/path/to/original/data /path/to/backup

sleep 5; # Allow some time for rdiff-backup to exit
kill $sshpid

Share This

I guess there are plenty of people out there who have purchased the ASUS Striker Extreme motherboard and are now disappointed with their choice and definitely frustrated with ASUS. Those where my feelings, too.

After wasting tens of hours on internet searching and many more on clearing my mobo’s CMOS, I think I found out the solution, which I would share with all the folks out there who experience the same issues.

If you get the CPU INIT error message and you try to clear the CMOS, but the mobo seems dead, then probably your problem is your memory’s voltage.

Briefly, my mobo seemed dead, with no beeping, no posting. The only thing I could see was the CPU INIT message on the mobo’s LCD. However, the CPU fan together with all the mobo’s leds where on, which means that there was voltage across it. I tried all the possible ways of clearing the CMOS, with and without cards, swapping memory stick or sticks and so on, but with no results.

Your mobo is most likely fine if the CPU fan works and here is the way to bring it back to life.

First of all you need to have a low specification RAM, running on probably 667 MHz, but the most important of all is the memory voltage. The memory needs to run with 1.8 Volts. The OCZ 9200 I got uses 2.3 Volts for operating, which is far away from 1.8 Volts. Note that the default settings for the memory voltage on your BIOS is set to AUTO, which is actually 1.8 Volts. This is probably the reason that you cannot clear your CMOS with high data rate modules, as all of them use higher voltage than that.

Step 1

Remove all the power cords including the 24-pin ATX connector (EATXPWR) and maybe the 2×4 (8-pin EPS) or 1×4 ATX12V connector (the one which powers up the CPU and is located just next to it).

Step 2

Remove all the cards including your graphics card

Step 3

Place only one Memory Stick at the last slot (the one further from CPU).

Step 4

Clear your CMOS. If you don’t know or you are not sure how, CLICK HERE.

Step 5

Put the graphics card on.

Step 6

Connect all the power cables, including the 24-pin ATX connector (EATXPWR) and the 2×4 (8-pin EPS) or 1×4 ATX12V connector.

Step 7

Power UP

You should now hear the desired BEEP and the motherboard should normally post. If everything works fine, shut down your PC, remove the low performance memory stick and install the high rate memories. During the posting enter the BIOS and change the memory voltage from AUTO to the appropriate value.

Please note that, if you do not have the newest BIOS version you should do so as soon as possible. My BIOS version is currently 1102, which is the latest. If you notice on the BIOS updates, there are many memory combatibility issues fixed on each updated version. Therefore the very first thing when you bring the motherboard in life is to update the BIOS keeping the low performance memory and then install the high data rate memory sticks.

In case that you have any query about the process mentioned in this post or you did not eventually brought your motherboard back to life, please feel free to leave your message here.

You can also leave a message to let other people know what you have experienced and of course whether this trick worked for you or not.

Share This

Share This

Share This

Share This

Share This

Share This