The apocalyPS3 ends in global resurrection, ARM chip at fault
The early belief that the PSN was spreading a brickitis infection to PS3s around the world has turned out to be not quite accurate. Yes, PSN was inaccessible over that extremely stressful day (for PS3 owners, the rest of us have been quite fine, thank you), but we're hearing from Eurogamer that the villain in this story was an ARM chip inside the console -- the very same one, in fact, that led to a few Zunes losing their minds back in 2008. The big problem here was simply a bit of hardware that couldn't get its bearings straight after expecting 2010 to be a leap year, and the arrival of March 1 "fixed" everything for all eight affected PS3 SKUs (of a total of eleven). That leaves Sony with four years to make sure this problem isn't heard from again, and if it doesn't, we'll be placing blame for the real 2012 apocalypse firmly on Howard Stringer's shoulders.

























ARM at fault? First Zune, then PS3, whats next... I'm getting a psychic signal... I see an eye... or is it an i... with an apple? and a maxi pad... oh wait its just the iPad... nice choice of processors apple... I think you should heed my vision as a warning and fix it now.
@3dpenguin It's not actually ARM, crap reporting on Engadget's part.
It's the code running on an ARM CPU.
Would you blame Intel for an old version of OS/2 being buggy, and say that all Intel CPUs are buggy, even if they're running another OS entirely? Because that's what you're doing right now.
@bhtooefr
Well the problem behind that thinking is the fact that if you don't take the time to fix the coding that is confusing the ARM CPU because it is a problem with other devices coding not the ARM CPU in general means it will continue to happen with each new device that uses the CPU when the problem comes up because of lazy programing method. The CPU isn't perfect because if it was the coding wouldn't have been truncated the way it was in both cases. Consider this, both Microsoft, who I fully support most of the time, and Sony, who I don't trust as far as I can throw them but I think is competent, used standard date coding on their systems and in both instances ran into a problem with the ARM and their coding when dealing with dates, Apple, whom I'm not a big fan of, is just as competent as Sony and Microsoft and will probably follow the same procedures as these companies, so that means they will likely run into the error too. The only way to prevent this from hitting the consumer is to go through and test date by date on the system. This is a problem with the ARM CPU not understanding standard coding processes, this makes it extremely hard to program for the chip. Its a damn good thing we didn't use ARMs in PCs back in 1999 otherwise we might have had a massive shut down, because we both know these things done like date coding.
The problem with the Zune was a clock driver for the Freescale MX31. The MX31 is a system on chip (SoC) which contains an ARM11. The problem was not the ARM11, the problem was a driver (software) that accesses it.
This code actually:
http://pastie.org/349916
It's in the function "ConvertDays". This is the reference driver for the clock function (RTC) and it contains the bug, apparently Microsoft never fixed the bug when incorporating the code into their system.
Anyway, the problem wasn't really anything to do with ARM.
On top of that, there's no chance the PS3 contains an MX31 chip. It's too powerful to be used (cost-effectively) as anything except a chip that drives UI for a device (since it contains a MBX graphic core) and the MX31 isn't nearly powerful ENOUGH to run the UI on PS3. So I am quite confident there isn't one in there. So this driver code that is for MX31 isn't in there. And this code doesn't contain a day 59 bug anyway, it has a day 366 bug.
Apparently taking one's technical info from Eurogamer is a great way to make yourself look foolish.
I think the reason for the Zune's failing was because the chip thought the Winter Olympic years (2002, 2006, 2010, etc.) were the leap years not the Summer Olympic years (2004, 2008, 2012 etc.). Thus, on December 31st of 2008 the Zune's were unresponsive due to the chip not understanding day 366 on a non-leap year, and now PS3's with the same chip are thinking March 1st is February 29th, then at some point, when you get online or something, you get conflicting dates, and everything goes crazy. I don't know exactly why they're freezing or whatever but I'm about 95% sure it's because the code on the chip has the leap years set to 2006, 2010, etc.
lol I love the title.
So after four months of having a bust blu-ray laser, I finally got round to buying a new laser (rather than just give Sony $150 for a second hand machine) and installing it on Tuesday of last week. I was then finally able to play Uncharted 2 which I'd bought back in October and had six days of heaven. However, I ended up beating the guy at the end on Sunday, so now I don't have any trophies for doing that and they don't turn up even if I sync. They show up on the game itself, just not in my profile despite me experimenting with getting other trophies etc. Anyone else still having problems? Please don't make me play the game through from the beginning again. I can't believe I had to pick that one day to kill him.
Wait a minute! Sony said it made a super powerful chip to put into the PS3. Now, we're hearing that they went with an ARM processor? I am shocked! SHOCKED! This is clearly misadvertisement.
As the leap year algorithm is so simple, I think it is unlikely the algorithm is broken. I'm guessing that the ARM chip uses two digits for representing the year and the Y2K bug was fixed by interpreting the 00-99 as a date from interval 1992 - 2092 or something similar. Who ever made the Y2K 'fix', implemented it in the code after the leap year check, as the leap year check should have been made to the 'corrected' date.
this is what i was told:
''the system malfunction did not resolve itself, SONY cahnge the logic settings on PSN/License detection to produce and update date entries from console chatter...the issue was mainly because the date on consoles and servers did not match up, if they had not fixed it then the issue would have persisted today when the console was showing 1st of march and it was the 2nd.''
The clock thing was not the only thing.