Compensate for Rockchip calendar deviation on November 31st | Hacker News Reader

Compensate for Rockchip calendar deviation on November 31st

git.kernel.org

131 pointsMoral_37 comments

I read a lot of kernel source at work. Every now and then I stumble across a comment or commit message like this which really gives me a chuckle and makes my day.

Also if you've ever actually used a Rockchip device you'll know they're absolute shit. Pirated Android phone images on incomplete Android device frameworks. They do bullshit like displaying on the TV at 1080p but the Netflix app displays at 720p in the top left corner. How unsurprising they fucked the calendar up too.

Before you go defend the brave embeddded developers from the mean nasty LKML, just think of all the consumers who've paid $100 for TV sticks which advertised an experience and didn't even come close to fulfilling that promise, with absolutely zero after-sales support or updates coming out of Rockchip. Fuck those guys.

If you are any form of hacker who takes pride in your work, you'll recognise this for the colossal fuck-up it actually is.

Even Microsoft is not immune to date bugs - remember their Zunes freezing on a leap year?

http://bit-player.org/2009/the-zune-bug

This was in software, not hardware, more serious than just the date being wrong, and they didn't even provide a fix other than "wait until the day passes":

http://gizmodo.com/5121822/official-fix-for-the-zune-30-fail

RK3288 from Rockchip is in several of the Chromebooks that are currently on the market, including Chromebook Flip and the ASUS Chromebit.

They perform quite well there if I may say so, when a proper amount of effort has been put into the software running on them.

The chips from Chinese manufacturers aren't really better or worse than most of the others out there, it's just that they often take shortcuts on the software side -- or rather, in particular the low-cost system OEM/ODMs do.

I've learned never to trust software implementations from third-party companies. They generally work well enough for pre-sales demonstrations, but you should always expect to do a bunch of post-sales bug fixing and feature implementation if you want to build a real product out of them. The same thing goes for BSPs from third parties.

Basically it's extremely rare to find third-party software that is completely trustworthy, even when you pay a bunch of money to ensure that this is the case. Hence why IEC62304 speaks directly to third-party software as enhancing risk. The best thing you can hope for is that the bugs are fairly benign or are easy to work around.

I've made pretty good money a few times by taking BSPs provided by vendors and transforming them into something actually usable and robust. And these aren't sketchy Chinese OEMs, these are well-established vendors.

typing this from a rockchip rk3188 laptop. with enough RAM, and a proper linux install, they're rock(sorry) solid.

This would certainly explain the weird date issue I had in Android last year, though.

If I hadn't come to the comment thread, I would not have realized that the commit message was sarcastic - I thought to myself, "wow, people are still finding bugs in calendars - this stuff is hard."

This is probably tangential but when it comes to code and context and everything (e.g. commit messages) I like to be as dry and clear as possible. Just the facts, ma'am.

At first I was like "November 31st?!" Then Rainier Wolfcastle popped into my head and said "THAT'S THE BUG."

It's disappointing that pretty much all RTCs still store two digit years. I'd like to design hardware that still works right after Y2.1K.

Not even 2.1k, because of the 2 digit years, they'll fail before that even. They've usually got some kind of cut off date where before that it'll give the wrong Day of the Week because it's using the wrong table now.

So is the Rockchip device counting incorrectly, or is someone actually proposing there is something specifically wrong with the Gregorian calendar? Without any other Google results for "Rockchip calendar" I'm assuming it's the former, but if so the level of snark is a bit difficult to read through and the post doesn't make much of a differentiation between the hardware and the calendar model used to correct for its error.

I think it is just a hardware bug that they make jokes out of.

November has 30 days, while the chip's real-time clock counts to 31 days in that month. Some additional commentary can be found on LKML [1].

[1] https://lkml.org/lkml/2015/12/2/1202

But in this link isn't code setting day to Nov 1 when it hits Oct 31? Am i reading some wrong?

