)]}'
{
  "commit": "b4a5e8a1deca7e61ebaffb37344766b0f0e9f327",
  "tree": "9b396c3ddca5278d553448043c276fad528fcd93",
  "parents": [
    "8da854cb02156c90028233ae1e85ce46a1d3f82c"
  ],
  "author": {
    "name": "Alok Kataria",
    "email": "akataria@vmware.com",
    "time": "Thu Mar 11 14:00:16 2010 -0800"
  },
  "committer": {
    "name": "H. Peter Anvin",
    "email": "hpa@zytor.com",
    "time": "Thu Apr 01 15:21:48 2010 -0700"
  },
  "message": "x86, hpet: Fix bug in RTC emulation\n\nWe think there exists a bug in the HPET code that emulates the RTC.\n\nIn the normal case, when the RTC frequency is set, the rtc driver tells\nthe hpet code about it here:\n\nint hpet_set_periodic_freq(unsigned long freq)\n{\n        uint64_t clc;\n\n        if (!is_hpet_enabled())\n                return 0;\n\n        if (freq \u003c\u003d DEFAULT_RTC_INT_FREQ)\n                hpet_pie_limit \u003d DEFAULT_RTC_INT_FREQ / freq;\n        else {\n                clc \u003d (uint64_t) hpet_clockevent.mult * NSEC_PER_SEC;\n                do_div(clc, freq);\n                clc \u003e\u003e\u003d hpet_clockevent.shift;\n                hpet_pie_delta \u003d (unsigned long) clc;\n        }\n        return 1;\n}\n\nIf freq is set to 64Hz (DEFAULT_RTC_INT_FREQ) or lower, then\nhpet_pie_limit (a static) is set to non-zero.  Then, on every one-shot\nHPET interrupt, hpet_rtc_timer_reinit is called to compute the next\ntimeout.  Well, that function has this logic:\n\n        if (!(hpet_rtc_flags \u0026 RTC_PIE) || hpet_pie_limit)\n                delta \u003d hpet_default_delta;\n        else\n                delta \u003d hpet_pie_delta;\n\nSince hpet_pie_limit is not 0, hpet_default_delta is used.  That\ncorresponds to 64Hz.\n\nNow, if you set a different rtc frequency, you\u0027ll take the else path\nthrough hpet_set_periodic_freq, but unfortunately no one resets\nhpet_pie_limit back to 0.\n\nBoom....now you are stuck with 64Hz RTC interrupts forever.\n\nThe patch below just resets the hpet_pie_limit value when requested freq\nis greater than DEFAULT_RTC_INT_FREQ, which we think fixes this problem.\n\nSigned-off-by: Alok N Kataria \u003cakataria@vmware.com\u003e\nLKML-Reference: \u003c201003112200.o2BM0Hre012875@imap1.linux-foundation.org\u003e\nSigned-off-by: Daniel Hecht \u003cdhecht@vmware.com\u003e\nCc: Venkatesh Pallipadi \u003cvenkatesh.pallipadi@gmail.com\u003e\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: \"H. Peter Anvin\" \u003chpa@zytor.com\u003e\nCc: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: H. Peter Anvin \u003chpa@zytor.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3d422da921003ef3c882b9a79e0c2bdc6f314880",
      "old_mode": 33188,
      "old_path": "arch/x86/kernel/hpet.c",
      "new_id": "2bda5f0052f72bee45b34c4f192937a625a36d5a",
      "new_mode": 33188,
      "new_path": "arch/x86/kernel/hpet.c"
    }
  ]
}
