Oh, the gods were angry at me last week. Very angry. They not only put me through the hell of completely destroying my computer (or so I thought), they also influenced me to exhibit my geek stubbornness and not replace anything, but instead break out the soldering iron and spend some frustrating hours soldering wire traces together that should never be attempted by mortal man.

In the end, I guess it was worth it. I mean that I stubbornly decided to fix things instead of junking my fantastic (and now old) computer. And I have the Zalman Reserator completely to blame for the whole thing.

The Zalman is a water cooling device that has no fans. Before, my computer had a total of 6 fans keeping it cool (CPU, Case, Graphics Card, and 3 in the power supply). Turning it on was similar to the noise of jet aircraft taking off from an aircraft carrier. Now it has just one, and it’s barely audible. The Zalman itself is inaudible and works flawlessly, so I feel somewhat bad for placing the blame on it. But how did this great travesty begin?

Due to the small yet real influence the angry gods had on me that fateful Thursday, my hand slipped as I installed the new heatsink of the Zalman onto the CPU, and suddenly a few copper traces were now exposed to the world in a way that god had not intended. They had, in fact, been severed by the edge of my needle nose pliers, and – as much as I tried to ignore the cut traces – the computer simply wouldn’t boot despite all of my anguished bleating. Yes, it was a sad time.

After a restless night of tossing and turning, dreams of soldering teeny tiny wires and conductive pens made for gnomes that could fix my sub-millimeter problems, I awoke the next day with newfound energy for fixing things, and putting my world back in order. I mean, how hard can it be to fix some silly wire traces coming from a CPU on a PCB? It’s got to be POSSIBLE, yes?

Now if I actually had some sort of measuring device to tell you how small these traces were, then I’d tell you. But I didn’t. My best guess is that they were 0.000001 mm wide. Well, they seemed that small anyway. Take a look at them – see the shiny colored copper areas? I had at this point scraped some of the coating off to inspect the damage and prepare for soldering.

Notice how there are two traces next to each other? Yes, that makes for a lot of fun – they are so close together that it’s not easy to get solder on just one trace without hitting the second one. To get an idea of the size of these traces, look at the socket on the left – the holes are for the CPU pins. The traces are less than half the width of the holes that the CPU pins fit into.Now if I actually had a soldering iron worth a damn, or some kind of PCB repair kit or a conductive pen with a tip the size of a mosquito’s schwanz, then I’d have been optimistic. But all I have at home is a Harry-Homeowner-I-Solder-Once-A-Year iron to work with. On the positive note, I can now tell you that it can be done. Even with crappy tools.

So here is what I had to do. First of all, I had to make a suitable tool to solder with – which meant taking that ugly soldering iron tip and sharpening it to a point. Any self respecting geek will have a dremel tool (or a cheap knockoff like me) with the appropriate grinder tip to do this with.

While certainly not the best tool, if you’re desperate like I was, then this will do. This is pretty easy to do.

The next thing to do was to rip apart a copper stranded cable and get a thin coating of solder onto several strands. This part is pretty easy as well – it just meant grabbing any old electric cord, chopping out a section, and then getting a coating of solder onto each of the strands.

At this point, things were going pretty well. But after this point, things got a lot hairier.

I don’t know if anyone in the world does this kind of PCB repair for a living, but one thing is certain – they probably have the correct tools to do it with. And they must also have a lot of patience.

I spent a few hours fiddling with these small wire strands and attempting to solder them to the broken traces. And yes, I was extremely pleased when I finally got the traces repaired. This involved touching the wires quickly with the iron while they were on top of the metal traces (to get them to initially stick) and then afterwards applying a small bead of solder to make sure that they stayed stuck in place. This was a lot harder than it sounds. But in the end, the wires were stuck. I mean, how geeky is that? Here is what my terrible soldering job looked like (there is a metal stud where the hole was in the previous picture).

Ugly, but functional (or so I thought). After getting finally getting a post, I quickly assembling things in my ignorant optimism – with it only to refuse post at all after the assembly was complete.

After another deconstruction, lots of coffee, re-heating the solder contacts, conductivity tests- it looked like things were actually going to work.

