Bug 9179 - pmd_set_huge: cannot satisfy mem with a huge-page mapping
Summary: pmd_set_huge: cannot satisfy mem with a huge-page mapping
Status: RESOLVED FIXED
Alias: None
Product: BSPs
Classification: Build System, Metadata & Runtime
Component: bsps-meta-intel (show other bugs)
Version: unspecified
Hardware: NUC Multiple
: Medium normal
Target Milestone: 2.1 M4
Assignee: Saul Wold
QA Contact: Francisco Pedraza
URL: http://yocto-ab-master.jf.intel.com/p...
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-02-26 22:41 UTC by Francisco Pedraza
Modified: 2016-03-22 14:20 UTC (History)
0 users

See Also:
OS type for building Yocto: ---
Type of Regression: Regression (Used to work)
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
do_testimage.1805 (7.77 KB, application/octet-stream)
2016-02-26 22:41 UTC, Francisco Pedraza 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Francisco Pedraza 2016-02-26 22:41:20 UTC 
Created attachment 3008 [details]
do_testimage.1805

When running testimage on NUC (D54250WYK), CORE i5, using intel-corei7-64 the next test failed: test_parselogs (oeqa.runtime.parselogs.ParseLogsTest).

Getting the following output:
 AssertionError: 2 != 0 : Log: dmesg_output.log
| -----------------------
| Central error: [    0.092602] pmd_set_huge: Cannot satisfy [mem 0xf8000000-0xf8200000] with a huge-page mapping due to MTRR override.


TEST ENVIRONMENT:
meta-qt4 : 4058b0773381f894d915ea3dfac5fe052d82a9a7
meta-intel : aaab29ad036b13a0959925329b2b8e471869ca53
meta-qt3 : 7d958b928a4a38a186746fabbc0d8169dd8bb3a6
poky : 23056103c949b498c23b47579e8dd57ce78e6ed9

Attached you can find dmesg_output.log
Comment 1 Saul Wold 2016-03-08 17:22:16 UTC 
From the commit message that is causing this message:

    pmd_set_huge() logs a warning message to a non-optimal request
    so that driver writers will be aware of such a case. Drivers
    should make a mapping request aligned to a single MTRR entry
    when the range is covered by MTRRs.

Since this is an older NUC device that is generating this message, it is 
unlikely that this will actually be fixed, so I would recommend that we 
whitelist this one in the sanity checking code.