Tag Archives: intel

Intel J1900 flaw causing early failure for embedded devices

Posted on by

This morning I woke up, made some coffee and went to the computer room to work on some projects when I noticed that the shared folders from my NAS weren’t showing up on my desktop. That’s odd I thought. I went over to the NAS and my fears were confirmed, not only was it offline, but it had an error light. It would power on, but it wouldn’t start up.

Hoping that this was some simple fault like a bad stick of memory, I disconnected the unit, pulled out the drives and brought it over to my test bench. I confirmed the power supply was good and swapped the memory in/out, but with no effect. Ouch, this thing is really dead I thought. Before consigning it to the e-waste bin, I thought I’d search around just to make sure and stumbled on a thread from 2020 about the CPU on these devices having a flaw. Not only that, there was a possible fix! (if, perhaps only a temporary one)

At the time the flaw was discovered Intel posted an addendum to their CPU specification update for the J1900 and related CPUs. (Intel has since removed these docs from the public facing side of their website and requires a CNDA account to access them. Thankfully the wayback machine has an archive of them linked above) Unfortunately, the problem lies in the silicon of the CPU itself and is not repairable.

The fix documented in the forum link above and in a similar Reddit thread a year later both outline connecting a 100-200ohm resistor to pull the LPC clock signal to ground. Thankfully this signal is exposed on a pin header that also supplies a ground pin on the NAS model I have. I first hooked up my oscilloscope to the clock pin and verified that it was operating out of spec. I rummaged through my component collection and found a 180ohm resistor that would work. I had some jumper wires with dupont connectors for another project and used that to make a dongle that would jump these 2 pins. I put power into the unit and it started right up. Amazing!

Sadly the problem with the J1900 CPUs is only going to get worse over time. It’s possible that I could be able to keep the unit running for some time, possibly by changing out for different resistors in the future as the circuit continues to degrade. However the real solution is to start planning a migration from this device to something new.

If you have an embedded device powered by a J-series, N-series or similar and it’s been operating 24×7 for several years, you’re likely on borrowed time. Get a good backup of your data and start planning your migration now.

(mostly) 4th Gen x86 Shootout!

Posted on by

Having recently restored my old 486SLC board, I was curious how it stacked up against other 486s of the era. I actually have a fairly decent collection of chips from this time period and a few motherboards that accept them.

For the majority of this test, I used a PerComp branded board made by PC Chips, (model M912) that has a fairly broad range of support for these CPUs and is based on the PC Chips “Chip 16″/”Chip 18” chipset. The board is configured with 256KB of L2 cache, 16MB of 32-pin SIMM memory and supports 7x 16-bit ISA expansion slots, 3 of which support 32-bit VLB cards.

stock photo of an unlabeled M912 board

One funny thing about this board is the branding on the chipset. At the time PC Chips didn’t have a great reputation for performance. In an attempt to boost their sales, they often placed stickers on their chips with the model numbers of other more popular chipsets.

fake chipset branding
actual chipset branding

Alright, enough of the history… let’s get into the testing! The chips I selected for the test were several Intel CPUs, a couple of Cyrix CPUs and a single AMD CPU. These were as follows: i486SX-25 (overclocked to 33Mhz), i486DX-33, i486DX2-66, Cx486DX2-66, Am486DX4-100, Cx5x86-100 (overclocked to 120Mhz)

stock photo of the chip I have. Mine has a fan bolted onto the heatsink as I’ve overclocked it to 120Mhz

The five 486 CPUs shown above all contain 8k of L1 cache on-die. They were all tested on the same motherboard mentioned above, which was configured with 256k of L2 cache.

I’ve also included the 486SLC numbers from a previous test. The SLC and the 5×86 aren’t a good direct comparison since the motherboard and configurations are quite different. Unfortunately, I managed to kill the Cyrix 486DX2-66 when I tested it the second time and wasn’t able to get cache and system performance numbers, but an image with the last screen it produced is included below.

What was most interesting to me were the results for the Intel SX and DX chips clocked at 33Mhz. All of the results from these 2 chips were identical except for the performance index. (which is lower on the SX as it lacks an FPU) What this tells me is that unlike the 3rd generation, Intel’s 4th generation SX chips were fully 32-bit externally. The i386SX was 16-bit externally and was dramatically slower as a result. Likewise the Cyrix 486SLC also suffered in this test due to its 16-bit external bus. I suspect Intel’s 4th generation SX chips were simply lower binned parts from the DX production line that had defects in the FPU section of the die. Simply disabling the FPU by cutting/burning the traces between it and the CPU section of the die would allow these otherwise defective chips to be sold, albeit as a lower-end model.

TX486SLC-e w/IIT FPU
i486SX25 @33Mhz
i486DX-33
i486DX2-66
Cx486DX2-66
Am486DX4-100
Cx5x86-100 @120Mhz

It’s a shame the Cyrix DX2-66 gave up the ghost during the test. However, it’s not a chip I was likely to put back into use in any of these systems. What data I did get from it confirmed my recollection of the CPU. It was slightly faster than the Intel DX2-66 in integer ops, but was a bit slower in floating point due to a weaker FPU design.

Intel finally wakes up, smells the lack of bandwidth

Posted on by

[H] Enthusiast – Intel Nehalem Technology Overview Webcast

One thing I’ve loved over the past few years is explaining to the Intel fanboys why my HPC at work is Opteron based.  Intel fans love to talk about clock speed and how the latest Core2 processor beats AMD’s Phenom in gaming benchmarks and such.  It always blows their mind when I explain how Opteron destroys anything with a FSB in the HPC space.  It seems Intel’s state of denial over AMD’s superior Hypertransport technology was largely a front for envy kept in secret.  Intel’s unveiling of their Nehalem platform reveals what is a near copycat design called QPI or QuickPath Interconnect.  It will be interesting to see AMD’s response to this design.  For now the Intel fanboys are predicting the swift death of AMD.  Let’s not forget that AMD developed this system for their 64-bit x86 platform (before Intel even had a 64-bit x86 on the roadmap) and was way ahead of the game then.  I seriously doubt they’ve been sitting on their laurels all this time.