)]}'
{
  "commit": "cd08d0754ecb0cb9293c8476cb33ded1d23d0d8f",
  "tree": "ff22e3f50b9559489737887b070a964c79c3f663",
  "parents": [
    "360624484c81d55f88b1e5f48ce24c9243ce38e5"
  ],
  "author": {
    "name": "Maciej W. Rozycki",
    "email": "macro@linux-mips.org",
    "time": "Thu Jun 19 00:39:33 2008 +0100"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@elte.hu",
    "time": "Tue Jul 08 09:13:24 2008 +0200"
  },
  "message": "x86: fix IO APIC breakage on HP nx6325\n\nOn Thu, 19 Jun 2008, Rafael J. Wysocki wrote:\n\n\u003e \u003e  With such a configuration the \"x86: I/O APIC: timer through 8259A\n\u003e \u003e second-chance\" patch should not matter, because the only change it\n\u003e \u003e introduces is an attempt to try the same I/O APIC pin again, but with the\n\u003e \u003e IRQ0 line of the master 8259A enabled.  That\u0027s not a terribly unusual\n\u003e \u003e configuration and nothing should get confused in the system.\n\u003e\n\u003e But it _does_ get confused, really.\n\n Something certainly gets confused, but so far I am not sure which bit\nexactly it is, are you?\n\n\u003e \u003e  Barring the unlikely possibility of the 8259A actually being wired to\n\u003e \u003e INTIN2 of the I/O APIC I can see two possible explanations:\n\u003e \u003e\n\u003e \u003e 1. The 8259A interrupt actually escapes to the CPU somehow and is handled\n\u003e \u003e    as an ExtINTA interrupt.  This would make the code in check_timer()\n\u003e \u003e    decide it has found a working configuration, while actually it has been\n\u003e \u003e    fooled.\n[...]\n\u003e Here you go:\n\u003e\n\u003e [    0.108006] ..TIMER: vector\u003d0x30 apic1\u003d0 pin1\u003d2 apic2\u003d-1 pin2\u003d-1\n\u003e [    0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC\n\u003e [    0.108006] ...trying to set up timer (IRQ0) through the 8259A ... \u003c3\u003e\n\u003e [    0.108006] ..... (found apic 0 pin 2) ...\u003c3\u003e works.\n\u003e\n\u003e The full dmesg is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-1.log\n\nThanks.  In this case I suspect the case #1 quoted above happens, that is\nthe 8259A manages to deliver its interrupt somehow.  Note at this stage it\nis meant to be in the AEOI mode, so it can happily resubmit the interrupt\nindefinitely with no additional handling as long as it receives INTA\ncycles.\n\nCan you please try the patch below on top of \"x86: I/O APIC: timer\nthrough 8259A second-chance\" to see whether my hypothesis is true?  It\nmodifies the through-8259A setup path so that the APIC input gets masked,\nbut the 8259A has the timer interrupt still enabled.  Let me know how the\ntimer interrupt is routed in this case.\n\nBisected-by: \"Rafael J. Wysocki\" \u003crjw@sisk.pl\u003e\nTested-by: \"Rafael J. Wysocki\" \u003crjw@sisk.pl\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "60a022d6de5e1f7ccb75758a78b339864df0b1ec",
      "old_mode": 33188,
      "old_path": "arch/x86/kernel/io_apic_64.c",
      "new_id": "f06f5b4fb35f5121ad7890b20d0825e0cbfb3e27",
      "new_mode": 33188,
      "new_path": "arch/x86/kernel/io_apic_64.c"
    }
  ]
}