[coreboot] cbmem fails with `Failed to mmap /dev/mem: Resource temporarily unavailable`

Aaron Durbin adurbin at google.com
Mon Oct 5 21:25:50 CEST 2015


http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f

That patch added dmi_init() which maintains a persistent dmi mapping.
However, that code used ioremap() as it's mapping. Thus, we have an
uncached-minus PAT entry covering the DMI tables. I'm actually not
sure why they don't just maintain a copy of the tables -- maybe for
eventlog purposes? So that PAT entry will always cause issues w/ cbmem
trying to do brute force 1MiB mappings of /dev/mem.

On Wed, Sep 30, 2015 at 8:50 AM, Aaron Durbin <adurbin at google.com> wrote:
> On Wed, Sep 30, 2015 at 2:29 AM, Paul Menzel
> <paulepanter at users.sourceforge.net> wrote:
>> Dear Aaron,
>>
>>
>> thank you for the quick reply.
>>
>>
>> Am Montag, den 28.09.2015, 09:38 -0500 schrieb Aaron Durbin:
>>> On Sun, Sep 27, 2015 at 2:54 PM, Paul Menzel wrote:
>>
>>> > building a coreboot image for the ASRock E350M1 with the attached
>>> > config, having code coverage enabled, I am unable to run the
>>> > utility `cbmem`.
>>> >
>>> > ```
>>> > $ sudo util/cbmem/cbmem -V -l
>>> > Looking for coreboot table at 0 1048576 bytes.
>>> > Mapping 1MB of physical memory at 0x0 (requested 0x0).
>>> > Found!
>>> >   coreboot table entry 0x11
>>> >     Found forwarding entry.
>>> > Unmapping 1MB of virtual memory at 0xb74b6000.
>>> > Looking for coreboot table at c7f9f000 1048576 bytes.
>>> > Mapping 1MB of physical memory at 0xffffffffc7f9f000 (requested 0xc7f9f000).
>>> >   ... failed.  Mapping 1052671B of physical memory at 0xffffffffc7f9e000.
>>> > Failed to mmap /dev/mem: Resource temporarily unavailable
>>> > ```
>>> >
>>> > Linux complains with the messages below.
>>> >
>>> > ```
>>> > $ dmesg
>>> > […]
>>> > [  916.233910] x86/PAT: cbmem:2647 conflicting memory types c7f9f000-c809f000 uncached-minus<->write-back
>>> > [  916.233927] x86/PAT: reserve_memtype failed [mem 0xc7f9f000-0xc809efff], track uncached-minus, req write-back
>>> > […]
>>> > ```
>>> >
>>>
>>> You are going to need to open the /dev/mem file w/ O_SYNC flags
>>> because the kernel is marking that range of memory as uncacheable.
>>> More info can be found here:
>>> https://www.kernel.org/doc/Documentation/x86/pat.txt
>>
>> I totally missed, that besides selecting code coverage, the Linux
>> kernel was updated to version 4.2 in between. Probably they changed
>> some default.
>>
>>     $ uname -a
>>     Linux my-asrocke350m1 4.2.0-1-686-pae #1 SMP Debian 4.2.1-1 (2015-09-25) i686 GNU/Linux
>>
>>> # cat /sys/kernel/debug/x86/pat_memtype_list
>>>
>>> would be helpful
>>
>>     $ sudo more /sys/kernel/debug/x86/pat_memtype_list
>>     PAT memtype list:
>> uncached-minus @ 0xc7fa7000-0xc7fa8000
>> write-back @ 0xc7fb8000-0xc7fbb000
>> write-back @ 0xc7fba000-0xc7fbd000
>
> Interesting. The range you requested isn't listed in here. However,
> the above 3 are which are smack in the middle of region you are
> requesting. I suspect that's where things are falling over. Do you
> know what these are? Are they listed in /proc/iomem ? The best
> visibility we have currently is the e820 below which just has the
> range starting at 0xc7f9d000 through 0xe0000000. There's some weird
> fudging the kernel does around the usable memory boundaries so those
> may not be we coreboot exported. Presumably you have coreboot logs
> from a previous boot not on this kernel? That might provide some
> insight as well.
>
> I should also note I didn't go trolling through the kernel to figure
> out its logic just yet. Just noting what you're finding.
>
>
>> write-combining @ 0xe0040000-0xe0274000
>> write-combining @ 0xe0274000-0xe0474000
>> write-combining @ 0xe0474000-0xe0475000
>> write-combining @ 0xe0478000-0xe0978000
>> uncached-minus @ 0xf0004000-0xf0005000
>> uncached-minus @ 0xf0100000-0xf0140000
>> uncached-minus @ 0xf0140000-0xf0144000
>> uncached-minus @ 0xf0144000-0xf0148000
>> uncached-minus @ 0xf0148000-0xf0149000
>> uncached-minus @ 0xf0149000-0xf014a000
>> uncached-minus @ 0xf014a000-0xf014b000
>> uncached-minus @ 0xf014b000-0xf014c000
>> uncached-minus @ 0xf014b000-0xf014c000
>> uncached-minus @ 0xf014b000-0xf014c000
>> uncached-minus @ 0xf014b000-0xf014c000
>> uncached-minus @ 0xf8088000-0xf8089000
>> uncached-minus @ 0xfed00000-0xfed01000
>> uncached-minus @ 0xfed80000-0xfed81000
>>
>>> along with this:
>>>
>>> $ for i in /sys/firmware/memmap/*; do echo $(cat $i/type $i/start $i/end); done
>>
>>     $ for i in /sys/firmware/memmap/*; do echo $(sudo cat $i/type $i/start $i/end); done
>>     System RAM 0x0 0x9fbff
>>     reserved 0x9fc00 0x9ffff
>>     reserved 0xf0000 0xfffff
>>     System RAM 0x100000 0xc7f9cfff
>>     reserved 0xc7f9d000 0xdfffffff
>>     reserved 0xf8000000 0xfbffffff
>>     System RAM 0x100000000 0x21effffff
>>
>>
>> Thanks,
>>
>> Paul
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot



More information about the coreboot mailing list