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>

It doesn't look like this actually has anything to do with ARB_depth_float.  My guess is that the test just exercises some different functionality once 3.0 is available.

I've sent a patch to the mesa-dev mailing list that should fix this issue.

http://lists.freedesktop.org/archives/mesa-dev/2012-January/017691.html

Fixed on 8.0 branch by:

commit 0362995e5abd7527e587ed97d2132af29e307a3c
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Tue Jan 17 16:24:05 2012 -0800

    mesa: Set default access flags based on the run-time API
    
    The default access flags for OpenGL ES (via GL_OES_map_buffer) and
    desktop OpenGL are different.  The code previously tried to handle
    this, but the decision was made at compile time.  Since the same
    driver binary can be used for both OpenGL ES and desktop OpenGL, the
    decision must be made at run-time.
    
    This should fix bug #44433.  It appears that the test case does
    various map and unmap operations and inspects the state of the buffer
    object around each.  When it sees that GL_BUFFER_ACCESS does not match
    its expectations, it fails.
    
    NOTE: This is a candidate for release branches.
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44433
    (cherry picked from commit f0ea46790f8f4df9a39b0cfab5c5f1bf02c136fc)

(In reply to comment #4)
> Fixed on 8.0 branch by:
> commit 0362995e5abd7527e587ed97d2132af29e307a3c

That should be 30e9bfd84ad64655a5ed0d1f84f5877cb3ae1b5a

> Author: Ian Romanick <ian.d.romanick@intel.com>
> Date:   Tue Jan 17 16:24:05 2012 -0800
> 
>     mesa: Set default access flags based on the run-time API
> 
>     The default access flags for OpenGL ES (via GL_OES_map_buffer) and
>     desktop OpenGL are different.  The code previously tried to handle
>     this, but the decision was made at compile time.  Since the same
>     driver binary can be used for both OpenGL ES and desktop OpenGL, the
>     decision must be made at run-time.
> 
>     This should fix bug #44433.  It appears that the test case does
>     various map and unmap operations and inspects the state of the buffer
>     object around each.  When it sees that GL_BUFFER_ACCESS does not match
>     its expectations, it fails.
> 
>     NOTE: This is a candidate for release branches.
> 
>     Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
>     Reviewed-by: Brian Paul <brianp@vmware.com>
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44433
>     (cherry picked from commit f0ea46790f8f4df9a39b0cfab5c5f1bf02c136fc)

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, these cases passed on huronriver.
such as:
(GL21)pbo(basic.accessTypeParamTest)
(GL21)pbo(drawPixels.1PBOBufferSubData)
(GL21)pbo(texImage.1PBOBufferSubData)
(GL21)pbo(vboAndFBO.readFromAFBO)
......