Date:	Wed, 23 Oct 2013 08:02:47 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	Ming Lei <ming.lei@...onical.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	x86@...nel.org,
	Andreas Herrmann <herrmann.der.user@...glemail.com>,
	tigran@...azian.fsnet.co.uk
Subject: Re: [PATCH 1/2] firmware, fix request_firmware_nowait() freeze with
 no uevent



On 10/23/2013 06:36 AM, Prarit Bhargava wrote:
> 
> 
> On 10/23/2013 12:16 AM, Ming Lei wrote:
>> On Wed, Oct 23, 2013 at 7:15 AM, Prarit Bhargava <prarit@...hat.com> wrote:
>>> On 10/21/2013 10:35 PM, Ming Lei wrote:
>>>>
>>>> That is why NOHOTPLUG isn't encouraged to be taken, actually
>>>> I don't suggest you to do that too, :-)
>>> Okay ... I can certainly switch to HOTPLUG.
>>
>> OK, that should be the right approach.
>>
>>>
>>>>
>>>> You need to make sure your approach won't break micro-code
>>>> update application in current/previous distributions.
>>>
>>> I've tested the following distributions today on a Dell PE 1850:  Ubuntu, SuSe,
>>> Linux Mint, and of course Fedora.  I do not see any issues with either the
>>> microcode update or the dell_rbu driver.  Unfortunately I do not have access to
>>
>> Actually I am wondering if your tests are enough because kernel
>> can't break user-space, which means lots of previous old version
>> distributions should surely be covered, :-)
> 
> I've tested an old version of Suse and a few older RHEL versions for kicks.  No
> problems.  I'm testing an older version of Ubuntu ATM and will update with
> details (it doesn't look like it does anything different FWIW so I'm not worried).
> 
>>
>> If you keep HOTPLUG, only change to request_firmware_nowait(),
>> that should be OK since the loading protocol between userspace and
>> kernel won't change wrt. microcode updating.
>>
>>> a system that uses the lattice-ecp3-config, however, from code inspection it
>>> looks like the driver looks at a specific place for the FW update and then
>>> applies it via the call function in request_firmware_nowait() so it looks like
>>> it is solid too.
>>>
>>> I think maybe this patchset should be split into two separate submits, one for
>>> the microcode and the second to figure out if the code really should wait
>>> indefinitely.  AFAICT neither use case in the kernel expects an indefinite wait.
>>
>> If you switch to HOTPLUG, you needn't worry about waiting indefinitely,
>> need you?
> 
> Nope ... I'll modify the code and retest.  

After all this I completely forgot the problem I'm trying to solve here.  The
issue is that with HOTPLUG & request_microcode_nowait(), if the microcode image
is not found (that is the file is not found on disk), then EACH cpu waits 1
minute and it takes 2 hours for a 120 cpu box to load the microcode module.

Which is terrible... so HOTPLUG doesn't work here.

Let me back up Ming and see if you have a better solution for me.  I have a
system that does not have the x86 microcode loaded on disk.  I use the microcode
module which calls request_firmware_nowait() to load the microcode image and I
want it done as fast as possible.  The microcode loader does not have a uevent
so I'm not waiting on userspace for completion.

How do I avoid the 60 second delay/cpu introduced in the microcode path?  I
don't see one.  If I use HOTPLUG I'm waiting 60 seconds.  If I use NOHOTPLUG
AFAICT the loading function never will return.  AFAICT the same issue arises
with the dell_rbu code -- it appears to never load the dell_rbu firmware.

P.
--
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/

Powered by blists - more mailing lists