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