Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754939AbcC1NLQ (ORCPT ); Mon, 28 Mar 2016 09:11:16 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:36098 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752099AbcC1NLM (ORCPT ); Mon, 28 Mar 2016 09:11:12 -0400 Subject: Re: [REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables To: Paul Menzel , Jean Delvare References: <1459154648.2351.19.camel@users.sourceforge.net> <56F92737.4050607@globallogic.com> Cc: Linux kernel mailing list , coreboot@coreboot.org From: Ivan Khoronzhuk Message-ID: <56F92D6E.3010102@linaro.org> Date: Mon, 28 Mar 2016 16:11:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F92737.4050607@globallogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2535 Lines: 71 On 28.03.16 15:44, ivan.khoronzhuk wrote: > Hi Paul, > > The dmi_remap() is arch dependent function and for mainline used as ioremap_cache for x86, arm.. > And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking about k4.5. k4.5 -> v4.6-rc1. > It's rather bug of dmi_remap than the patch which just use it. > > The only reason why the bug wasn't found earlier it was unmapped back at init, but it > doesn't mean it cannot be used after init, which can lead to strange behavior in future. > If it should be ioremap_cache(), it's better to change dmi_remap() for your arch. > > Oh, yes, k4.2 is using the ioremap instead of ioremap_cache(). > But seems it's currently solved with: > commit ce1143aa60273220a9f89012f2aaaed04f97e9a2 > "x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()" > So, probably, it should be back ported. > > On 28.03.16 11:44, Paul Menzel wrote: >> 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 >> -- Regards, Ivan Khoronzhuk