I have the following system:

• Shuttle SP35P2 (BIOS: SP35S20J)
• Intel Core 2 Quad Q9550
• 8 GB RAM
• GeForce 8400 GS

Instead of putting a hard drive in the box, I got an iMicro IMMR300B, which goes into a 5 1/4" drive bay and allows easy swapping of 3 1/2" drives. Since the CD-ROM door prevents this from being properly installed, I stuck some rubber feet to the bottom and ran the SATA and power cables through the open area where a PCI card would go. I have four 250 GB drives from a dismantled RAID box and this way, I can install different operating systems on each one and just swap them when I want to boot a different OS.

This system ran just fine for a while, but at some point, the network quit working. After running for about 10 or 15 minutes, it would just stall out. This happened in Vista (x64), Win7 (x64), OpenSolaris, and Ubuntu (x64). After a while, I got it working but I noticed that it only had a 100mb link instead of a 1000mb one. When I briefly disconnected and reconnected the cable, I got the 1000mb link, but it would stall out again. The first time this happened, I think I fixed it by installing the latest drivers on a Vista x64 installation from Marvell's website, which were newer than the ones on Shuttle's website. After that, it worked for all OS'es.

A few days later, it happened again. This time, I noticed what triggered it: installing FreeBSD 7.2! The system would run fine in Vista x64, Win7 x64, and Ubuntu x64 (JJ), but installing FreeBSD 7.2 (x64) would not only make it stall out after about 10 minutes, but make it stall out after about 10 minutes no matter what OS was installed! Powering the system down, swapping the harddrive, and booting up an entirely different OS had no effect!

I did some research. I found several reports of issues, some debates as to whether or not Marvell devices were even supported in FreeBSD, and some cryptic tools for doing some low level diagnostics and reprogramming of the network chip itself. Some of the posts before the link to the "do this at your own risk" reprogramming tools had some interesting information: the version 1.2 firmware (which I had) has some known issues and upgrading to 2.2 would fix it. I looked at these tools and decided against digging up a DOS boot disk and trying to figure out which firmware file was right for my chip.

I finally called Shuttle's tech support and immediately got through to a nice guy who listened to my problems and assured me that this was a very stable platform and it was possible that there was a hardware problem. I mentioned the ethernet firmware upgrade and he didn't think that it was possible - the only firmware is the BIOS. I could send it in and if they determine that something is wrong, they would fix it, but if they couldn't find anything, I have to pay $55 or something for their time. He also recommended setting the BIOS settings to default after upgrading the firmware. I did try resetting the BIOS settings, but it had no effect.

Some more digging surfaced this post. This one had a nice little utility that would upgrade the ethernet chip to version 1.4. I decided to give this one a try. After connecting a floppy drive and finding a working disk, I successfully ran the program and sure enough, my ethernet chip now had a firmware of version 1.4. While this did seem to make it work reliably in Windows and Linux again, another attempt at installing FreeBSD quickly put it into 'bad' mode.

After that, I saw that Shuttle made available a 'J' version of the BIOS (I had 'F'). I updated the BIOS and even though the notes didn't mention anything about the network chip, it seemed to resolve the stalling again. I even installed FreeBSD and it ran for a while without stalling out! I started to think that the problem was fixed. Then I fired it up the next day and saw that it was once again stalling out. This time, it seems to run fine (in Vista x64) with basic traffic, but as soon as I try to do some high bandwidth activity (like transfer some large files to my NAS box), the network instantly stalls out.

There is clearly something wrong here. I am hoping that either Shuttle or Marvell will step up to the plate and fix this. I honestly don't understand what can be messed up so bad that powering down the system and rebooting it in a different OS with a different hard drive doesn't fix it. I also haven't figured out exactly what makes it work again.

At this point, I am almost ready to just send it in for repair and if they claim to not find anything wrong, they can just keep it. This whole experience is reminding me of why I switched to Apple. And speaking of Apple, my MacBook is rock solid except for the occasional (once every few days to weeks) network dropout. Closing the lid to put it to sleep and then opening it again makes it instantly start working again. When I look at the system logs, what do I see causing the problem? Yukon 2!

I have contacted tech support at both Shuttle and Marvel and pointed them to this page. Any developments will be posted here.

After some email communication with the Marvel support guy, I determined that the FreeBSD driver that comes with the OS has some bugs in it that put the network chip in a state that power cycling will not fix. Running the diagnostic tool, however, will reset the chip or something so it will work again. Marvel does provide it's own FreeBSD driver, but I didn't try it. This computer is now my Windows 7 box.