Original Knights Corner (effectively a stepping of Larrabee) was ~60 cores, each 4-way threaded. Top-shelf Knights Landing parts were 72 cores.

Rumor was that the P54C design was re-imported back into Intel -- they had contracted out a re-implementation, I assume because they needed a fully synthesizable design rather than being tied to a specific die process. My old team had an FPGA socket 7 module that could run an instantiation of this code around 100MHz.

modern x86 hardware is a binary blob these days. even if you don't load any microcode on your CPU, default microcode is present in mask ROM.

Here you go:

• http://ark.intel.com/products/codename/54859/Avoton
• http://ark.intel.com/products/codename/63508/Denverton

Of course mask ROM (or its modern equivalent) is still used. All the embedded microcontrollers in CPUs, chipsets, and IO controllers at least have bootloaders if not default firmware.

Just like RMS has with his Loongson laptop, right?

How's that cloudless life working out for you?

Agreed. I can bootstrap a complete OS and software stack, even cross-compile it to multiple hardware platforms, but I can't do the same thing at the hardware level. I'm stuck with multiple levels of proprietary hardware and firmware. I can't get HDL to my RasPi. I want the ability to bootstrap a complete hardware design (physical circuit boards, RTL, and ALL platform firmware) between multiple independent hardware and silicon vendors. True multiple-sourcing. If I had the facilities (board manufacturing, fab process) I could do it myself. I expect FPGAs to grow good enough to handle this in my lifetime, but they are still tied to proprietary toolchains, and designs for the FPGA silicon itself is not Free or Open.

OS X may not generate SMIs, but are you also asserting that SMM handlers are never run on Apple hardware running OS X?

what are these SMB drivers? how do they affect existing SMM code which is provided in BIOS?

Illumos is still under active development, so you can still get your solaris fix.

CPU microcode still exists even if the blobs aren't included. You're just limited to the version that's included with the stepping of your CPU. I believe the management engine (ME) on the chipset is the same way. (On the server side, at least, the chipset won't allow the CPUs to boot without an ME blob.)

Just because your software doesn't include any blobs doesn't mean that there aren't any blobs on the hardware.

Why put a microscope online? How else are you going to do deep packet inspection?

I wonder what VIA would say about that. it seemed like they had the atom-level market carved out before the atom appeared.

sounds familiar. I had an 80GB early intel SSD (INTEL SSDSA2MH080G1GC) in a macbook pro, which gave me the OSX blue screen equivalent while I was working on it one day without any warning. it wouldn't even boot. Disk utilities under OSX (run from another system, obviously) were unable to even fsck the filesystems, so I replaced the disk. (I had the foresight to make backups, so I didn't lose anything.)

I moved the failed SSD to another machine to take a look at the SMART parameters, which still showed a 96% lifetime left, although it did show read errors after a captive self-test. an email to intel tech support indicated that a secure delete might bring it back to life, and indeed it did. after the secure delete, the drive was reformatted, and I now use it as storage for a couple VMs, and so far so good, although I'm careful not to have anything critical on it.

so no, not graceful. sudden and catastrophic. I'm wondering what a subsequent failure will look like, now that I have smartmontools keeping an eye on it.