And here I am writing this blog entry on the one and the same, with those very horrifying looking solders (but with the naked eye you can’t really see how bad they look). And yes, I didn’t have any microscope or special magnifying tool to help with this.

So what’s the point? Perhaps I can at least encourage someone out there that has jammed a screwdriver into their motherboard to try to fix it, even if you only have primitive tools – there is at least one other person out there that has successfully done it :)

Of course, now that I’m concerned that the solder joints might “go bad” in the future, I guess it’s time to start looking for an upgrade. Now that I have a good reason, that is, I’m looking forward to it!

BTW, the Reserator works great, but one missing point in the instructions led to me sticking a tool in the computer in the first place, which wouldn’t have happened otherwise. There is a mounting plate on the bottom of the motherboard directly below the CPU which has to be swapped when installing on a socket 939 board (in my case, with an ASUS board, it was glued on, so it took some careful prying to remove it). However, if you follow the picture instructions that come with the Reserator, you’ll install it upside down like I did, and then the nuts will pull through when you attempt to tighten the metal pegs that hold the heatsink bracket. And if you’re as unlucky as me, you might even cut some traces along the way.

A friend of mine brought a NTFS (Windows XP) hard drive that had been “erased” by a virus of some kind. I said I’d try to recover the lost data, which was unreadable to Windows.

After wasting some time undeleting a bunch of garbage on some other unimportant partitions, I realized that the main NTFS partition had not been automatically mounted for me - meaning there might be a problem with the partition itself. After manually attempting to mount the partition, I got a message that the boot sector was corrupt. So what to do?

NTFS partitions have a backup of the boot sector located on the last sector of the NTFS partition. There are probably various programs out there that one can pay for to restore this backup copy to its rightful place. There might even be a “Microsoft way” of doing things, which I can only guess requires you to agree to the terms of some EULA and give away any rights you have to your great collection of polka MP3s. Instead, all you need to do is this one line (as root):

mount -t ntfs /dev/sdg1 /media/tmp -o errors=recover

where you need to replace “/dev/sdg1″ with your NTFS partition location (I connected this drive with an external USB carrier) and “/media/tmp” with the location you’d like to mount the fixed partition. That’s all! Once you’ve mounted it, it’s fixed automatically and might even be bootable again (if this is the only problem you have).

This will even work if you accidentally begin to copy data over the beginning of your NTFS partition, since the copy of the boot sector is at the end of the partition. Note: This only works with kernel versions 2.6 and newer.  Can’t get a much easier fix than that!

Ok, this isn't really a complete "HOWTO" - it's just a summary of the experiences I had with getting NVidia drivers to work properly with a 64-bit Linux distribution with my current hardware (although this will equally apply to a 32-bit distro).

