i915-infra issueshttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues2020-06-24T13:24:19Zhttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/91Add a tool that checks chamelium state2020-06-24T13:24:19ZArkadiusz HilerAdd a tool that checks chamelium stateFrom time to time [Chameliums](https://www.chromium.org/chromium-os/testing/chamelium) seem to go into weird state. This stops all Chamelium-based testing on that given host. The syndrome is that any connection to chamelium:9992 gets ref...From time to time [Chameliums](https://www.chromium.org/chromium-os/testing/chamelium) seem to go into weird state. This stops all Chamelium-based testing on that given host. The syndrome is that any connection to chamelium:9992 gets refused.
We should add a tool that tries to connect chameliums periodically, and if it fails send an email notification to people with physical access to the HW. We can run it as a part of our infra.https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/72Tag idle runs too2019-11-14T07:36:53ZArkadiusz HilerTag idle runs too(reported by @l4kshmi)
We have [repositories with tags for kernel and IGT](https://intel-gfx-ci.01.org/#repositories-with-ci-tags) and we already tag most of our post-merge and pre-merge runs - `CI_DRM_`, `Patchwork_`, `IGTPW_`, `IGT_`....(reported by @l4kshmi)
We have [repositories with tags for kernel and IGT](https://intel-gfx-ci.01.org/#repositories-with-ci-tags) and we already tag most of our post-merge and pre-merge runs - `CI_DRM_`, `Patchwork_`, `IGTPW_`, `IGT_`.
One missing bit are [idleruns](https://intel-gfx-ci.01.org/#idle-runs). We should push tags for them too!https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/68igt-vis: Don't display dmesg-warn as a separate field2019-12-10T11:08:32ZArkadiusz Hilerigt-vis: Don't display dmesg-warn as a separate fieldHaving a separate field for dmesg that is WARN or greater just increases amount of scrolling and usually lacks the necessary context which is logged with less severe level.
Instead we can slightly change the background color (to more re...Having a separate field for dmesg that is WARN or greater just increases amount of scrolling and usually lacks the necessary context which is logged with less severe level.
Instead we can slightly change the background color (to more red-ish) for lines with `loglevel >= WARN` in the regular dmesg log.https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/53Add link to results.json.bz22019-07-02T07:56:06ZArkadiusz HilerAdd link to results.json.bz2https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_319/fi-cml-u2/igt@runner@aborted.html
Those pages link to the correct boot/dmesg/etc. logs but raw results.json.bz2 comes handy, especially for checking on unusual results.
The file is al...https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_319/fi-cml-u2/igt@runner@aborted.html
Those pages link to the correct boot/dmesg/etc. logs but raw results.json.bz2 comes handy, especially for checking on unusual results.
The file is already uploaded, so let's add link to the template that is used to render those pages.https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/43vis: Figure out good UX for caching the test filter2020-02-06T17:22:32ZArkadiusz Hilervis: Figure out good UX for caching the test filterThe new vis (!33) comes with a text field in the navbar that is used for filtering grids on test names and by default cached that.
The UX it presented though is too confusing (value stays there forever, no button to clear it, not easy ...The new vis (!33) comes with a text field in the navbar that is used for filtering grids on test names and by default cached that.
The UX it presented though is too confusing (value stays there forever, no button to clear it, not easy to spot), especially for people coming without the implementation knowledge so the caching got disabled as of b0980dc3.
TODO:
* [ ] Add a (x) to reset the value
* [ ] Make persistence optional (checkbox?)
* [ ] make filter more visible (either by putting red "filter" in the front or by blinking it?)https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/42vis: keep tooltip visible2019-10-31T09:41:40ZArkadiusz Hilervis: keep tooltip visibleOn the right edge of the viewport, most of the cell's tooltip renders off-screen
![image](/uploads/c86e2a859be94ee67f01ff41c3cb5ffa/image.png)
There are two apparent ways of solving that:
A. old-vis-style: offset tooltip down and to t...On the right edge of the viewport, most of the cell's tooltip renders off-screen
![image](/uploads/c86e2a859be94ee67f01ff41c3cb5ffa/image.png)
There are two apparent ways of solving that:
A. old-vis-style: offset tooltip down and to the left, as we have some screen estate to spare them there due to test names
B.clever: depending on a quater render the tooltip relative to the cursor:
```
|below, to the right | below, to the left |
|------------------------------------------
|above, to the right | above, to the left |
```https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/32vis: Make new tests more visible2020-02-06T09:33:27ZArkadiusz Hilervis: Make new tests more visibleCurrently, to find the new tests in the visualization you have to go to "shards all" view and then search in the page for new tests names.
With #11 we will already start using data from [cibuglog](/gfx-ci/cibuglog) for the visualization...Currently, to find the new tests in the visualization you have to go to "shards all" view and then search in the page for new tests names.
With #11 we will already start using data from [cibuglog](/gfx-ci/cibuglog) for the visualization of the results.
We can do similar thing with information about new tests (cibuglog already has logic for finding them, [example](https://lists.freedesktop.org/archives/igt-dev/2019-February/009605.html)).
With that included in the .json we could have the new tests on the combined views and/or we could highlight them somehow.https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/30Request to add the ability to install packages at test build time to CI platf...2019-02-21T12:41:13ZStuart SummersRequest to add the ability to install packages at test build time to CI platforms.IGT currently has Docker files for fedora and debian distros. It would be great if CI had the ability to extract these packages (or run within Docker itself) to install required dependencies as part of patch verification. I'd like to req...IGT currently has Docker files for fedora and debian distros. It would be great if CI had the ability to extract these packages (or run within Docker itself) to install required dependencies as part of patch verification. I'd like to request we add the infrastructure to do that. Thanks!https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/26VKMS in the farm2019-02-07T09:11:12ZArkadiusz HilerVKMS in the farmThis is related to Targeted Testing #25.
We need to figure out what's the best way to deploy VKMS, probably with its own dedicated test list.
VM? Bare metal with i915 disabled?
@adrinael has hands on experience with this, so assignin...This is related to Targeted Testing #25.
We need to figure out what's the best way to deploy VKMS, probably with its own dedicated test list.
VM? Bare metal with i915 disabled?
@adrinael has hands on experience with this, so assigning for now to him.Petri LatvalaPetri Latvalahttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/23account for tests from a missing shard by marking them as notrun2020-07-15T08:09:37ZMartin Roukalaaccount for tests from a missing shard by marking them as notrunWhen a shard machine does not start IGT execution the whole shard is lost, i.e.: the tests that were in the list were not accounted for, even as "notruns".
That causes the final test count to wildly vary in increments of ~80 which makes...When a shard machine does not start IGT execution the whole shard is lost, i.e.: the tests that were in the list were not accounted for, even as "notruns".
That causes the final test count to wildly vary in increments of ~80 which makes things harder to track.
One way of assuring that we have stable test counts (+/- the normal evolution of the tests) is to generate the list of missing tests by running `igt_runner --dryrun` for each missing "shard chunk" during the result collection phase.Tomi SarvelaTomi Sarvelahttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/21When a shard does not get executed, all its tests need to be marked as notrun2019-10-11T10:31:28ZMartin RoukalaWhen a shard does not get executed, all its tests need to be marked as notrunThis make the notrun status accurate.
Any ideas on how to achieve this, @tsa and @adrinael? We probably need to enhance the IGT result packer for this.This make the notrun status accurate.
Any ideas on how to achieve this, @tsa and @adrinael? We probably need to enhance the IGT result packer for this.https://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/20Improve the patchwork queue page2019-01-11T05:32:42ZMartin RoukalaImprove the patchwork queue pageThe patchwork queue page could benefit from multiple improvements:
- [ ] make the style consistent with other pages
- [ ] explain the priority of the different queues
- [ ] explain the lack of shards queueThe patchwork queue page could benefit from multiple improvements:
- [ ] make the style consistent with other pages
- [ ] explain the priority of the different queues
- [ ] explain the lack of shards queuehttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/19vis: collapse hosts that do not have anything interesting to display2018-12-19T15:04:38ZArkadiusz Hilervis: collapse hosts that do not have anything interesting to displayshowing information about what has been collapsed so that we don't confuse people is the hardest partshowing information about what has been collapsed so that we don't confuse people is the hardest parthttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/17Add hardware description beside the hostname in Hardware List2018-12-18T16:29:07ZTomi SarvelaAdd hardware description beside the hostname in Hardware ListAt the moment, the description for the machines are intermingled to the automatically fetched data.
For clarity, it would be better to have the machine description next to the machine name, example:
fi-whl-u (Intel Whiskey Lake RVP)At the moment, the description for the machines are intermingled to the automatically fetched data.
For clarity, it would be better to have the machine description next to the machine name, example:
fi-whl-u (Intel Whiskey Lake RVP)Arkadiusz HilerArkadiusz Hilerhttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/15Sort HW list within GENs2018-12-13T21:06:28ZArkadiusz HilerSort HW list within GENsNow we get somewhat random ordering, e.g. for GEN9: fi-skl-6700hq, fi-skl-guc, fi-kbl-8809g, fi-cfl-guc, fi-bxt-dsi, fi-kbl-guc, fi-skl-6700k2. This makes glancing on the list hard.
We already have scores for the platform codenames in, ...Now we get somewhat random ordering, e.g. for GEN9: fi-skl-6700hq, fi-skl-guc, fi-kbl-8809g, fi-cfl-guc, fi-bxt-dsi, fi-kbl-guc, fi-skl-6700k2. This makes glancing on the list hard.
We already have scores for the platform codenames in, so let's use them.Arkadiusz HilerArkadiusz Hilerhttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/13drmtip.html page usability2019-10-31T09:39:31ZArkadiusz Hilerdrmtip.html page usability**Topic:** https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html (**WARNING:** heavy, may kill Chrome)
@tpalli said that rendering may be slow because of tables and its sizing - browser has to wait for all the cells to render the full th...**Topic:** https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html (**WARNING:** heavy, may kill Chrome)
@tpalli said that rendering may be slow because of tables and its sizing - browser has to wait for all the cells to render the full thing. Couple of things to try out:
* replace table with cleverly cssed divs
* append them as callbacks, so we don't block the main thread
Other option would be not rendering anything except for stats and just have a search box. After typing 3-4 characters we would render anything including the sub-string. Something like `gem_` still would be pretty heavy though.
As of 'glancability' of the results - it's quite hard currently anyway, so I don't think it would be impacted that much.
Bonus points for optimizing [arrayToUTF8()](https://gitlab.freedesktop.org/gfx-ci/i915-infra/blob/master/site-publishing/assets/vis.js#L196), which converts byte array, that comes from unpacked.gz, to an Unicode string - it seems to take significant chunk of time.
CC: @mupuf @tsa @adrinaelhttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/11Showing Bug id for all ci test failures in CI results visualization page.2019-05-14T15:21:21ZLAKSHMINARAYANA VUDUMShowing Bug id for all ci test failures in CI results visualization page.Navigate to any CI results page (BAT/SHARDS/DRMTIP).
Move cursor to any failure (fail/dmesg-warn/warn/incomplete/crash/dmesg-fail)
If a bug exists for this failure, show the bug id.
This way anyone can find the bug id for any test fail...Navigate to any CI results page (BAT/SHARDS/DRMTIP).
Move cursor to any failure (fail/dmesg-warn/warn/incomplete/crash/dmesg-fail)
If a bug exists for this failure, show the bug id.
This way anyone can find the bug id for any test failure if a bug exists already.Petri LatvalaPetri Latvalahttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/10Visualisation: add a link back to patchwork when showing the results for a pr...2018-12-18T08:18:00ZMartin RoukalaVisualisation: add a link back to patchwork when showing the results for a pre-merge testEverything is in the titleEverything is in the titleArkadiusz HilerArkadiusz Hilerhttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/8Link to other machines from machine history page2019-02-28T09:30:11ZPetri LatvalaLink to other machines from machine history pageMake the machine name from pages like https://intel-gfx-ci.01.org/tree/drm-tip/fi-icl-u2.html a dropdown selection of other available machine histories.Make the machine name from pages like https://intel-gfx-ci.01.org/tree/drm-tip/fi-icl-u2.html a dropdown selection of other available machine histories.Arkadiusz HilerArkadiusz Hilerhttps://gitlab.freedesktop.org/gfx-ci/i915-infra/-/issues/3Collect the hardware information before each CI run2020-05-05T07:41:31ZMartin RoukalaCollect the hardware information before each CI runThe hardware information should be collected for all machines, timestamped and should also contain the runconfig it was collected on.
This will make it easier to know when they were collected and will allow us to update the website fast...The hardware information should be collected for all machines, timestamped and should also contain the runconfig it was collected on.
This will make it easier to know when they were collected and will allow us to update the website faster and more consistently.