You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
migrated from Bugzilla #98311
status ASSIGNED severity normal in component intel for ---
Reported in version unspecified on platform Other
Assigned to: haihao
3 0x00000000004485e0 in JPEG::Encode::JPEGEncodeInputTest_Full_Test::TestBody (this=0x9cd820) at i965_jpeg_encode_test.cpp:457
i965 = 0x9c2900
4 0x00000000005645be in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void> (object=0x9cd820, method=&virtual testing::Test::TestBody(), location=0x6e1bdb "the test body") at ../test/gtest/src/gtest.cc:2402
No locals.
5 0x000000000055f350 in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=0x9cd820, method=&virtual testing::Test::TestBody(), location=0x6e1bdb "the test body") at ../test/gtest/src/gtest.cc:2438
No locals.
6 0x000000000054564c in testing::Test::Run (this=0x9cd820) at ../test/gtest/src/gtest.cc:2475
impl = 0x954e00
7 0x0000000000545ebc in testing::TestInfo::Run (this=0x990260) at ../test/gtest/src/gtest.cc:2656
13 0x0000000000468fc5 in RUN_ALL_TESTS () at ../test/gtest/include/gtest/gtest.h:2233
No locals.
14 0x0000000000468f3a in main (argc=1, argv=0x7fffffffd808) at test_main.cpp:35
No locals.
On 2016-10-18 18:58:42 +0000, U. Artie Eoff wrote:
Created attachment 127384
gdb trace with drm bufmgr debug on
On 2016-10-18 19:02:25 +0000, U. Artie Eoff wrote:
Created attachment 127388
additional gdb data
On 2016-10-18 19:08:04 +0000, U. Artie Eoff wrote:
The bus error is triggered when the test tries to access the data pointer returned by i965_MapBuffer of the derived image.
On 2016-10-18 21:07:58 +0000, U. Artie Eoff wrote:
AFAICT, we are failing to read from the drm mmap'd region... mmap documentation says:
Use of a mapped region can result in these signals:
SIGSEGV
Attempted write into a region mapped as read-only.
SIGBUS Attempted access to a portion of the buffer that does not
correspond to the file (for example, beyond the end of the
file, including the case where another process has truncated
the file).
If I'm reading it correctly and since the mmap call does not fail, something must have truncated it before we try to use it? But what/how?
On 2016-10-19 13:52:09 +0000, haihao wrote:
Is the buffer tiled?
On 2016-10-19 13:55:35 +0000, U. Artie Eoff wrote:
(In reply to haihao from comment # 6)
Is the buffer tiled?
dri_bo_get_tiling in i965_MapBuffer returns 2 for tiling
On 2016-10-19 14:24:20 +0000, U. Artie Eoff wrote:
(In reply to U. Artie Eoff from comment # 7)
(In reply to haihao from comment # 6)
Is the buffer tiled?
dri_bo_get_tiling in i965_MapBuffer returns 2 for tiling
Furthermore, the returned [mmap'd] buffer comes from intel_bufmgr_gem.c:map_gtt(...)
On 2016-10-20 16:20:27 +0000, U. Artie Eoff wrote:
When I execute from within a graphical environment, I always encounter this issue. I am using gnome for my graphical env.
However, if I vt-switch into a non-graphical console, I do not encounter this issue when executing from there.
On 2016-10-24 04:56:12 +0000, haihao wrote:
I can't reproduce it in the graphics env. I ran the test case 100 times without any issue.
I can always reproduce this issue with kernel 4.5.0-rc4+ with/without graphical env. The issue is gone after switching kernel to 4.8.0-rc8+.
Could you try a recent kernel to see the issue is still there? I will mark the bug as resolved if the test case works fine with a recent kernel.
On 2016-10-25 20:44:07 +0000, U. Artie Eoff wrote:
I tried kernel 4.8.0-rc8 and the issue is still there. I also encounter this issue with and without a graphical session on this kernel.
On 2016-10-25 23:07:35 +0000, Sean V Kelley wrote:
Yes, I was going to say I've been using 4.8 on Arch and the issue is always there.
Sean
On 2016-10-25 23:37:06 +0000, U. Artie Eoff wrote:
(In reply to Sean V Kelley from comment # 17)
Yes, I was going to say I've been using 4.8 on Arch and the issue is always
there.
Sean
My last result was from upstream kernel at tag v4.8-rc8, which is not v4.8-rc8+ as Haihao tested. @haihao, can you be more specific about which commit id you are on with v4.8-rc8+? @sean, is your kernel a 4.8 "final" or an "rc" release?
I'm trying 4.9.0-rc2+ (i.e. 9fe68cad6e74) right now, and so far I am not seeing the issue with this version after ~100 executions.
Yes, I was going to say I've been using 4.8 on Arch and the issue is always
there.
Sean
My last result was from upstream kernel at tag v4.8-rc8, which is not v4.8-rc8+
as Haihao tested. @haihao, can you be more specific about which commit id you
are on with v4.8-rc8+? @sean, is your kernel a 4.8 "final" or an "rc" release?
I'm trying 4.9.0-rc2+ (i.e. 9fe68cad6e74) right now, and so far I am not seeing
the issue with this version after ~100 executions.
You are receiving this mail because:
You are the QA Contact for the bug.
On 2016-10-26 08:52:49 +0000, haihao wrote:
It is hard for us too find the root cause if we don't look into the i915. If we want to know the root cause, I think a better way is find a good commit and a bad commit, then do bisect.
In addition, we can make sure it is not a driver issue if the test case works well with a recent kernel.
On 2016-10-26 15:42:43 +0000, U. Artie Eoff wrote:
I continuously ran the test overnight with kernel.org 4.9.0-rc2+ (i.e. 9fe68cad6e74) and have not encountered this issue.
Yes, I agree. We should understand the root-cause even if it's kernel related and not a driver issue. That way, if this issue shows up again in the future, we can save time by investigating the direct cause. So far, it appears kernel related. Or maybe it's a compatibility issue with userspace libdrm and kernel version?
I am not sure what the chronological relationship is between drm-intel-nightly and kernel.org. So if you're going to bisect i915, use kernel.org since there is a good and bad there. Unfortunately, 4.8.4 is the latest mainstream stable release which Sean confirmed is bad. And other distros are on slightly older versions. So if we can understand the cause, perhaps we can come up with a driver solution to WA it for now.
On 2016-11-02 17:32:44 +0000, Sean V Kelley wrote:
Yes, the most important thing is that we need to be able to isolate the root cause as we can hardly promote the framework if we don't know the cause for the errors. It is good to bisect the kernel and map that to libdrm versions. I get very wary of using non stable kernels in this testing. Try to start from the Quarterly release BKC.
Sean
The text was updated successfully, but these errors were encountered:
This issue can not be duplicated on SKL platform with intel-vaapi-driver 1.8.3.pre1, try 20 times
enc:
platform : SKL
linux kernel: 4.12.0-rc2
Libva :1.8.3.pre1
Libva- intel-driver :1.8.3.pre1
libva-utils : 1.8.3.pre1
Typical invocation:
for i in seq 1 20; do ./test_i965_drv_video --gtest_filter=Big/JPEGEncodeInputTest.Full/2; done
migrated from Bugzilla #98311
status ASSIGNED severity normal in component intel for ---
Reported in version unspecified on platform Other
Assigned to: haihao
Original attachment names and IDs:
On 2016-10-18 18:56:01 +0000, U. Artie Eoff wrote:
On 2016-10-18 18:57:00 +0000, U. Artie Eoff wrote:
On 2016-10-18 18:58:42 +0000, U. Artie Eoff wrote:
On 2016-10-18 19:02:25 +0000, U. Artie Eoff wrote:
On 2016-10-18 19:08:04 +0000, U. Artie Eoff wrote:
On 2016-10-18 21:07:58 +0000, U. Artie Eoff wrote:
On 2016-10-19 13:52:09 +0000, haihao wrote:
On 2016-10-19 13:55:35 +0000, U. Artie Eoff wrote:
On 2016-10-19 14:24:20 +0000, U. Artie Eoff wrote:
On 2016-10-20 16:20:27 +0000, U. Artie Eoff wrote:
On 2016-10-24 04:56:12 +0000, haihao wrote:
On 2016-10-24 05:10:38 +0000, haihao wrote:
On 2016-10-24 05:12:36 +0000, haihao wrote:
On 2016-10-24 17:54:27 +0000, U. Artie Eoff wrote:
On 2016-10-24 19:07:46 +0000, U. Artie Eoff wrote:
On 2016-10-25 04:44:18 +0000, haihao wrote:
On 2016-10-25 20:44:07 +0000, U. Artie Eoff wrote:
On 2016-10-25 23:07:35 +0000, Sean V Kelley wrote:
On 2016-10-25 23:37:06 +0000, U. Artie Eoff wrote:
On 2016-10-26 00:45:23 +0000, haihao wrote:
On 2016-10-26 06:46:19 +0000, Sean V Kelley wrote:
On 2016-10-26 06:50:41 +0000, Sean V Kelley wrote:
On 2016-10-26 08:52:49 +0000, haihao wrote:
On 2016-10-26 15:42:43 +0000, U. Artie Eoff wrote:
On 2016-11-02 17:32:44 +0000, Sean V Kelley wrote:
The text was updated successfully, but these errors were encountered: