Dear Ivan, dear Jeann,
There is an unwanted regression due to commit d7f96f97 (firmware: dmi_scan: add SBMIOS entry and DMI tables). Since Linux kernel 4.2 the utility `cbmem`, used to access information stored in memory, from the coreboot project [1] does not work anymore on a lot of systems as reported in coreboot’s issue tracker as ticket #33 [2]. ``` Failed to mmap /dev/mem: Resource temporarily unavailable ``` Aaron Durbin analyzed on the coreboot mailing list [3]: > > 3) Why is that range set as uncached-minus? Would write-back work? > > Please see this thread: > http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html > > The actual issue stems from > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f > which maintains a persistent mapping of smbios tables. It uses > dmi_remap() which is '#define dmi_remap ioremap' which is where the > uncached-minus PAT entry comes from. It should be using the same > mechanism as the ACPI table mappings which uses ioremap_cache(). It’d be great, if the commit could be reverted, or the code be changed in a way that `cbmem` still works. If I should report this issue somewhere else, please tell me too, and I’ll do my best to follow up there. Thanks, Paul [1] https://www.coreboot.org [2] https://ticket.coreboot.org/issues/33 [3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html
signature.asc
Description: This is a digitally signed message part