[Bug 106848] [GM45] igt at gem_mmap_gtt@basic-small-bo-tiledx - fail - Failed assertion: memcmp(ptr , tiled_pattern, PAGE_SIZE) == 0 (edit)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106848

--- Comment #8 from Adric Blake <promarbler14 at gmail.com> ---
I tried testing your theory and it doesn't seem to hold up. I have tested
several different mem= and physical module configurations. For the mem=
options, I verified the available memory each boot with the "free" program
and/or "htop."

With 8G (4G + 4G) physical RAM, I tested mem= configs for every multiple of
512M, from 6G (inclusive) to 7.5G, as well as 8G without the mem= option. None
of those could produce the bug. I should note that the 6G config here had less
available RAM than the physical 6G RAM configuration (by precisely 154MiB).

With 6G (4G + 2G) physical RAM, I tested mem= configs for every multiple of
512M, from 3G (inclusive) to 6G. Except for 6G, none of those could produce the
bug. The order of the RAM modules on the board did not matter (thankfully).

With 5G (4G + 1G), 4G (2G + 2G), and 4G (4G + empty slot) physical RAM
configurations, I didn't bother testing mem= configs and booted each with all
available RAM. None of these could produce the bug.

With 3G (2G + 1G) physical RAM, I could produce the bug! I should note that the
kernel logged the messages:
  mtrr_cleanup: can not find optimal value
  please specify mtrr_gran_size/mtrr_chunk_size
I think this issue only comes up with recent (4.15+?) kernels though.

I did not test 2G (2G + empty slot), 2G (1G + 1G), or 1G (1G + empty slot).

Other possible configurations for my hardware are (4G + 512M [maybe]), (2G +
512M), (1G + 512M), (1G + empty slot), (512M + 512M), and (512M + empty slot).
I can't test these, though, since I don't have any 512M RAM modules.


That all said, if we use the 6G and 3G configs as a basis for a pattern, then
we could assume that configs of (x + x/2) produce the bug, and that the (1G +
512M) config would also produce the bug. That is all speculation, though.

I'm more confused as to how such a bug only decided to show up after the bad
commit that I bisected to.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180608/416fe064/attachment.html>