linux-kernel - Re: microcode loading got really slow.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 May 2013 10:06:56 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	Dave Jones <davej@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>, x86@...nel.org,
	fenghua.yu@...el.com
Subject: Re: microcode loading got really slow.

At Thu, 23 May 2013 15:45:32 +0800,
Ming Lei wrote:
> 
> On Thu, May 23, 2013 at 11:39 AM, Dave Jones <davej@...hat.com> wrote:
> >  > On 05/21/2013 04:03 PM, Dave Jones wrote:
> >  >
> >  > [   72.318133] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x6
> >  > [  132.446449] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x6
> >  > [  192.573101] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x6
> >  > [  252.702055] microcode: Microcode Update Driver: v2.00 <tigran@...azian.fsnet.co.uk>, Peter Oruba
> >  >
> >  > For some reason the events for udev seem to be getting delayed 60s
> >  > for each core.
> >
> > Screwed up my .config, and had CONFIG_FW_LOADER_USER_HELPER inadvertantly set
> > Odd though that it causes that 60 second delay, given that it's supposedly a
> > 'fallback' when the direct loading fails.
> 
> udevd has the ugly problem previously at some situations(for example,
> request_firmware called in probe(), and that is why direct loading is
> introduced),
> but not sure why the direct loading is failed first.

The microcode update is optional, so it's no error even if the
microcode firmwares are not found.

But yes, this seems happening during the module probing.  The lines
"microcde: CPU..." show before "microcode: Microcode Update
Driver...", which means the f/w loading has been done before finishing
the module load.

I thought (or hoped) this mess (60s stalls) was fixed in the recent
udev, but apparently not...?


> Could you enable 'CONFIG_DEBUG_DRIVER' and post 'dmesg' out?
> And better to check where the affected firmware(microcode) is in your
> distribution.
> 
> >
> > It seems I don't actually need to set that option, so I'm not bothered
> > if there's an actual bug here or not, but the behaviour seems odd.
> 
> If the option isn't set, the firmware will be lost for the requested CPU, :-)

I don't think it's relevant.  If firmware files exist, the microcode
update should have been successful even without usermode helper
kconfig.  If not exist, no update -- so should it be.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/