)]}'
{
  "commit": "fa6a1a554b50cbb7763f6907e6fef927ead480d9",
  "tree": "9af94b945a5f10eaf2670ac14595db057d98054c",
  "parents": [
    "d0974b11e0741034fc5d22838b9cb85402a280d6"
  ],
  "author": {
    "name": "David P. Reed",
    "email": "dpreed@reed.com",
    "time": "Wed Nov 14 17:49:21 2007 -0500"
  },
  "committer": {
    "name": "Thomas Gleixner",
    "email": "tglx@apollo.(none)",
    "time": "Sat Nov 17 16:27:01 2007 +0100"
  },
  "message": "ntp: fix typo that makes sync_cmos_clock erratic\n\nFix a typo in ntp.c that has caused updating of the persistent (RTC)\nclock when synced to NTP to behave erratically.\n\nWhen debugging a freeze that arises on my AMD64 machines when I\nrun the ntpd service, I added a number of printk\u0027s to monitor the\nsync_cmos_clock procedure.  I discovered that it was not syncing to\ncmos RTC every 11 minutes as documented, but instead would keep trying\nevery second for hours at a time.  The reason turned out to be a typo\nin sync_cmos_clock, where it attempts to ensure that\nupdate_persistent_clock is called very close to 500 msec. after a 1\nsecond boundary (required by the PC RTC\u0027s spec). That typo referred to\n\"xtime\" in one spot, rather than \"now\", which is derived from \"xtime\"\nbut not equal to it.  This makes the test erratic, creating a\n\"coin-flip\" that decides when update_persistent_clock is called - when\nit is called, which is rarely, it may be at any time during the one\nsecond period, rather than close to 500 msec, so the value written is\nneedlessly incorrect, too.\n\nSigned-off-by: David P. Reed\nSigned-off-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\n\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "de6a2d6b3ebb69ad65f1491e9f44a846e1b86f44",
      "old_mode": 33188,
      "old_path": "kernel/time/ntp.c",
      "new_id": "14a2ecf2b318f82bd87d22031da05738e3773fd4",
      "new_mode": 33188,
      "new_path": "kernel/time/ntp.c"
    }
  ]
}