These cases regressed due to below commit.

commit deb6dd6b4df7324b4b240799029a80db65b89d96
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Jan 4 18:02:49 2012 -0800

    i965: Turn on ARB_depth_buffer_float by default.

    Everything about this that we have tests for works except for the
    deprecated metaops.  The conclusion we came to on IRC sounded like we
    were OK with turning it on as long as core functionality works.  The
    remaining failures (copypixels, drawpixels) should just be a matter of
    finishing the MapRenderbuffer for them.

    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This bug appears to be fixed by Brian's renderbuffer-cleanups-v2 branch.

Can't reproduce currently on 8.0 or master.

With Brian's renderbuffer-cleanups-v2 branch merged, this test passes on master and 8.0-rc2 on my SNB GT2 mobile (8086:0126 (rev 09)).

System Environment:
--------------------------
Libdrm:         (master)2.4.30-18-gb643b0713aefdc0611e47654e88263b53b0de6f5
Mesa:           (8.0)caebd7929dca802ece8ef36b0f85094d66133b57
Xserver:                (server-1.11-branch)xorg-server-1.11.3
Xf86_video_intel:              
(master)2.17.0-599-gca252e5b51d7b2f5a7b2c2e0d8fdb024b08096db

verify with mesa 8.0 branch, some subcases can passed on huronriver.
such as:
(GL30)vao(advanced.deletion.vao)
(GL30)vao(basic.stateChange.colorArray)
......

but some subcases still failed on huronriver, they passed ever before.
such as:
(GL30)vao(advanced.mixEnables.basic) 
(GL30)vao(advanced.mixEnables.shadersAttr) 
(GL30)vao(advanced.sharingVBOs.basic)
(GL30)vao(advanced.stateChange.allArrays)
(GL30)vao(advanced.stateChange.attribArrays)
(GL30)vao(advanced.stateChange.colorArray)
(GL30)vao(advanced.stateChange.elementArrays)
(GL30)vao(advanced.stateChange.fogCoordArray)
(GL30)vao(advanced.stateChange.normalArray)
(GL30)vao(advanced.stateChange.secColorArray)
(GL30)vao(advanced.stateChange.texCoordArray)
(GL30)vao(advanced.vboChangeData.viaBufferData)
(GL30)vao(advanced.vboChangeData.viaBufferSubdata)
(GL30)vao(advanced.vboChangeData.viaMapping)

(In reply to comment #4)
> With Brian's renderbuffer-cleanups-v2 branch merged, this test passes on master
> and 8.0-rc2 on my SNB GT2 mobile (8086:0126 (rev 09)).

I did some analysis on these failing test cases today.

These all pass on RGBA FBConfigs.  They all fail on 16 RGBx visuals.

Passing FBConfigs (RGBA 8 8 8 8) are:
145 140 139 121 116 115 146 122 137 136 113 112 138 114 135 111

Failing FBConfigs (RGBx 8 8 8 0) are:
143 134 133 119 110 109 144 120 131 130 107 106 132 108 129 105

In each case, the failure mode is that OGLconform expects to read back four values (R, G, B, A) and instead finds (R, G, B, 1).  The vertex shader passes the color to the fragment shader, which writes it straight to gl_FragColor.  If they're rendering to a window, they have no alpha bits, so we read back "1.0".

Based on this observation, I believe that this is actually a bug in OGLconform: it expects to be able to read back RGBA when it doesn't have an alpha channel.  These tests should all be blacklisted when alphaBits == 0.  I'm guessing that either the Windows driver doesn't expose RGBx window formats or they implicitly promote it to RGBA (as we do), but fail to rewrite the A component to 1.0 during readback.  Either way, it is not our bug.

These test failures are also independent of the depth buffer float commit referenced in the original report.  I tried 7.11, deb6dd6b~1, and master on the RGBx FBConfigs and only saw fixes, not regressions.

I would advocate closing this as NOTOURBUG and removing it from the blocker list.  If someone would like to patch OGLconform, that might be worthwhile.

Every single time I looked at the output from this test, I read it backwards.  I read that it was expecting 1.0 but got something else.  Your analysis is completely correct.  However, there was a bug, and I fixed it.  I think RESOLVED/FIXED is correct.

Xun or Gordon, does that sound acceptable?

I'm fine to closing this. It would be great if you could produce the test fix based on the analysis. (Is that eaasy? I haven't looked into this)

Alright, I've got an OGLconform patch.  I'll send it to you.  Closing as fixed.

Verified with latest oglconform.