if (tm->tm_mon == 10 && tm->tm_mday == 31) { dev_warn(dev, "correcting Nov 31st to Dec 1st (HW bug)\n"); tm->tm_mon = 11; tm->tm_mday = 1; rk808_rtc_set_time(dev, tm); }

Maybe they start counting months at zero.

http://www.cplusplus.com/reference/ctime/tm/:

  Member   Type Meaning                   Range
  tm_sec   int  seconds after the minute  0-61*
  tm_min   int  minutes after the hour    0-59
  tm_hour  int  hours since midnight      0-23
  tm_mday  int  day of the month          1-31
  tm_mon   int  months since January      0-11
  tm_year  int  years since 1900	
  tm_wday  int  days since Sunday         0-6
  tm_yday  int  days since January 1      0-365
  tm_isdst int  Daylight Saving Time flag

Thanks for that link. The discussion and the different attempted solutions are fascinating.

The snark is extremely dry, so it is entirely reasonable to have misunderstood it. But the effect of adding an unconditional day to November would be to increase the year to 366 days (and 367 on leap years), which even the ancients knew was totally wrong. And the effect of adding a day to November and take it from e.g. December is just to affect how we do human accounting; there's no astronomical concept of December 1 that needs to line up with anything.

The introduction to the patch is unnecessarily demeaning.

If I had to patch an OS kernel to account for an erroneous hardware RTC, I'd probably be inclined to be a little "demeaning" too.

To be fair, with any amount of actual testing of the hardware IP before production, this would have been caught, it's a pretty bad bug.

Or Rockchip could have simply implemented a linear seconds counter, which would have worked fine and not required crazy workarounds.

I wonder how they missed it. If someone was asked to write verification tests for a RTC chip, this would one of the first few things obvious things to be checked.

Really, or are you just saying that? They "missed it" because either (a) they didn't bother to test at all, or (b) they actually thought November has 31 days and didn't bother to do the 4 seconds of research required to get both the implementation and the test correct (since, of course, the people writing this are almost certainly Chinese and know as much about the Gregorian calendar as they know about McDonald's hamburgers, Norman Rockwell's art, or the present value of the euro).

Welcome to firmware, folks!

They use the Gregorian calendar in China for everything except traditional holidays.

In addition to using the Gregorian calendar, China has a couple thousand McDonalds and people there are well aware of major world currencies.

I have a feeling they just "bought" the IP from a third-party and never actually tested it.

That's hardly demeaning. I would be more devastated if I produced a product that had this type of a bug, versus what some random stranger might write in patch notes about it.

The person responsible doesn't care in the slightest. They got paid, their product not only got sold but is still being sold, and so there's nothing to be bothered with. That's what firmware's about: toss it out the door and move on. Trust me, if the person who did this even knows about it, he surely does not care at all.

The good news is that presumably the introduction of this bug means that they needlessly rewrote the RTC for this generation of chips, which means they might meaninglessly rewrite it again and the bug will be fixed!

Oh, you're such an optimist! Everyone knows firmware developers will only rewrite something needlessly if it's correct.

Wow, this comment is currently downvoted to 0, and the replies to it are justifying the belittling response. You become more worthy through action --- not by belittling someone else.

I think the downvotes are a little harsh, but I disagree with you. The patch notes are not belittling and don't represent any of the other problems I've seen complaints about re Linux contributions (swearing, bullying, sexism). They're just a bit of light-hearted fun - and they're not contained in the code itself.

> You become more worthy through action --- not by belittling someone else.

Hence why the patch submitter was upvoted and the commenter was downvoted.

I make chips for a living, and if I had screwed up this badly I would fully expect to be fired. Being fired for incompetence is much more demeaning than gentle mockery by people writing a workaround.

On the contrary, the comments are far too kind. This sort of error is simply unconscionable and the person responsible for it deserves far worse. It's unfortunate that the poor sod responsible for working around it can't do any more than write a scathing comment, because at an absolute minimum the responsible party should never work again (in any industry or role).

I find it to be a remarkably gentle response to an act of such gross incompetence.

Reply on news.ycombinator.com