Re: microcode loading got really slow.

[Takashi Iwai]

At Thu, 23 May 2013 15:45:32 +0800,
Ming Lei wrote:
> 
> On Thu, May 23, 2013 at 11:39 AM, Dave Jones <davej@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/