Bug 57441

Works like a charm for me. I guess this is a regression? As a first step please check whether you have actually permission to read the files. If that turns up nothing and it's a regression, please bisect.

(In reply to comment #1)
> Works like a charm for me. I guess this is a regression? As a first step
> please check whether you have actually permission to read the files. If that
> turns up nothing and it's a regression, please bisect.

This case only failed on HSW machine.
I used the same Hard Disk on other platform, this case can passed.
I have checked some older kernels, but I can't find a good point.

Created attachment 71023 [details] [review]
fixup l3 parity sysfs check on hsw

This should fix the testcase. Please test whether nothing else blows up now, thanks.

(In reply to comment #3)
> Created attachment 71023 [details] [review] [review]
> fixup l3 parity sysfs check on hsw
> 
> This should fix the testcase. Please test whether nothing else blows up now,
> thanks.

The first commit in the attachment d22555f6cf3b93206e570eda14eb2d5ebd9d125c , I can't find it in -next-queued branch.

But the followed two commit I founded.

I pulled the latest source to commit 717d08697593b87501614346590a2b9a1d76be39, then builded a kernel and tested the case, it's also failed.

Can you tell me d22555f6cf3b93206e570eda14eb2d5ebd9d125c  is on which branch?

Whether you have pushed? 

thanks for your help.

> --- Comment #4 from shui yangwei <yangweix.shui@intel.com> ---
> Whether you have pushed?

I haven't pushed it anywhere, it's just a patch in git format - but
you can apply it like any other patch with

$ patch -p1 -i <filename.patch>

Patch merged to -fixes as

commit ebf69cb8331d7336e4bcd442a2ca69bb61739a58
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 5 09:52:14 2012 +0100

    drm/i915: fixup l3 parity sysfs access check

Created attachment 71076 [details]
sysfs_l3_parity dmesg

(In reply to comment #6)
> Patch merged to -fixes as
> 
> commit ebf69cb8331d7336e4bcd442a2ca69bb61739a58
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Dec 5 09:52:14 2012 +0100
> 
>     drm/i915: fixup l3 parity sysfs access check


I test with this commit, after running, STD output "Fail".

Indeed, register writes to the l3 remapping range seem to simply get dropped on the floor on hsw. Reopening and assigning to Ben

Ben have you had a chance to look at this yet?  Hopefully something simple...

(In reply to comment #9)
> Ben have you had a chance to look at this yet?  Hopefully something simple...

I am without a stable HSW platform at the moment. The platform I was using just ate my harddrive.

https://patchwork.kernel.org/patch/2142561/

Please test, thanks.

(In reply to comment #11)
> https://patchwork.kernel.org/patch/2142561/
> 
> Please test, thanks.

I retest with this patch but still fail on HSW.

I attached the dmesg.

Created attachment 74964 [details]
sysfs_l3_parit-20130217.dmesg

I patched the patch on latest drm-intel-fixes branch.

Kernel commit 4518f611ba21ba165ea3714055938a8984a44ff9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jan 23 16:16:35 2013 +0100

    drm/i915: dump UTS_RELEASE into the error_state

(In reply to comment #14)
> I patched the patch on latest drm-intel-fixes branch.
> 
> Kernel commit 4518f611ba21ba165ea3714055938a8984a44ff9
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Jan 23 16:16:35 2013 +0100
> 
>     drm/i915: dump UTS_RELEASE into the error_state

Is it the same EPERM error message?

(In reply to comment #15)
> (In reply to comment #14)
> > I patched the patch on latest drm-intel-fixes branch.
> > 
> > Kernel commit 4518f611ba21ba165ea3714055938a8984a44ff9
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date:   Wed Jan 23 16:16:35 2013 +0100
> > 
> >     drm/i915: dump UTS_RELEASE into the error_state
> 
> Is it the same EPERM error message?

Do you mean the error message of "/sys/kernel/debug/dri/0/i915_error_state
"? Sorry, I don't know what you means here. could you give me more statements?  Thanks a lot.

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > I patched the patch on latest drm-intel-fixes branch.
> > > 
> > > Kernel commit 4518f611ba21ba165ea3714055938a8984a44ff9
> > > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Date:   Wed Jan 23 16:16:35 2013 +0100
> > > 
> > >     drm/i915: dump UTS_RELEASE into the error_state
> > 
> > Is it the same EPERM error message?
> 
> Do you mean the error message of "/sys/kernel/debug/dri/0/i915_error_state
> "? Sorry, I don't know what you means here. could you give me more
> statements?  Thanks a lot.

Does you still get?


Reading sysfs: Operation not permitted
Reading sysfs: Operation not permitted
Reading sysfs: Operation not permitted

Created attachment 75720 [details]
sysfs_l3_parity Fail dmesg

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > I patched the patch on latest drm-intel-fixes branch.
> > > > 
> > > > Kernel commit 4518f611ba21ba165ea3714055938a8984a44ff9
> > > > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > Date:   Wed Jan 23 16:16:35 2013 +0100
> > > > 
> > > >     drm/i915: dump UTS_RELEASE into the error_state
> > > 
> > > Is it the same EPERM error message?
> > 
> > Do you mean the error message of "/sys/kernel/debug/dri/0/i915_error_state
> > "? Sorry, I don't know what you means here. could you give me more
> > statements?  Thanks a lot.
> 
> Does you still get?
> 
> 
> Reading sysfs: Operation not permitted
> Reading sysfs: Operation not permitted
> Reading sysfs: Operation not permitted

Oh, I'm sorry that we haven't described clearly. I retest this patch on commit 4518f611ba21ba165ea3714055938a8984a44ff9, the reminder: "Reading sysfs: Operation not permitted" doesn't exist. But this case also come to be "Fail".

A patch referencing this bug report has been merged in Linux v3.9-rc1:

commit eb32e4584d8e9d6cbec20550d4f91396de2cdb55
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Feb 14 19:46:07 2013 +0100

    drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap

Can you please apply this to intel-gpu-tools and send the results?

diff --git a/tests/sysfs_l3_parity b/tests/sysfs_l3_parity
index 6f814a1..4c690e3 100755
--- a/tests/sysfs_l3_parity
+++ b/tests/sysfs_l3_parity
@@ -12,9 +12,10 @@ $SOURCE_DIR/../tools/intel_l3_parity -c
 
 #Check that we can remap a row
 $SOURCE_DIR/../tools/intel_l3_parity 0,0,0
+echo "The exit status was $?"
 disabled=`$SOURCE_DIR/../tools/intel_l3_parity | grep -c 'Row 0, Bank 0, Subbank 0 is disabled'`
 if [ "$disabled" != "1" ] ; then
-       echo "Fail"
+       echo "Fail $disabled"
        exit 1
 fi

(In reply to comment #20)
> Can you please apply this to intel-gpu-tools and send the results?
> 
> diff --git a/tests/sysfs_l3_parity b/tests/sysfs_l3_parity
> index 6f814a1..4c690e3 100755
> --- a/tests/sysfs_l3_parity
> +++ b/tests/sysfs_l3_parity
> @@ -12,9 +12,10 @@ $SOURCE_DIR/../tools/intel_l3_parity -c
>  
>  #Check that we can remap a row
>  $SOURCE_DIR/../tools/intel_l3_parity 0,0,0
> +echo "The exit status was $?"
>  disabled=`$SOURCE_DIR/../tools/intel_l3_parity | grep -c 'Row 0, Bank 0,
> Subbank 0 is disabled'`
>  if [ "$disabled" != "1" ] ; then
> -       echo "Fail"
> +       echo "Fail $disabled"
>         exit 1
>  fi

After I apply this patch, test result is like below:
----------------------------------------
[root@x-hsw24 tests]# ./sysfs_l3_parity
The exit status was 0
Fail 0

(In reply to comment #21)
> (In reply to comment #20)
> > Can you please apply this to intel-gpu-tools and send the results?
> > 
> > diff --git a/tests/sysfs_l3_parity b/tests/sysfs_l3_parity
> > index 6f814a1..4c690e3 100755
> > --- a/tests/sysfs_l3_parity
> > +++ b/tests/sysfs_l3_parity
> > @@ -12,9 +12,10 @@ $SOURCE_DIR/../tools/intel_l3_parity -c
> >  
> >  #Check that we can remap a row
> >  $SOURCE_DIR/../tools/intel_l3_parity 0,0,0
> > +echo "The exit status was $?"
> >  disabled=`$SOURCE_DIR/../tools/intel_l3_parity | grep -c 'Row 0, Bank 0,
> > Subbank 0 is disabled'`
> >  if [ "$disabled" != "1" ] ; then
> > -       echo "Fail"
> > +       echo "Fail $disabled"
> >         exit 1
> >  fi
> 
> After I apply this patch, test result is like below:
> ----------------------------------------
> [root@x-hsw24 tests]# ./sysfs_l3_parity
> The exit status was 0
> Fail 0

Darn, I meant to have it display the output of the tool.

Can you just run this from the command line:
<load drm with debug=0x6>
<load i915>
sudo dmesg -c > /dev/null
sudo <igt_dir>/tools/intel_l3_parity 0,0,0
sudo <igt_dir>/tools/intel_l3_parity

Paste the everything on the command line for the above, and attach the dmesg afterwards, please.

Thanks.

*** Bug 64515 has been marked as a duplicate of this bug. ***

Poke for the information Ben requested.

Created attachment 79599 [details]
dmesg: sysfs_l3_parity debug

(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #20)
> > > Can you please apply this to intel-gpu-tools and send the results?
> > > 
> Can you just run this from the command line:
> <load drm with debug=0x6>
> <load i915>
> sudo dmesg -c > /dev/null
> sudo <igt_dir>/tools/intel_l3_parity 0,0,0
> sudo <igt_dir>/tools/intel_l3_parity
> 
> Paste the everything on the command line for the above, and attach the dmesg
> afterwards, please.

I do it just like the step you described and paste the dmesg here.


Kernel Info:
-----------------------
Kernel: (drm-intel-next-queued)e6c6992522d3f74341f032bda2c76266057cc53b
Some additional commit info:
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Mon May 13 18:12:25 2013 -0300

    drm/i915: Adding more reserved PCI IDs for Haswell.

Please test:
https://patchwork.kernel.org/patch/2853836/

(In reply to comment #26)
> Please test:
> https://patchwork.kernel.org/patch/2853836/

This patch worked. Apply this patch on latest -next-queued kernel, this case passed and return value is 0. I also tried the kernel without the patch, the test result is fail.

Ben, I'm wondering why this bug was set as LOW priority?

Afaik it's mostly a checkbox feature that we should have, but not something customers/users really ask for. Hence the low priority. But Ben's working on a full fix now.

QA, please test.

Fixed on -nightly and -queued kernel.
It still fails on -fixes kernel.

output:
Fail

Yeah, this is only fixed in -next-queued, not -fixes.

(In reply to comment #32)
> Yeah, this is only fixed in -next-queued, not -fixes.

It's working now, verified here.

Closing old verified.