tHog
I no longer have this machine, information is retained for reference.

hoo

Gentoo Linux

  • Jetway J9F2-Extreme motherboard
  • Intel Core 2 Duo T7200 2.00 Ghz CPU
  • 2*1 GB DDR2 667 MHz CL5 (maxed out)
  • Toshiba MK3255GSX 2.5'' 320 GB SATA hard drive
  • Samsung SH-S223LRSMN DVD+/-RW DL Lightscribe
  • Morex 80 W Mini-ITX passive PSU
Hoo

Summary

Got the motherboard on 2008-03-12, bought from Hanobox. The old Gentoo installation booted with no fuss, except that the kernel was recompiled for SMP and drivers.

Linux drivers

ComponentKernel module(s)Notes
Ethernetr8169
IDE/SATAata_piix
USB 2.0uhci_hcd, ehci_hcd
Firewireieee1394, ohci1394
Graphics / Xintel-agp, i915, drmXorg driver: i810 aka intel
Graphics / consolevesafb
Sound / ALSAsnd_hda_intel (Realtek + ATI HDMI)
CPU frequency scalingacpi_cpufreqPHC patch for undervolting (update for Linux 2.6.25)
CPU temperature monitoringcoretemp, ISA buslm_sensors

Files

CPU frequency switching, undervolting, and temperature monitoring

As this is the first SMP system I've owned, some things have not been obvious from the start. Some of the confusion comes from the fact that the "dual core" makes some parts of the CPUs shared, namely L2 cache and external connections (FSB). For example, the L2 cache usually runs at the internal CPU frequency, so I couldn't imagine the two CPUs running at different speeds. But apparently they do. The CPUs are independent in the following aspects that I found somewhat surprising:

I've rewritten my cpufreq and undervolting scripts so that both CPUs are equally configured. Even then, they can run at different frequencies, for example with the conservative governor when only one CPU is loaded.

Display quirks

OpenGL acceleration with the 945GM

There's a bug with fullscreen acceleration that makes SDLMAME unusable with OpenGL. This seems to be fixed with mesa 7.1 and xorg-server 1.5.0, though otherwise this update makes X somewhat slower.

Otherwise, OpenGL acceleration seems to work, for example with PPRacer. Using the environment variable INTEL_BATCH=1 gives a notable speedup, bringing glxgears to well over a thousand FPS. The overall feeling is not much faster than my laptop with the 852/855GM, though.

Interestingly, the new Mesa driver framework called Gallium3D is being developed, with i915/945 as the first working hardware target. I haven't tried any unstable/development drivers yet, though.

Disk drive quirks

Connector issues

Cooling: issues

The stock cooling installations for CPU and northbridge are, frankly, embarrassing, and they had to be replaced before first boot.

J9F2 stock CPU cooler

What is this fansink trying to do, push air through the CPU? With a basic understanding of fluid mechanics, you have to wonder why these dumb fansink designs prevail.

J9F2 northbridge with stock shims and paste J9F2 northbridge heatsink with too much paste

The northbridge cooling had the same exact problem here as in the J7F5. The shims are too thick and/or hard, leaving empty space between the chip and the heatsink. You can see this from the huge amount of cooling paste.

Cooling: solutions

I didn't happen to have any suitable shimming material for the northbridge, so I just left it out. Being careful not to damage the corners of the chip in process.

Ditto for the CPU cooler. I use a Nexus PSM-5000 with the stock fan on the side. Basic fluid mechanics at work, with undervolting I'm getting CPU temperatures of max 35 °C (2008-03-14). Fully loaded at max frequency, and the fan at its minimum speed. Cool.

On 2008-06-08 I decided to encase the machine for more portability and better looks. I had full-tower aluminium case, where most of the space will be wasted, but at least there's plenty of room for cooling. So I rigged an 80-mm temperature sensitive fan in a rubber band suspension. The result is disturbingly quiet, particularly with the case closed. The single fan provides better cooling for the rest of the motherboard too, while emphasizing the natural convection path of the case, from bottom front to top back.

