| Summary: | [CI][DRMTIP] igt@runner@aborted - fail - TAINT_BAD_PAGE: Bad page reference or an unexpected page flags. | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Martin Peres <martin.peres> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | intel-gfx-bugs |
| Version: | XOrg git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | ReadyForDev | ||
| i915 platform: | ICL | i915 features: | |
|
Description
Martin Peres
2019-05-02 10:01:00 UTC
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * ICL: igt@runner@aborted - fail - TAINT_BAD_PAGE: Bad page reference or an unexpected page flags. - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_272/fi-icl-y/igt@runner@aborted.html We should update BIOS on this system. From initial triaging with my limitation, it looks nothing has broken with i915 driver with respect to this BUG, it is bad_page assertion, while allocating a new page for a user space process (kms_plane_scali). [~lvudum] u may files this open bug to Linux MM Maintener. (In reply to Anshuman Gupta from comment #3) > From initial triaging with my limitation, it looks nothing has broken with > i915 driver with respect to this BUG, it is bad_page assertion, while > allocating a new page for a user space process (kms_plane_scali). > [~lvudum] u may files this open bug to Linux MM Maintener. Thanks for your input. This failure is reported here https://bugzilla.kernel.org/show_bug.cgi?id=203557 Please don't do this, by usual bug filing standards our reports here are completely unactionable and this might as well sound like a bad machine or our driver bug. If you want to file a bug with a foreign subsystem please make damn sure you have solid proof it's a bug with them, and not just a hunch. Quick comment from Dave Airlie on irc: * airlied also guesses it's memory corrupt or some pages ending up in wrong state <airlied> I doubt mm is at fault <danvet> yeah <airlied> we marked something unvevictable and freed it? See the dmesg backtrace <4>[ 114.390971] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set <1>[ 114.390972] bad because of flags: 0x100000(unevictable) drm/i915 does mark pages as unevictable, so this very much could be our own bug. Or bad hw. Internally it's not a big deal if our triaging doesn't really analyze the bug, but that stops being fun as soon as we involve non-intel people. Lakshmi, can you pls close the kernel bugzilla entry with a quick "oops sry, need to look at this more first internally". Thanks, Daniel (In reply to Daniel Vetter from comment #5) > Please don't do this, by usual bug filing standards our reports here are > completely unactionable and this might as well sound like a bad machine or > our driver bug. > > If you want to file a bug with a foreign subsystem please make damn sure you > have solid proof it's a bug with them, and not just a hunch. > > Quick comment from Dave Airlie on irc: > > * airlied also guesses it's memory corrupt or some pages ending up in wrong > state > <airlied> I doubt mm is at fault > <danvet> yeah > <airlied> we marked something unvevictable and freed it? > > See the dmesg backtrace > > <4>[ 114.390971] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set > <1>[ 114.390972] bad because of flags: 0x100000(unevictable) > > drm/i915 does mark pages as unevictable, so this very much could be our own > bug. Or bad hw. > > Internally it's not a big deal if our triaging doesn't really analyze the > bug, but that stops being fun as soon as we involve non-intel people. > > Lakshmi, can you pls close the kernel bugzilla entry with a quick "oops sry, > need to look at this more first internally". > > Thanks, Daniel Thanks for pointing this. Yes, I will double check or be more cautious when creating an external bug. For now I have closed the kernel bug. This failure has happened twice where in both the cases the previous test mentioned in the output was passed. https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_276/fi-icl-y/igt@runner@aborted.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_272/fi-icl-y/igt@runner@aborted.html So, it might not be related to Bug https://bugs.freedesktop.org/show_bug.cgi?id=110040, or https://bugs.freedesktop.org/show_bug.cgi?id=110041 Needs further investigation. This has been seen only 2 times on system that had old BIOS and now BIOS has been updated and after that not seen. If we see issues on this BIOS ICLSFWR1.R00.3162.A00 then we could think further. Not seen now in 1 week. Lowering. i915_gem_object_get_pages_gtt()->mapping_set_unevictable() set the mapping unevictable. i915_gem_object_put_pages_gtt()->mapping_clear_unevictable() clear the mappings unevictable. Gem expert need to comment are we missing any put sequence here causing this assertion. i915_gem_object_get_pages_gtt()->mapping_set_unevictable() set the mapping unevictable. i915_gem_object_put_pages_gtt()->mapping_clear_unevictable() clear the mappings unevictable. Gem expert need to comment are we missing any put sequence here causing this assertion. For now this issue occurs only on icl-y and icl-dsi. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/287. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.