Intel dithers over i820 recall details

Taiwanese mobo makers, others up in arms


The Intel cockup over the i820 chipset has placed profits of Taiwanese mobo makers in financial jeopardy as the chip giant decides exactly how to tackle what has to be a major logistics nightmare.

As we reported here last week, the problems Intel will face after it admitted that a fault with the memory hub translator (MTH) on synchronous DRAM versions of the i820 chipset have spread far beyond just the simple recall of its ill-fated Cape Cod chipset. We initially broke this story in March, meaning that Intel has had a full two months to not come up with the recall answer.

Third party manufacturers, including Asus, Gigabyte and others, are now thinking out the implications of the i820 problem, but, insiders say, are worried both about the impact on their bottom line and whether there will be a market for such motherboards when Intel finally gets its act together and produces a working MTH at some unspecified point in the third quarter of this year.

But, so far, Intel has said little to re-assure the vast army of nearly one million i820 mobo users, and must be hoping that the problem will quietly sink into the mists of time. That is unlikely.

As of the end of last week, Intel was not confirming that it would ship Rambus based i820s, complete with Rambus RIMMs, to customers facing system lock ups and potential data corruption who use both Cape Cod and third party solutions based on the defective MTH part. And if it does decide to ship such systems packed with Rambus, no-one is saying what speed any RIMMs that ship with such systems will be.

Nor does Intel yet seem to have any solution for hapless users who may have bought their first PC and who have little desire to get a screwdriver out and delve into the innards of the beige box to swap out something which is called "a motherboard".

The large PC companies who have bought Cape Cod mobos and installed them in their systems are also keeping quiet about how they will tackle the debacle, and, according to sources, are also waiting for the official line on what actually happens.

Over the weekend, Asia Biz Tech was reporting that the Taiwanese firms were seeking compensation from Intel for the cockup, with the average sum of dosh for each screwed up mobo being $120.

The distributor and dealer market, which buys Intel boxed mobos when they can get them, is also waiting for the official line from Chipzilla.

A source at a major European PC manufacturer said today: "I would say that any system integrator who decided to ship an 820 platform did so in face of severe technical reasons why they shouldn't. The people I feel sorry for are the mainboard manufacturers who have once again been screwed by Intel. They really should be used to it by now. Best buy some more of that AMD and Via stock."

Industry estimates say the whole bananas could amount to a hit for Intel which could be as much as hundreds of millions of dollars. ®


Other stories you might like

  • Pentester pops open Tesla Model 3 using low-cost Bluetooth module
    Anything that uses proximity-based BLE is vulnerable, claim researchers

    Tesla Model 3 and Y owners, beware: the passive entry feature on your vehicle could potentially be hoodwinked by a relay attack, leading to the theft of the flash motor.

    Discovered and demonstrated by researchers at NCC Group, the technique involves relaying the Bluetooth Low Energy (BLE) signals from a smartphone that has been paired with a Tesla back to the vehicle. Far from simply unlocking the door, this hack lets a miscreant start the car and drive away, too.

    Essentially, what happens is this: the paired smartphone should be physically close by the Tesla to unlock it. NCC's technique involves one gadget near the paired phone, and another gadget near the car. The phone-side gadget relays signals from the phone to the car-side gadget, which forwards them to the vehicle to unlock and start it. This shouldn't normally happen because the phone and car are so far apart. The car has a defense mechanism – based on measuring transmission latency to detect that a paired device is too far away – that ideally prevents relayed signals from working, though this can be defeated by simply cutting the latency of the relay process.

    Continue reading
  • Google assuring open-source code to secure software supply chains
    Java and Python packages are the first on the list

    Google has a plan — and a new product plus a partnership with developer-focused security shop Snyk — that attempts to make it easier for enterprises to secure their open source software dependencies.

    The new service, announced today at the Google Cloud Security Summit, is called Assured Open Source Software. We're told it will initially focus on some Java and Python packages that Google's own developers prioritize in their workflows. 

    These two programming languages have "particularly high-risk profiles," Google Cloud Cloud VP and GM Sunil Potti said in response to The Register's questions. "Remember Log4j?" Yes, quite vividly.

    Continue reading
  • Rocket Lab is taking NASA's CAPSTONE to the Moon
    Mission to lunar orbit is further than any Photon satellite bus has gone before

    Rocket Lab has taken delivery of NASA's CAPSTONE spacecraft at its New Zealand launch pad ahead of a mission to the Moon.

    It's been quite a journey for CAPSTONE [Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment], which was originally supposed to launch from Rocket Lab's US launchpad at Wallops Island in Virginia.

    The pad, Launch Complex 2, has been completed for a while now. However, delays in certifying Rocket Lab's Autonomous Flight Termination System (AFTS) pushed the move to Launch Complex 1 in Mahia, New Zealand.

    Continue reading

Biting the hand that feeds IT © 1998–2022