Yet another failed Synology box

How hot was it running?

I'd hazard a guess that a decent number were in a NAS.

I think it is just a design flaw. It appears that the internal pullup on one of the GPIO lines "degrades", over time. The signal involved is responsible for interfacing to the boot flash (etc.). So, the processor is never able to fetch its IPL and just sits there acting stupid.

Of course, the designer only LEARNS about this after he has already deployed units with these CPUs in place. Ooops!

What is most amusing is the number of such boxes that I encounter where the "previous owner" just abandoned the data -- THAT HE HAD PREVIOUSLY THOUGHT MERITED A RAID-BASED SOLUTION -- instead of trying to recover it via other means (even if you leave the hardware as "toasted", there are tools that you can use to begrudgingly access the existing RAID arrays -- as long as you don't manually dick with the drives before doing so!)

Yet another example of folks following blinkenlights instead of thinking about their ACTUAL needs!

And other "appliances" that tried to rely on "cheap" processors.

And we wonder why Intel is such a schlock outfit...

CPU failure isn't something that I normally consider but it is one of those models affected. Ho hum - it's WEE scrap (the owner will be sad).

Ugh! You must have the patience of Job to deal with laptops! I won't even bother replacing the coin cells as there's usually some amount of gymnastics involved in gaining access to it.

(And too many snap-together plastic parts that decide NOT to snap but prefer, instead, to BREAK!)

Higher and higher levels of integration suggest we;ll be seeing more of these sorts of failures as its often uncharted territory for folks who previously designed "CPUs". And, who knows how many "buried" faults will never even be observable... the only remedy being to replace the entire assembly!

With higher density boards, I imagine anything larger than a few square inches will see pad failures from thermal expansion/contraction and board flexion (esp as folks THINK they can swap DIMMs without consequences). Too many things don't scale as easily as one might hope...

I draw the line at stuff that has been PU melt glued together on a once and for all basis. I know someone who has a heat gun and a sharpened paint scraper who is prepared and rather good at taking them on.

We see the same with the repair cafe and modern TVs the core chips that fail are so expensive that buying a brand new better spec TV is cheaper!

The high level of integration makes it much harder for new electronic engineers. I cut my teeth on old ICL1900 TTL boards dismantling and making new things from the resulting logic parts.

I remember back when some high performance Pentium 4 laptops got so hot on the underside that they would cook the users legs if used that way.

I'm surprised because the Atom C2000 ('Avoton') is an embedded server chip - commonly used in NASes, small networking appliances, etc. I would not expect to find it in a laptop. This design fault was a well-known specific problem for the Avoton series and no other other hardware is affected.

Any time I've had a completely dead laptop that was previously working when put away, it's been CMOS battery related. Of course if it was not working previously then it could be something else.

Theo

I have a couple of Supermicro rack servers with those chips. There was a fix which involved adding some resistors to the motherboard. Later versions of the processor were fixed I believe. The problem would often take about 5 years to show up and would only be discovered after trying to reboot. John

They are common in SOHO kit. I've seen them in QNAP and Synology NASs.

"Strengthening" the (internal) pullup on one of the clock signals.

Yeah, "Avoid rebooting. Use a UPS to ensure the device remains powered during momentary outages"

Sort of like telling a driver "Avoid hitting other vehicles".

And, who's to say when the "permanent temporary fix" stops working? Will you have an identical device that you can switch over to in order to keep your availability up?

Can you get a refund? A refund would not be as good as restorings data. I bought a medium with a warranty for this medium - but this warranty expressly excludes the data which I wrote to this medium!

Don Y snipped-for-privacy@foo.invalid wrote: |-----------------------------------------------------------------------| |"What is most amusing is the number of such boxes that I encounter | |where the "previous owner" just abandoned the data -- THAT HE HAD | |PREVIOUSLY THOUGHT MERITED A RAID-BASED SOLUTION --" | |-----------------------------------------------------------------------|

I would not be amused.

|-----------------------------------------------------------------------| |"instead | |of trying to recover it via other means (even if you leave the | |hardware as "toasted", there are tools that you can use to begrudgingly| |access the existing RAID arrays -- as long as you don't manually | |[. . .] with the drives before doing so!)" | |-----------------------------------------------------------------------|

I do not own such media, but please identify such tools. Thanks in advance. (S.

I see most folks using RAID and ZFS as if it was a badge of honor. Few have "done the math" regarding how little it actually gives you by way of "protection".

So, the apparent willingness to discard the data (instead of trying to recover it) suggests the data wasn't as important as they wanted YOU to believe.

Many "appliances" are Linux or *BSD based. So, having a box running the appropriate OS (and device drivers) can usually be coaxed into manifesting the data "as encoded".

Of course, if you have 8 spindles in an array, then you will need some way of mounting 8 media so the "rescue box" can access them (in the event that they are a RAID/ZFS pool and not just bare drives).

There are also some Windows-hosted tools that can do this (more or less). The problem, there, is the incompatibility in file naming/mangling conventions between the two platforms. E.g., "class::method" is a valid filename on my *BSD boxen. Any Windows tool that tries to present that via the file explorer interface will likely gag on the colons.

Or, case sensitivity.

Or, maximum pathlength.

I.e., unless you've actually done a trial run of such a recovery, you are likely going to be surprised in ways you hadn't imagined!

(And, if the disk that you are attempting to recover is already "failing", then you've got a time deadline to complicate things before it becomes irrecoverable. How long do you think it takes to recover a terabyte -- IF you have a terabyte of freespace already set aside and KNOW what you are doing?? Four terabytes? Eight??)

I've not checked their math...

Ask your NAS/DAS/SAN what sort of ACTUAL *sustained* throughputs it can achieve. And compare any of the RAID levels to simple mirroring.

Resync on 1TB Linux Raid 1 is few hours, faster with older drives, the newer ones using deeper recoding to increase density have slower write speed. Should be done a day for 4 terabytes.

Of course, Raid only protects against disk failures and only when you propmptly insert a replacement. Failing power supply can fry all drives in the array (but then there is decent chance to recover data by replacing drive electronics).

Raid 1 is just a mirror so it's considerably faster than

But, nowadays, 1T isn't very big as a single spindle. And, time scales almost linearly. So, 4T is "a workday";

And, for a given URE class, the risk of a URE *also* increases linearly.

So, for nearline drives, you've got roughly an 8% chance of encountering a URE during the rebuild. That increases to 32% for a 4T drive. (an order of magnitude lower for enterprise class drives) But, will likely only loose the data object in which the error is detected (you've got a second copy of it so *likely* can still recover that item).

The disk itself need not fail to put data at risk. Absent patrol reads and data scrubbing, you could have a bunch of accumulated errors on the disk just waiting to be discovered.

Or, as in the example cited, a failed controller effectively renders all of your data inaccessible until a similar controller can be found (assuming you've familiarized yourself with how to import the "foreign" configuration).

Note that (in the case of the cited NAS) *that* owner obviously found the effort to recover the data exceeded the value of the data (else why dispose of the drives?)

Being able to move a spindle to another box and treat it like a regular medium avoids the uncertainty that you likely encounter WHEN you suffer a failure and aren't completely confident in your "process". (And, the stress associated with such an occurrence -- as you don't know WHAT you are at risk of losing -- just makes this all the more upsetting) And, lets you focus on recovering those things that are most valuable to you -- instead of letting the array make that decision for you.

ZFS is not good enough. In 2008 I installed OpenSolaris on a ZFS partition. It became corrupted within weeks. I did not lose anything critical to OpenSolaris and ZFS - during those months I was evaluatings various operating systems so OpenSolaris disqualified itself and ZFS.

During the same months I also evaluated various BSDs (including a FreeBSD Release Candidate), but I stabilized on GNU/Linux. I do concede that FreeBSD's ease of accessing documentation is an advantage for FreeBSD, but it was not enough for that choice.

Don Y snipped-for-privacy@foo.invalid wrote: |------------------------------------------------------------------| |"[. . .] | |[. . .] Windows tool [. . .] | |[. . .] will likely gag on the [. . .] | | | |[. . .] | | | |Or, maximum pathlength." | |------------------------------------------------------------------|

Microsoft is so inept that Windows Explorer failed to transfer files from C: to D: with the origin and destination paths differings only by their drive letters. These failures involve complaints by Windows Explorer that the destination paths are too long! (These C: and D: are really partitions on the same drive, and they are of the same filesystem type.)

|------------------------------------------------------------------| |"I.e., unless you've actually done a trial run of such a recovery | |you are likely going to be surprised in ways you hadn't imagined!"| |------------------------------------------------------------------|

(S.

Can you add a pull-up resistor external to the CPU?

If it's any comfort, I overcooked two large CPUs including an Intel i7. After too many hours of SPICE ... *PHUT* ... gone.

Don Y snipped-for-privacy@foo.invalid wrote: |----------------------------------------------------| |"

Don Y also did not write this excerpt from StorageMath.org/raid-rebuild-calculator by Mister Subash Geetha Krishnan - |-----------------------------------------------------------------------| |"NVMe SSD and SATA SSD arrays have URE rates of 10^17 or better, making| |SSD RAID 5 significantly safer than HDD RAID 5 during rebuilds, even | |at large capacities. See also: calculate ZFS RAIDZ usable capacity." | |-----------------------------------------------------------------------|

I do not detect a real warning against ZFS on

Don Y also did not write

- it has hardly a warning (except about money).

(S.

That is a limitation of Explorer. There are ways around it as the underlying filesystem obviously supports longer pathnames.

And, case sensitivity.

And supported character set.

But, most people will not have planned for this and will only discover it when trying to create or move a chunk of the filesystem (and then find themselves stuck)

That;s the workaround (100 ohm). But, I suspect it just kicks the can down the road a bit.

Cisco had a helluva time with product failures (imagine your fabric not coming back online after a power glitch).

Of course, Intel is slow to admit to such problems (the reason I stopped using them after the 8085)

I think electromigration will be a significant problem going forward. For the commodity market, they'll shrug it off as an excuse to replace kit.