Re: [alsa-devel] [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)
On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote:
On Wednesday 16 March 2016 10:48:43 Imre Deak wrote:
Tomi, noticed two things that maybe infrastructure related, see below:
Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test gem_ringfill: Subgroup basic-default-s3: pass -> DMESG-WARN (skl-nuci5) Test gem_storedw_loop: Subgroup basic-bsd: pass -> DMESG-WARN (skl-nuci5) Subgroup basic-bsd1: pass -> DMESG-WARN (skl-nuci5)
Unrelated platform. All of the above are SND resume failures. Ville said he contacted Takashi about them.
SND is recurring problem. I'd like to see drm-intel-nightly not breaking when pulling sound updates.
We need to escalate this again, snd team seriously sucks at quality control :( Adding Libin&Takashi. If this doesn't improve I need to throw sound trees out of -nightly for real. -Daniel
On Wed, 16 Mar 2016 16:37:06 +0100, Daniel Vetter wrote:
On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote:
On Wednesday 16 March 2016 10:48:43 Imre Deak wrote:
Tomi, noticed two things that maybe infrastructure related, see below:
Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test gem_ringfill: Subgroup basic-default-s3: pass -> DMESG-WARN (skl-nuci5) Test gem_storedw_loop: Subgroup basic-bsd: pass -> DMESG-WARN (skl-nuci5) Subgroup basic-bsd1: pass -> DMESG-WARN (skl-nuci5)
Unrelated platform. All of the above are SND resume failures. Ville said he contacted Takashi about them.
SND is recurring problem. I'd like to see drm-intel-nightly not breaking when pulling sound updates.
We need to escalate this again, snd team seriously sucks at quality control :( Adding Libin&Takashi. If this doesn't improve I need to throw sound trees out of -nightly for real.
Sorry about that, but I couldn't get the warning on my machine.
How is the procedure to reproduce the bug? Please give the exact commit id and environment you're testing, too.
Takashi
On Wednesday 16 March 2016 16:40:24 Takashi Iwai wrote:
On Wed, 16 Mar 2016 16:37:06 +0100, Daniel Vetter wrote:
On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote:
SND is recurring problem. I'd like to see drm-intel-nightly not breaking when pulling sound updates.
We need to escalate this again, snd team seriously sucks at quality control :( Adding Libin&Takashi. If this doesn't improve I need to throw sound trees out of -nightly for real.
Sorry about that, but I couldn't get the warning on my machine.
How is the procedure to reproduce the bug? Please give the exact commit id and environment you're testing, too.
Our CI has been built to mimic user environment, so base is up-to-date Ubuntu 15.04. This affects to boot-up mechanics and usermode software versions. There are about dozen machines, 8 gens, from ILK to SKL.
Reproduction: CI is doing these steps
- Compile kernel: CI_DRM is drm-intel-nightly HEAD - Deploy it to testhost: copy to /boot, recreate initrd - Boot testhost to init 3 - Run newest IGT/piglit with basic testset - Collect results
The last commits tested are:
CI_DRM_1140 git://anongit.freedesktop.org/drm-intel 3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979
CI_DRM_1141 git://anongit.freedesktop.org/drm-intel fc881ebd9c3c26919c7d1113f8bf7014e1a05563
CI_DRM_1142 git://anongit.freedesktop.org/drm-intel 9f8709ffd099e85e5e116ed7d09f1b8009f40847
CI_DRM_1143 git://anongit.freedesktop.org/drm-intel 5356c22379fc96cb087ee59bfdbbe46ec3bdf654
CI_DRM_1144 git://anongit.freedesktop.org/drm-intel a5c43f5d1b4968a370f54bdda5387ce213aca785
CI_DRM_1145 git://anongit.freedesktop.org/drm-intel bf3dcd53821a7d6c81f7061c6c7956aad57ec615
CI_DRM_1146 git://anongit.freedesktop.org/drm-intel be0d1481fb1a2fd1cb199b81c9c01154a78d43dd
CI_DRM_1147 git://anongit.freedesktop.org/drm-intel dbbc6d276864d7b7a3a1edb04f0511153f9c3852
Note that drm-intel-nightly history changes, so the exact commits might not be there any more.
Tomi
On Thu, 17 Mar 2016 08:57:23 +0100, Tomi Sarvela wrote:
On Wednesday 16 March 2016 16:40:24 Takashi Iwai wrote:
On Wed, 16 Mar 2016 16:37:06 +0100, Daniel Vetter wrote:
On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote:
SND is recurring problem. I'd like to see drm-intel-nightly not breaking when pulling sound updates.
We need to escalate this again, snd team seriously sucks at quality control :( Adding Libin&Takashi. If this doesn't improve I need to throw sound trees out of -nightly for real.
Sorry about that, but I couldn't get the warning on my machine.
How is the procedure to reproduce the bug? Please give the exact commit id and environment you're testing, too.
Our CI has been built to mimic user environment, so base is up-to-date Ubuntu 15.04. This affects to boot-up mechanics and usermode software versions. There are about dozen machines, 8 gens, from ILK to SKL.
Reproduction: CI is doing these steps
- Compile kernel: CI_DRM is drm-intel-nightly HEAD
- Deploy it to testhost: copy to /boot, recreate initrd
- Boot testhost to init 3
- Run newest IGT/piglit with basic testset
- Collect results
The last commits tested are:
CI_DRM_1140 git://anongit.freedesktop.org/drm-intel 3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979
CI_DRM_1141 git://anongit.freedesktop.org/drm-intel fc881ebd9c3c26919c7d1113f8bf7014e1a05563
CI_DRM_1142 git://anongit.freedesktop.org/drm-intel 9f8709ffd099e85e5e116ed7d09f1b8009f40847
CI_DRM_1143 git://anongit.freedesktop.org/drm-intel 5356c22379fc96cb087ee59bfdbbe46ec3bdf654
CI_DRM_1144 git://anongit.freedesktop.org/drm-intel a5c43f5d1b4968a370f54bdda5387ce213aca785
CI_DRM_1145 git://anongit.freedesktop.org/drm-intel bf3dcd53821a7d6c81f7061c6c7956aad57ec615
CI_DRM_1146 git://anongit.freedesktop.org/drm-intel be0d1481fb1a2fd1cb199b81c9c01154a78d43dd
CI_DRM_1147 git://anongit.freedesktop.org/drm-intel dbbc6d276864d7b7a3a1edb04f0511153f9c3852
Note that drm-intel-nightly history changes, so the exact commits might not be there any more.
Well, I have no internal access, so I have no idea which one succeeded and which one failed.
Unfortunately I can't reproduce it in my side. A simpler unit test that can reliably reproduce the issue would be really appreciated...
thanks,
Takashi
On Thursday 17 March 2016 18:00:52 Takashi Iwai wrote: ...
CI_DRM_1147 git://anongit.freedesktop.org/drm-intel dbbc6d276864d7b7a3a1edb04f0511153f9c3852
Note that drm-intel-nightly history changes, so the exact commits might not be there any more.
Well, I have no internal access, so I have no idea which one succeeded and which one failed.
Unfortunately I can't reproduce it in my side. A simpler unit test that can reliably reproduce the issue would be really appreciated...
Sorry, I was being unclear. They all fail on selected machines (ILK, SNB), since CI_DRM_1140.
The unit tests that hang quite reliably on first run are igt@gem_ringfill_basic-default-s3 igt@drv_module_reload_basic igt@kms_pipe_crc_basic@suspend-read-crc-pipe-[abc]
Tomi
On Fri, 18 Mar 2016 08:36:27 +0100, Tomi Sarvela wrote:
On Thursday 17 March 2016 18:00:52 Takashi Iwai wrote: ...
CI_DRM_1147 git://anongit.freedesktop.org/drm-intel dbbc6d276864d7b7a3a1edb04f0511153f9c3852
Note that drm-intel-nightly history changes, so the exact commits might not be there any more.
Well, I have no internal access, so I have no idea which one succeeded and which one failed.
Unfortunately I can't reproduce it in my side. A simpler unit test that can reliably reproduce the issue would be really appreciated...
Sorry, I was being unclear. They all fail on selected machines (ILK, SNB), since CI_DRM_1140.
Do you have the commit of the last working kernel?
The unit tests that hang quite reliably on first run are igt@gem_ringfill_basic-default-s3 igt@drv_module_reload_basic igt@kms_pipe_crc_basic@suspend-read-crc-pipe-[abc]
Where can I get these?
Takashi
On Friday 18 March 2016 09:00:13 Takashi Iwai wrote:
On Fri, 18 Mar 2016 08:36:27 +0100,
Do you have the commit of the last working kernel?
The unit tests that hang quite reliably on first run are igt@gem_ringfill_basic-default-s3 igt@drv_module_reload_basic igt@kms_pipe_crc_basic@suspend-read-crc-pipe-[abc]
Where can I get these?
IGT is intel-gpu-tools, hardware unittests using piglit as a base. CI runs BAT (Basic Acceptance Tests), a set of IGT tests: around 200 tests, runs under 10 minutes. Can be run with ${IGT_PATH}/scripts/run-tests.sh -t basic
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
http://anongit.freedesktop.org/git/piglit.git
Latest working drm-intel commit was CI_DRM_1139: 3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 2016-03-14_09-06-45 drm-intel-nightly: 2016y-03m-14d-09h-06m-00s UTC integration manifest
Best Regards,
Tomi
On Fri, 18 Mar 2016 09:12:53 +0100, Tomi Sarvela wrote:
On Friday 18 March 2016 09:00:13 Takashi Iwai wrote:
On Fri, 18 Mar 2016 08:36:27 +0100,
Do you have the commit of the last working kernel?
The unit tests that hang quite reliably on first run are igt@gem_ringfill_basic-default-s3 igt@drv_module_reload_basic igt@kms_pipe_crc_basic@suspend-read-crc-pipe-[abc]
Where can I get these?
IGT is intel-gpu-tools, hardware unittests using piglit as a base. CI runs BAT (Basic Acceptance Tests), a set of IGT tests: around 200 tests, runs under 10 minutes. Can be run with ${IGT_PATH}/scripts/run-tests.sh -t basic
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
http://anongit.freedesktop.org/git/piglit.git
Latest working drm-intel commit was CI_DRM_1139: 3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 2016-03-14_09-06-45 drm-intel-nightly: 2016y-03m-14d-09h-06m-00s UTC integration manifest
There were a few different kernel warnings, so this date is possibly a red herring. One is the kernel warning from pin2port(), and this has nothing to do with Skylake. It's being addressed now.
The problem I can't follow is the PM refcount unbalance found on Skylake. It'd be helpful if you can give the exact *minimal* reproducer. The warning shows the result, and it means that something wrong did happen before that. So, we need the procedure until that point, not the point of the outcome.
thanks,
Takashi
On Wed, 16 Mar 2016, Daniel Vetter daniel@ffwll.ch wrote:
[ text/plain ] On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote:
On Wednesday 16 March 2016 10:48:43 Imre Deak wrote:
Tomi, noticed two things that maybe infrastructure related, see below:
Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test gem_ringfill: Subgroup basic-default-s3: pass -> DMESG-WARN (skl-nuci5) Test gem_storedw_loop: Subgroup basic-bsd: pass -> DMESG-WARN (skl-nuci5) Subgroup basic-bsd1: pass -> DMESG-WARN (skl-nuci5)
Unrelated platform. All of the above are SND resume failures. Ville said he contacted Takashi about them.
SND is recurring problem. I'd like to see drm-intel-nightly not breaking when pulling sound updates.
We need to escalate this again, snd team seriously sucks at quality control :( Adding Libin&Takashi. If this doesn't improve I need to throw sound trees out of -nightly for real.
With that, we'd get more stable CI, but we'd also only see the failures once the sound trees get merged upstream. We don't want that either.
One idea would be to have separate CI runs for updating trees not in our control. But we're pretty far from making that happen.
BR, Jani.
On Wed, Mar 16, 2016 at 4:50 PM, Jani Nikula jani.nikula@linux.intel.com wrote:
On Wed, 16 Mar 2016, Daniel Vetter daniel@ffwll.ch wrote:
[ text/plain ] On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote:
On Wednesday 16 March 2016 10:48:43 Imre Deak wrote:
Tomi, noticed two things that maybe infrastructure related, see below:
Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test gem_ringfill: Subgroup basic-default-s3: pass -> DMESG-WARN (skl-nuci5) Test gem_storedw_loop: Subgroup basic-bsd: pass -> DMESG-WARN (skl-nuci5) Subgroup basic-bsd1: pass -> DMESG-WARN (skl-nuci5)
Unrelated platform. All of the above are SND resume failures. Ville said he contacted Takashi about them.
SND is recurring problem. I'd like to see drm-intel-nightly not breaking when pulling sound updates.
We need to escalate this again, snd team seriously sucks at quality control :( Adding Libin&Takashi. If this doesn't improve I need to throw sound trees out of -nightly for real.
With that, we'd get more stable CI, but we'd also only see the failures once the sound trees get merged upstream. We don't want that either.
One idea would be to have separate CI runs for updating trees not in our control. But we're pretty far from making that happen.
Yes agreed, it would probably not help a lot at all to drop sound trees, we'd simply notice a bit later. I'm not sure what would be the best option here, just expressing maintainer grumpiness ;-) Good ideas very much welcome ... -Daniel
participants (4)
-
Daniel Vetter -
Jani Nikula -
Takashi Iwai -
Tomi Sarvela