Skip to content

Linux

Upgrading the CPU in a Dell Studio XPS 1640

While the default Dell Studio XPS 1640 is fast and is a decent work laptop, it needed to do one extra thing, run virtual machines (VMs). I spend a lot of my time debugging, hacking and otherwise trying to make software behave in ways that the developers had not intended.

Tools like VirtualBox, VMWare, Xen and QEMU make this job less tedious. The problem is that with the Intel T7350 CPU, I cannot run 64 bit VMs. Turns out that T7250 is a 64 capable chip, but without the VT-x extension which allows for hardware assisted virtualization.

Look your Intel CPU up to see if it supports the VT-x flag. It turns out upgrading your CPU is relatively easy as Dell did a good job in designing the laptop. The instructions are all in their online service manual.

Replacing CPU in a Dell Studio XPS 1640

The only hard part is figuring out what CPU is compatible and then buying it. Thankfully my company had no problem ordering an upgrade and after the first successful attempt, they ordered more for my other colleagues as well.

When picking an upgrade CPU, you must find one your motherboard supports. Your best and most compatible guess is to choose one in the same family as your own CPU, essentially a later model. Since the T7350 has a 1066 front side bus (FSB) , 45nm process and takes 25W, it is then easy to find a similar CPU with those values but at a much higher clock rate and L2 cache, and most importantly, VT-x flag.

Wikipedia has a list of all mobile processors that have the VT-x flag.

  • Mobile Core 2 Duo T5500, T5600, T6670, T7100, T7200, T7250, T7300, T7400, T7500, T7600G, T7700, T7800, U7500, L7200, L7300, L7400, L7500, L7700, U7500, U7600, U7700 (Merom)
  • Mobile Core 2 Duo SU7300, SU9300, SU9400, SU9600, SL9300, SL9380, SL9400, SL9600, SP9300, SP9400, SP9600, P7350 (mac),P7370, P7550 (confirmed), P7570, P8400, P8600, P8700, P8800, P9500, P9600, P9700, T8100, T8300, T9300, T9400, T9500, T9550, T9600, T9800, T9900 (Penryn)

A successor of the T7350 (Merom-2M) is the P8700 (Penryn-3M) and fits all my requirements to fit in the laptop. It is faster and more importantly has the VT-x flag and is easily found online for very cheap.

The installation went without incident and upon reboot I entered the BIOS and enabled the "Hardware Virtualization" option. Saved and rebooted, Virtualbox finally gave me the option to create and run 64-bit VMs.

An additional note: Updating (Flashing) the BIOS is not necessary. The BIOS checks to see if the CPU has the flag or not and will not display the "Hardware Virtualization" option if the CPU does not support it.

vNES for J2ME on your mobile

If you have ever wanted to play a NES game on your mobile, then you might have heard about vNES. There is a J2ME version which allows it to run on most mobiles available today. There are however a few rough edges to this application as it requires assembling the necessary files together and running a windows batch file. From a Linux point of view, I have created a replacement shell script that does a better job. It requires unix2dos, rename, and bash.

Just place this file into your vNes directory: makejar.sh

#!/bin/bash
cd roms
#uppercase all our roms
rename 'y/a-z/A-Z/' *.nes
#remove all spaces, shorten name
rename "s/ *//g" *.NES
#rename roms to png
rename 's/\.NES$/\.png/' *.NES
#create our list of roms
package=""
for file in `dir -A` ; do
    package="${package}${file%.png}\
"
done
echo -e $package > ../package.txt
cp *.png ../package
cd ..
#make sure list is with windows line breaks
unix2dos package.txt
cp package.txt package/2.txt
cd package
#package everything up
zip -r -9 ../vnes.jar *
cd ..

Be sure to set: chmod +x makejar.sh

General advice:

The NES rom files must be in iNES format, and also be renamed from *.rom to *.png and copied into "package" directory. There is a file in "package" called 2.txt which is a list of all the roms you have. Rom names should be in capital letters, with .png at the end, not .rom nor .nes. Example: castlevania_3.nes --> CASTLE3.png and in 2.txt add a new line with 'CASTLE3' without the '.

Here are a list of possible problems:

This usually means that something is not right with 2.txt, make sure this is an extra line at the end of list. Use a space if you have to and remember use Windows based EOL 'end of line' characters. It helps to use 'unix2dos' to convert your \ to ^M.

You get the "application is invalid" error message:

Delete the line "MIDlet-Data-Size: 1024000" in the file "package\META-INF\MANIFEST.mf", this line tells the mobile how big the java application is. Problem is some mobiles just do not agree with that size and as a result will refuse to run a slightly dodgy application. It is best just to remove the line for maximum compatibility.

When loading a rom you get "java.lang.NullPointerException" error message:

This is because the rom file either does not exist in the package dir, the name is spelled incorrectly in the 2.txt file, or that there are wrong line endings. Verify that the files exist as *.png in the 'package' directory and to be safe, run unix2dos or todos on 2.txt file make sure the line endings are correct. The application expects dos ^M line endings.

SSH Multiplexing: a faster way to SSH

How it works:

By changing the way you ssh to a machine, you can reuse your initial ssh connection to save time when connecting.

Edit your ~/.ssh/config file to have this:

Host * ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h:%p

We avoid problems of reusing the default /tmp but storing our connections in their own directory.

Be sure to create the directory:

mkdir -m 700 -p ~/.ssh/sockets

When was it available:

The functionality has been available since OpenSSH 3.9.

Usefulness:

I has come in handy for those hard to type passwords. Once in, a repeat ssh on another (local) terminal to the same machine will take just a few miliseconds and you have a command prompt to work with.

Security:

One caveat is that this is on a per-user basis, so if you want to connect with a different username then you will have to initialize a new connection. This also means that anyone using your machine can then reuse your connection to log into the remote machine. This could be a security issue for you.

USB not showing up in VMware

For the longest time USB used to work quite well in VMware, then as if by magic, it all stopped working. However, after poking around I've discovered that there is a solution and it involves usbfs (usbdevfs). So here is a solution to get you all back up and running.

  • Create a new user group and name it usbfs, let's say that it has gid 1003
  • within /etc/fstab change the following line usbdevfs /proc/bus/usb usbfs noauto 0 0- if you have it, change it to below, if you don't have it, then just add the following line usbfs /proc/bus/usb usbfs rw, devgid=1003, devmode=0640, busgid=1003, busmode=0550, listgid=1003, listmode=0440 0 0- add vmware users to group usbfs usermod -G usbfs vmwareuser- If you get an error like this: mount: mount point /proc/bus/usb does not exist - then you have to compile a custom kernel from sources with CONFIG_USB_DEVICEFS enabled.

SSH with Public Key Authentication

Okay, say you have a server, you have to ssh to this server ... say 20 times a day? It gets irritating having to login and type your password repeatedly. Not to mention it can be insecure if anyone is sniffing the network.

So on your desktop machine you want to create some keys. This can be done with the following command:

ssh-keygen -t rsa

At the prompts just press enter for all the defaults. This includes an empty password.

Now you should have a file in .ssh/id_rsa.pub , this file has to go to the server. You can do this with this command

cat .ssh/id_rsa.pub | ssh username@servername "cat - >>.ssh/authorized_keys"

All going well, this should exit cleanly. Test it by ssh'ing again to the server normally, if all goes well it shouldn't prompt but just drop you into your remote shell. If this fails make sure your servers /etc/ssh/sshd_config has the following line

RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys

Also, you will need specific permissions in order for this to work as well, so the follow needs to be run as the user you are logged in as.

server$ chmod go-w ~/ server$ chmod 700 ~/.ssh server$ chmod 600 ~/.ssh/authorized_keys

Enjoy your keyless SSH access.