5 ms·
Compensate for Rockchip calendar deviation on November 31st
- 762236 11y agoThe introduction to the patch is unnecessarily demeaning.
- aaronem 11y agoIf 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.
- TD-Linux 11y agoTo 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.
- pkaye 11y agoI 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.
- fredkbloggs 11y agoReally, 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!
- userbinator 11y agoI have a feeling they just "bought" the IP from a third-party and never actually tested it.
- urda 11y agoThat'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.
- fredkbloggs 11y agoThe 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.
- TD-Linux 11y agoThe 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!
- fredkbloggs 11y agoOh, you're such an optimist! Everyone knows firmware developers will only rewrite something needlessly if it's correct.
- 762236 11y agoWow, 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.
- smcl 11y agoI 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.
- slavik81 11y ago> You become more worthy through action --- not by belittling someone else. Hence why the patch submitter was upvoted and the commenter was downvoted.
- jamesbowman 11y agoI 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.
- fredkbloggs 11y agoOn 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).
- fredkbloggs 11y agoReally, downvoter asshole, really?! Let's walk through it, shall we? I'm not sure how many days are in November. Or any month, for that matter. Ok, no problem, no one knows everything. Let's go look this up. This takes a few seconds. We look it up. Oh hey, November has 30 days. Cool. I'll go write the correct code. It won't take any longer than writing the wrong code, nor will it cost me or my company any more. Tell me why this is too hard, or too much work, or too expensive, or WHATEVER. Tell me. Really. Go ahead, I'm waiting.
- dang 11y agoPersonal attacks and name-calling are not allowed on HN. Please post civilly and substantively, or not at all.
- mikeash 11y agoI find it to be a remarkably gentle response to an act of such gross incompetence.
- plorg 11y agoSo 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.
- yuhong 11y agoI think it is just a hardware bug that they make jokes out of.
- rzzzt 11y agoNovember 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 https://lkml.org/lkml/2015/12/2/1202
- jsudhams 11y agoBut 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); }
- rahimnathwani 11y agoMaybe they start counting months at zero.
- Someone 11y agohttp://www.cplusplus.com/reference/ctime/tm/ 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
- suprjami 11y agoI 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.
- userbinator 11y agoEven Microsoft is not immune to date bugs - remember their Zunes freezing on a leap year? http://bit-player.org/2009/the-zune-bug 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 http://gizmodo.com/5121822/official-fix-for-the-zune-30-fail
- ojn 11y agoRK3288 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.
- jschwartzi 11y agoI'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.
- kevin_thibedeau 11y agoIt'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.
- simcop2387 11y agoNot 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.
- bitwize 11y agoAt first I was like "November 31st?!" Then Rainier Wolfcastle popped into my head and said "THAT'S THE BUG."
- nchelluri 11y agoIf 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.