Experiences

1280x720 H.264 video with AC3 doesn't even tax one CPU fully — load stays around 60% max (with CPU at max frequency). Full HD could well be possible. This is without any hardware acceleration, besides XVideo.

Extreme!!!111 ;)

There's apparently another model of the J9F2 around. Why would this one be called extreme? Perhaps due to some of these:

March 2010 upgrade: x86-64, laptop SATA HD, and digital audio

[2010-03-12] Yesterday my T7200 CPU arrived, and the laptop drive had been waiting for a while already. The old 32-bit install could well run on the new CPU, but I wanted a fresh 64-bit start with the new HD too. Nothing special about this Gentoo install, after you've done a few of them it's all routine. The new kernel was compiled via oldconfig, since most of the hardware drivers are the same.

CPU power and cooling

The T7200 die seems nearly twice as large as the T2300, and the power draw was expected to increase respectively. With 4 MB of L2 cache, it feels like the T7[246]00 are the SUVs of Socket M, adding whatever number of transistors that can possibly be fitted within the specs of a mobile CPU from 2006. Admittedly, my prime motivation for this upgrade goes somewhat against my cool and quiet principles, but performance per watt has probably improved. Notably, SSE2 instructions are twice as fast per clock.

There is a new limitation with undervolting, a minimum VID of 19 for all frequencies. At the maximum frequency I soon get rounding errors at this VID, so the limit is not really a problem, but I cannot lower it far enough to crash the entire machine :)

The increased power consumption is clearly reflected in the die temperature, which has gone roughly from 40 to 55 °C at full load. With the room temperature around 20, it can be estimated that the power has increased by a factor between 1.5 and 2; heat flux is generally proportional to temperature difference. After adjusting the fan position, the temperature is now at a comfortable 49...50 °C.

SPDIF header

After digging around documents and PCB traces, I have come to the conclusion that there are no SPDIF connectors on the motherboard. However, an equally solid fact is that the ALC888 chip does have both an input and and output for SPDIF. So say the specs, which also come with a couple of helpful circuit examples.

Thus, to make the most of the downtime with CPU and HD upgrades, I also planned to take another look at the motherboard's digital audio, and whip out some solder if needed. The chip's SPDIF output was indeed soldered to a trace, but that seemed to lead nowhere, so I ended up doing some soldering of my own. The trick about these miniature jobs is to pre-solder the wire properly, and then do the connection fairly quickly without any extra solder. I simply wired up a header for the SPDIF input, output, and digital ground. These are TTL level signals, so I currently use the SPDIF adapter I previously built using these instructions. The input is so far untested, but the output works fine, for example for passing 6-channel AC3 via MPlayer into the amplifier.

May 2010 upgrade: DL DVD burner and SATA mode settings

[2010-05-12] I needed a double layer burner, and I did consider a Blu-ray burner for some time. However, the price difference was huge, as you could get a really nice DVD burner for next to nothing, and I am somewhat wary about the future of spinning disc media in general.

While I did have a DL burner in my old laptop, it failed to recognize a lot of blank media. It was apparently a firmware issue, and there were no official updates. I did not want to hack on something I was about to sell anyway.

Until now, the BIOS settings for SATA had been in their defaults for IDE emulation. Even after I did install a SATA HD. Somehow I had gotten the idea that, in order to use any IDE ports, the entire system must be in an IDE mode. So naturally I changed it to AHCI when I only had SATA drives. However, the kernel still sees IDE in addition to AHCI. I guess the IDE emulation is really only about SATA ports, in case a really outdated OS does not handle AHCI.

The SATA HD initially had an unexpectedly low performance in many operations, though bulk transfers were fast according to hdparm. For example, moving a large file between HD partitions was excruciating. I suspected this had something to do with IDE emulation, where SATA features such as NCQ are not available. The mode change confirmed this, and the drive feels much faster.


Risto A. Paju