On 06/19, Daniel Vetter wrote:
> On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter wrote:
> > The actual bug we seem to have is blowing up on the ggtt_unpin in
> > context_fini. Which is doubly-impossible: Gen4 doesn't have hw
> > contexts, so should have dctx->obj == NULL. And ring init failures
>
On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter wrote:
> The actual bug we seem to have is blowing up on the ggtt_unpin in
> context_fini. Which is doubly-impossible: Gen4 doesn't have hw
> contexts, so should have dctx->obj == NULL. And ring init failures
> fail earlier so shouldn't even hit the
Hm, that's a bit unexpected. You are on a gen4 device, which means
we'll return the right error in the same function after a few more
register writes. But those are harmless.
On gen5+ we do more (call the pipe_control setup code), which could
potentially clobber the error code. So your patch
On 06/19, Daniel Vetter wrote:
> On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz
> wrote:
> > This commit add check for return value of init_ring_common() in the
> > init_render_ring(). Now, when failure is detected the error code is
> > propagated to the caller layer instead of being
On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz
wrote:
> This commit add check for return value of init_ring_common() in the
> init_render_ring(). Now, when failure is detected the error code is
> propagated to the caller layer instead of being ignored.
>
> I believe that this fix will have a
On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz
bergo.tor...@gmail.com wrote:
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller layer instead of being ignored.
I believe that
On 06/19, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 12:38 AM, Konrad Zapalowicz
bergo.tor...@gmail.com wrote:
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller layer instead of
Hm, that's a bit unexpected. You are on a gen4 device, which means
we'll return the right error in the same function after a few more
register writes. But those are harmless.
On gen5+ we do more (call the pipe_control setup code), which could
potentially clobber the error code. So your patch
On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The actual bug we seem to have is blowing up on the ggtt_unpin in
context_fini. Which is doubly-impossible: Gen4 doesn't have hw
contexts, so should have dctx-obj == NULL. And ring init failures
fail earlier so
On 06/19, Daniel Vetter wrote:
On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The actual bug we seem to have is blowing up on the ggtt_unpin in
context_fini. Which is doubly-impossible: Gen4 doesn't have hw
contexts, so should have dctx-obj == NULL. And ring
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller layer instead of being ignored.
I believe that this fix will have a positive impact on the oops that
I hit recently and which starts
This commit add check for return value of init_ring_common() in the
init_render_ring(). Now, when failure is detected the error code is
propagated to the caller layer instead of being ignored.
I believe that this fix will have a positive impact on the oops that
I hit recently and which starts
12 matches
Mail list logo
