lkml.org 
[lkml]   [2013]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: microcode loading got really slow.
From
On Thu, May 23, 2013 at 11:06 PM, Takashi Iwai <tiwai@suse.de> wrote:
> At Thu, 23 May 2013 10:48:00 -0400,
> Dave Jones wrote:
>>
>> On Thu, May 23, 2013 at 04:36:20PM +0200, Takashi Iwai wrote:
>>
>> > > >> Also udev supports user-defined rules to load firmware, which
>> > > >> means some drivers may not put their firmware in the default
>> > > >> path of distribution's firmware.
>> > > >
>> > > > It's why I suggested to put a warning in that path as the first step.
>> > > > So we can see whether there is any actual user.
>> > >
>> > > If you plan to do it, it'd better to add default firmware path of some
>> > > distributions into firmware_class.c first, otherwise it may cause
>> > > unnecessary noise for this distribution.
>> > >
>> > > But if more default search paths are added, it might cause mistaken
>> > > firmwares found under incorrect path, for example, android's
>> > > default path is "/etc/firmware" and "/vendor/firmware"(maybe different
>> > > for different versions).
>> > >
>> > > Also, putting default search paths into kernel isn't good, which was
>> > > introduced unwillingly for well-known reason.
>> >
>> > Maybe we can create a new Kconfig to specify non-standard firmware
>> > path?
>>
>> You keep mentioning non-standard paths for firmware, but in this case,
>> I don't think Fedora is doing anything unusual. We have microcode firmware
>> in /lib/firmware/intel-ucode/ just like (afaik) everyone else.
>>
>> What *is* happening, I think is that the CPU is new enough that there's no
>> newer firmware file available for it.
>>
>> thoughts?
>
> Yes, in your case, everything is fine in the kernel itself. And no
> microcode update is needed for new CPU, thus no firmware.

Can the driver decide if the CPU need microcode? Or there will
be the microcode for the CPU in future?

>
> The problem is that the f/w loader tries to call udev and udev gets
> stuck when invoked from module init. This doesn't hit most drivers
> because usually the firmware is mandatory and it must exist. Thus the
> direct f/w loading always works for them. If it hits, it's only the
> error case.
>
> But, for the microcode loader, it's normal that the firmware doesn't
> exist, like your case. Unfortunately, this falls back to user helper
> mode, and now you're seeing the problem.

The problem is that if driver call request_firmware(), it means it need
the firmware and it know there should be one. So maybe the driver
shouldn't call request_firmware() if it can figure out that case.

> So, the option would be to fix udev, let it behaving like before.
> The second option would be to change ("fix") the kernel behavior, but
> the question is which way.

Sounds like the microcode driver depends on userspace or filesystem
to decide if there is one microcode available for me, is the way correct?


Thanks,
--
Ming Lei


\
 
 \ /
  Last update: 2013-05-23 18:21    [W:0.087 / U:2.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site