<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [GM45] igt@gem_mmap_gtt@basic-small-bo-tiledx - fail - Failed assertion: memcmp(ptr , tiled_pattern, PAGE_SIZE) == 0 (edit)" href="https://bugs.freedesktop.org/show_bug.cgi?id=106848#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [GM45] igt@gem_mmap_gtt@basic-small-bo-tiledx - fail - Failed assertion: memcmp(ptr , tiled_pattern, PAGE_SIZE) == 0 (edit)" href="https://bugs.freedesktop.org/show_bug.cgi?id=106848">bug 106848</a> from <a class="email" href="mailto:promarbler14@gmail.com" title="Adric Blake <promarbler14@gmail.com>"> Adric Blake</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>