)]}'
{
  "log": [
    {
      "commit": "969830b2fedf8336c41d6195f49d250b1e166ff8",
      "tree": "ba7eec39395531b9baf62a0e13a875f085524409",
      "parents": [
        "2b26736c88db85c038e04c2306d0745553e69602"
      ],
      "author": {
        "name": "David Miller",
        "email": "davem@davemloft.net",
        "time": "Tue Aug 12 15:08:51 2008 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@linux-foundation.org",
        "time": "Tue Aug 12 16:07:28 2008 -0700"
      },
      "message": "radeonfb: fix accel engine hangs\n\nSome chips appear to have the 2D engine hang during screen redraw,\ntypically in a sequence of copyarea operations. This appear to be\nsolved by adding a flush of the engine destination pixel cache\nand waiting for the engine to be idle before issuing the accel\noperation. The performance impact seems to be fairly small.\n\nHere is a trace on an RV370 (PCI device ID 0x5b64), it records the\nRBBM_STATUS register, then the source x/y, destination x/y, and\nwidth/height used for the copy:\n\n----------------------------------------\nradeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10]\nradeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10]\nradeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10]\nradeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10]\nradeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10]\nradeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10]\nradeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10]\nradeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10]\nradeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10]\nradeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10]\nradeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10]\n----------------------------------------\n\nWhen things are going fine the copies complete before the next ROP is\neven issued, but all of a sudden the 2D unit becomes active (bit 17 in\nRBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit\n14) are set as well.  The FIFO begins to backup until it becomes full.\n\nWhat happens next is the radeon_fifo_wait() times out, and we access\nthe chip illegally leading to a bus error which usually wedges the\nbox.  None of this makes it to the console screen, of course :-)\nradeon_fifo_wait() should be modified to reset the accelerator when\nthis timeout happens instead of programming the chip anyways.\n\n----------------------------------------\nradeonfb: FIFO Timeout !\nERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0)\nERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601]\nERROR(0): TPC\u003cradeonfb_copyarea+0xfc/0x248\u003e\nERROR(0): M_SYND(0),  E_SYND(0), Privileged\nERROR(0): Highest priority error (0000080000000000) \"Bus error response from system bus\"\nERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]\nERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]\nERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\\\n\nERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]\nERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]\nERROR(0): E-cache idx[800e40] tag[000000000e049f4c]\nERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000]\nKer:xnel panic - not syncing: Irrecoverable deferred error trap.\n----------------------------------------\n\nAnother quirk is that these copyarea calls will not happen until the\nfirst drivers/char/vt.c:redraw_screen() occurs.  This will only happen\nif you 1) VC switch or 2) run \"consolechars\" or 3) unblank the screen.\n\nThis seems to happen because until a redraw_screen() the screen scrolling\nmethod used by fbcon is not finalized yet.  I\u0027ve seen this with other fb\ndrivers too.\n\nSo if all you do is boot straight into X you will never see this bug on\nthe relevant chips.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\nSigned-off-by: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\nCc: \u003cstable@kernel.org\u003e\t\t[2.6.25.x, 2.6.26.x]\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "efc491814308f89d5ef6c4fe19ae4552a67d4132",
      "tree": "2e00231a9ac9221ebb52cedf8249db0441603094",
      "parents": [
        "f6ac436dcc4c34709bcde355f3f2254ac0a183d4"
      ],
      "author": {
        "name": "David Miller",
        "email": "davem@davemloft.net",
        "time": "Tue Aug 05 13:01:25 2008 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@linux-foundation.org",
        "time": "Tue Aug 05 14:33:49 2008 -0700"
      },
      "message": "radeon: misc corrections\n\nI have a new PCI-E radeon RV380 series card (PCI device ID 5b64) that\nhangs in my sparc64 boxes when the init scripts set the font.  The problem\ngoes away if I disable acceleration.\n\nI haven\u0027t figured out that bug yet, but along the way I found some\ncorrections to make based upon some auditing.\n\n1) The RB2D_DC_FLUSH_ALL value used by the kernel fb driver\n   and the XORG video driver differ.  I\u0027ve made the kernel\n   match what XORG is using.\n\n2) In radeonfb_engine_reset() we have top-level code structure\n   that roughly looks like:\n\n\tif (family is 300, 350, or V350)\n\t\tdo this;\n\telse\n\t\tdo that;\n\t...\n\tif (family is NOT 300, OR\n\t    family is NOT 350, OR\n\t    family is NOT V350)\n\t\tdo another thing;\n\n   this last conditional makes no sense, is always true,\n   and obviously was likely meant to be \"family is NOT\n   300, 350, or V350\".  So I\u0027ve made the code match the\n   intent.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\nAcked-by: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\nTested-by: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
      "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d",
      "parents": [],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n"
    }
  ]
}