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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.