From: Prarit Bhargava <prarit@redhat.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-kernel@vger.kernel.org, tigran@aivazian.fsnet.co.uk,
x86@kernel.org, hmh@hmh.eng.br, andi@firstfloor.org
Subject: Re: [PATCH] x86, microcode, Fix long microcode load time when firmware file is missing [v2]
Date: Thu, 31 Oct 2013 11:23:51 -0400 [thread overview]
Message-ID: <52727607.6050107@redhat.com> (raw)
In-Reply-To: <s5heh75wi4h.wl%tiwai@suse.de>
On 10/28/2013 11:05 AM, Takashi Iwai wrote:
> At Mon, 28 Oct 2013 08:06:08 -0400,
> Prarit Bhargava wrote:
>>
>> If no firmware is found on the system that matches the processor, the
>> microcode module can take hours to load. For example on recent kernels
>> when loading the microcode module on an Intel system:
>>
>> [ 239.532116] microcode: CPU0 sig=0x306e4, pf=0x1, revision=0x413
>> [ 299.693447] microcode: CPU1 sig=0x306e4, pf=0x1, revision=0x413
>> [ 359.821972] microcode: CPU2 sig=0x306e4, pf=0x1, revision=0x413
>> [ 419.960263] microcode: CPU3 sig=0x306e4, pf=0x1, revision=0x413
>> [ 480.090024] microcode: CPU4 sig=0x306e4, pf=0x1, revision=0x413
>> ...
>> [ 2825.151364] microcode: CPU43 sig=0x306e4, pf=0x1, revision=0x413
>> [ 2885.280863] microcode: CPU44 sig=0x306e4, pf=0x1, revision=0x413
>> [ 2945.410719] microcode: CPU45 sig=0x306e4, pf=0x1, revision=0x413
>> [ 3005.540541] microcode: CPU46 sig=0x306e4, pf=0x1, revision=0x413
>> [ 3065.670405] microcode: CPU47 sig=0x306e4, pf=0x1, revision=0x413
>> ...
>> etc.
>>
>> Similarly there is a 60 second "hang" when loading the AMD module, which
>> isn't as bad as the Intel situation. This is because the AMD microcode
>> loader only attempts to look for the firmware on the boot_cpu and, if
>> found, loads the microcode on each cpu. This patch does the same for the
>> Intel microcode, and it obviously peeds up the module load if there is no
>> microcode update available.
>>
>> After making this change, the old microcode loading code and the new
>> loading code can be cleaned up and unified in the core code.
>>
>> This patch was tested on several systems (both AMD and Intel) with the
>> microcode in place and without, as well as on several different OSes.
>
> Does simply disabling CONFIG_FW_LOADER_USER_HELPER work without your
> patch?
>
> If yes, it's an infamous udev issue. An easier solution would be to
> create a function that does only the direct f/w loading without
> usermode helper, and call it in the microcode driver.
>
> An untested quick fix patch is attached below.
>
>
Takashi, this patch works AFAICT.
I wish I had thought of doing it this way to begin with ...
If you choose to submit, can you add a Tested-by: Prarit Bhargava
<prarit@redhat.com>
Thanks,
P.
prev parent reply other threads:[~2013-10-31 15:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-28 12:06 [PATCH] x86, microcode, Fix long microcode load time when firmware file is missing [v2] Prarit Bhargava
2013-10-28 14:37 ` Borislav Petkov
2013-10-28 15:06 ` Henrique de Moraes Holschuh
2013-10-28 15:11 ` Prarit Bhargava
2013-10-28 15:23 ` Borislav Petkov
2013-10-28 15:05 ` Takashi Iwai
2013-10-28 15:12 ` Prarit Bhargava
2013-10-31 15:23 ` Prarit Bhargava [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52727607.6050107@redhat.com \
--to=prarit@redhat.com \
--cc=andi@firstfloor.org \
--cc=hmh@hmh.eng.br \
--cc=linux-kernel@vger.kernel.org \
--cc=tigran@aivazian.fsnet.co.uk \
--cc=tiwai@suse.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).