It seems that there are an ungodly number of things that can go wrong (when they do go wrong) with NVidia drivers on the Linux platform. Usually things work fine after installation, be it by using the supplied NVidia installer or whatever method your distribution suggests. Unfortunately, my problem was unsolvable by all means that you will find on the web. That's right: I went through everything short of replacing my entire PC to solve this problem. What was my final solution? Well, if you're looking for a solution to your own NVidia woes, I would suggest you not read the rest of this paragraph and skip to the next one where I give you some hints on what to try when troubleshooting. My solution: I flashed the video card BIOS to that of a completely different vendor. While that doesn't make sense that you'd have to do this (and you won't find anyone from NVidia that will suggest you should do it), it was what I had to resort to to get things to work.

Symptoms: When any 3D (openGL) application is started, the PC will lock up hard - usually requiring a manual reset (meaning finger push button reset). The PC may not lock up hard, but freeze and become garbled instead; you may even be able to continue working but with a garbled screen (I couldn't). To reproduce this problem, simply run 'glxinfo' in a console - that should be enough to do it.

This occurs at least with the following distributions: Gentoo Linux, Ubuntu, and Suse - regardless of whether a 32-bit or 64-bit distribution is being used.

My hardware:
Motherboard: ASUS A8N32-SLI Deluxe
Graphics card: Gainward 7800GT PCIe
HDD: 2x Maxtor 6V300F0 300GB
PSU: 650 Watts
CPU: AMD X2 4400
RAM: 2x 1GB Kingston DDR400

First of all, you have to have actually successfully installed the NVidia drivers. Unless you've disabled it, you will see an NVidia splash screen when X starts. If you don't have this part right, then there are many resources on the web to help you depending on your distribution. It's usually always better to do the install using the method your distro prefers: emerge on Gentoo, apt-get for Ubuntu, or yast for Suse. If you instead try to use the supplied installer from NVidia's website, you could run into library problems later (which is the case with Gentoo).

Here is the list of things to check when you have the lockup problem (in no particular order):

1 - Passing Kernel Parameters

There are some kernel parameters that may or may not influence the performance or stability of the driver. They are:

You should try passing these to the linux kernel when you boot - or some combination of them. "noapic" and "acpi=off" seem to be popular.

2 - IRQ Conflicts

Your NVidia board should have an assigned IRQ. When the nvidia driver module is loaded, execute this:

You should see something like this:

Of course your output will look different. The point here is that the "nvidia" module has an interrupt number, and that it doesn't share it with other peripherals. In my case you see that it is sharing an interrupt with ohci1349 (firewire) and sky2 (ethernet) drivers. Try disabling or moving the peripheral that is sharing an IRQ number with the nvidia module. I disabled the hardware that shared with the nvidia card (of course, to no avail).

If you have no interrupt assigned to your video card at all, check that in your BIOS settings (of your motherboard) that you have "Assign IRQ to Video" enabled (or something similar).

One more note: the "type" of interrupt assigned to the nvidia board should be "level", not "edge". The driver module probably won't load if it is not "level".

It has been noted that Creative boards (SoundBlaster whatever, Audigy, etc) like to conflict with NVidia boards. If you have one, move it to a different slot or take it out temporarily for testing.

3 - Check For a Motherboard BIOS Upgrade

Normally there should be no reason to upgrade your motherboard BIOS. On occasion, something may have been fixed; but more often than not you're bound to introduce a new problem. If you start asking around for help from NVidia, they will tell you to do this, even if you're sure you don't need to (or if there is no update available for your board) - so you may as well get this item out of the way.

4 - Strange Motherboard Settings

Some BIOS settings can interfere with your NVidia card. If you have a disabled NX/XD-Bit (NoeXecute/eXecuteDisable) , you should try changing that. If you have onboard virus protection, disable it. If you have overclocking related BIOS options, turn them off. For example, my ASUS has an automatic overclocking feature - it should be disabled (later you can turn it on if you get things working, of course). Also, "PEG Link Mode" should be normal.

While you're at it, you can disable all onboard things you're not using: firewire, USB (if you can deal without USB mouse/keyboard), serial / parallel, audio, etc. That way you can eliminate them as possibly conflicting with your NVidia card.

5 - MEMTEST86

Ok, this should actually be #1, but I had assumed in the beginning that your system already has a known good and stable configuration. This is absolutely essential: run memtest86 . Some say you should run it for 10 hours (or overnight); the only time I ever found errors on a bad RAM module they appeared after a minute or less.

If you have an Ubuntu or SUSE boot CD, it has memtest86 as an option (it can't get easier than that). Otherwise, download this small (but excellent!) recovery CD and choose the memtest boot option.

If you have any RAM problems whatsoever, you need to fix this first - it's probably the culprit.

6 - AGP and Your xorg.conf File

There are a couple of settings that could affect your stability issue; primarily if you are using AGP (I am not). I haven't heard that these affect PCIe in any way, but I'm putting this here anyway since it seems to be a common problem among lots AGP users. From the NVidia README:

Option "NvAGP" "integer"

Configure AGP support. Integer argument can be one of:

Value	Behavior	0	disable AGP	1	use NVIDIA's internal AGP support, if possible	2	use AGPGART, if possible	3	use any AGP support (try AGPGART, then NVIDIA's AGP)

Please note that NVIDIA's internal AGP support cannot work if AGPGART is either statically compiled into your kernel or is built as a module and loaded into your kernel.

Try 0 and see what happens. If it works, then you have AGP issues. You might have to remove AGPGART support from your kernel and use the right NvAGP option.

Also, look for "RenderAccel" and give it the parameter "false":

Option "RenderAccel" "false"

Later you can enable this if you get things working.

7 - Manually Upgrade Drivers

Even though I said you should use the proper installation method depending on your distro, try uninstalling the drivers and getting the newest from NVidia's website. Note: If you have an older NVidia card, you need to use the "Legacy" drivers supplied by your distro (and by NVidia).

Be careful with updating your drivers this way, as you can end up with library problems / improper links that could lead to further problems.

8 - Incompatible Libraries

It has been noted on some distros (Gentoo) that if you install the driver using NVidia's install mechanism instead of the default "right way" (emerge, apt-get, urpmi, whatever) you'll run into problems with old libraries lying around in places they shouldn't - which end up causing conflicts and odd behavior. If you've done this, then I can't really help you - but you should probably start by uninstalling any versions you have installed and manually looking for leftover library bits and removing them. Good luck.

9 - Reinstall X, Mesa, and Dependencies

Ok, this is a pain to do, but it's one of the things I did. Completely reinstall X and its dependencies - or if it's easier, just reinstall your whole distribution.

10 - Different Distributions?

Ok, perhaps a different distribution will fix your problem. Why? Well, different kernels might work differently with your board. If you don't mind trying out a different distribution, give this a shot. You won't find the real cause of your problem this way, however.

SUSE linux was the only distro I tried that worked 100% perfectly after an install (it detected my motherboard, and that I have a RAID controller, which it informed me would not be supported in RAID mode, which I already knew but no other installer chose to tell me). Ubuntu, Mandriva, and Gentoo could give you anywhere from a few to many niggles after installation.

11 - Vanilla Kernel Compilation

Another thing that NVidia support will ask you to do (this means go to kernel.org and get the latest official stable release and use that as your kernel). When you do this, I recommend only enabling the bare minimum you need (and the options that are required for the NVidia driver - see this page for more info.)

12 - Stability / Heat Issues

If you are actually able to use the drivers for 3D applications for a short period of time (and thereafter a lockup), then you don't have the same problem as I did, but you might have a stability problem due to overheating. You can monitor the temperature of your GPU in Linux, but I won't go over how to set that up. If available, I would suggest borrowing Windows from a friend, installing it and the NVidia Windows drivers, and then installing the NVidia NTune utility. It should come with a stress test that will notify you of any stability problems. While you're at it, check to see if 3D applications work properly in Windows for you (in my case, they worked flawlessly).

If you do have a heat problem, you probably should return your card. If you can't, then you could attempt to pull off the fan/heatsink contraption and apply fresh thermal paste to the offending chips. Google around for guides on how to do this.

One more thing: cheap power supplies will give you never-ending stability issues. Make sure that you have a big enough capacity power supply. Also, not all power supplies are the same: 500W from one brand will not "be the same" as 500W from another manufacturer. If you have a no-name cheapy powersupply with borderline specs for your system, get a newer better one (I did this unnecessarily - but it was cheaper than getting a new MB or video card).

13 - Maxtor Drives and NForce Incompatibility

The particular model drives I have (Maxor 6V300F0) have a nasty bug that causes instability with NForce chipset motherboards. Not all drives have this bug; certain firmware revisions do. There is a fix out there that Maxtor will not give you for some reason. Do a search to find out where to download the fix (I don't have it; I didn't need it, since my firmware revision was new enough). I don't know why Maxtor won't give out the fix (probably they are afraid of helping a hard drive firmware hacking scene, where people simply change the firmware in their drives that are identical to other models and gain hundred of extra gigabytes. Well, that's my guess.) In any case, I don't think I will be buying Maxtor again.

Last But Not Least : Video Card BIOS

None of the above items were in any way related to my problem. In the end, I took my video card (Gainward 7800GT) and flashed the BIOS with one from an eVGA 7800GT.

Initially I flashed with a slightly newer version of the Gainward 7800GT ROM, but that made absolutely no difference. I wrote the possibility of a BIOS problem off at that point. Later, short of buying a new board, I took the leap of faith and flashed with the eVGA BIOS.

So why does this work? What is the problem? Why should the BIOS affect whether or not the NVidia drivers will work on a particular platform (fine on Windows, but not on Linux)? I expect that NVidia won't answer this.

If you have the same problem as I did, you certainly won't get an RMA - your card works fine on Windows. There is no detectable issue with the card. And you are voiding your warranty by flashing it to that of a different vendor - but what other choice is there? Buy a second video card and cross your fingers?

Go to the site http://www.mvktech.net to find the right ROM and flashing utility. Of course, you shouldn't do this - but it was the only solution that worked for me. You very well might destroy your video card. Note: When flashing to a different vendor, you'll have to specify some flags to override the original vendor information.

One thing I found out from this whole debacle was that NVidia does not officially suggest or support any particular Motherboard/Video Card combination on Linux. So if you want to play it safe and buy a combination of hardware that just works - well, don't ask NVidia. If you're a home user like me and can't afford to drop $300 a pop on new video cards just because the one you bought has a non-detectable BIOS issue, well - good luck.

So as a last resort, you might want to try what I did and flash the your video card BIOS. But do a little research first and make sure your card is practically the same as the BIOS you're flashing to (I just made a wild-ass guess). If you flash it to a wrong BIOS, you're gonna end up with a nice decorative circuit board for your Christmas tree.

If anyone else out there had to do this, I'd appreciate hearing the details.

I've been pretty excited about getting a new desktop ever since my last one decided to stop working. But of course - I'm not the kind of person to buy a ready-made system, I want to pick my components a little more carefully and really know what I'm getting. I've never had problems doing this in the past (ever since my 386, I've been building my own PC's. Actually, that's not completely correct - I once built an IBM 8088 system out of spare parts, which I used for a long time). This time around has been quite - educational - I guess. And extremely frustrating.

First of all, let me get this out of the way: The Worst Computer Store I've ever attempted to purchase something from. I say "attempted" because I've paid, but as of today (14 days later), I still don't have anything. Maybe I'm spoiled by the "normal" way I expect online stores to work: you pick what you want, you pay, and then they ship it to you. Sounds simple, but I guess it isn't always - like in this case.
Read the rest of this entry »

My normal desktop (of over 3 years) crashed a couple of weeks ago. Now, I'm no newbie, I can fix just about anything (or waste a lot of time trying) - but I decided that this time I'd just buy a new computer.

The faulty component was the motherboard - the capacitors were going bad and something had caused the power connector to burn at the connection point on the MB. The CPU works fine, as well as everything else; but I decided that I can buy myself a new PC since I spend so much time using the thing.

So, the new specs are now going to be :

AMD Athlon 64 X2 4400+ (a dual-core CPU, each with 1MB cache for a total of 2MB cache on-die)
ASUS A8N32-SLI Motherboard (with onboard everything except graphics, a heatpipe for cooling, 2 16x PCI express slots with separate data channels)
2.5GB PC3200 RAM
NVidia 7800 GT Graphics card (with SLI)
2x Western Digital SATA-300 250GB drives in RAID mode (for one fast 500GB drive), plus a pair of normal IDE drives for data storage (~800GB total)

... and the rest of the hardware stuff is not so important. I'll be installing Gentoo Linux as my base OS (64-bit goodness, of course), with a real install of WinXP 64 Bit Edition for gaming (I dont know if it is actually better to use the 64-bit version versus the 32-bit one as far as games go), followed by two virtual machines : one with Mandrake Linux (to stay compatible with some of the software I am developing), and one with Windows XP (also for development). In a year or two when the cost of the graphics cards go down, I'll get a second one to run them both in SLI mode (where they both share the processing).

Geeky.

I've just decided to get back into microcontrollers, and I wanted to start out with a cheap programmer for a cheap PIC. The simplest one I found (and it's REAL cheap) is right here. It connects via parallel port, and is capable of programming the PICMicro PIC16F84 and similar chips. I'll post pics when I build it (if I do). Anyone know of any good robotics projects I should take a look at?

I'll probably just end up testing the PIC with some simple programs, and once I get a handle on it, I'll start thinking about a real design. Here is a good page with some projects to look at to start. Note: These sites aren't new, just new to me