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

[Paul Menzel]

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
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

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

[Aaron Durbin]

On Wed, Sep 30, 2015 at 2:29 AM, Paul Menzel
 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: [e-mail]
> http://www.coreboot.org/mailman/listinfo/coreboot