Messages in this thread | | | Date | Wed, 23 Oct 2013 10:08:29 -0400 | From | Prarit Bhargava <> | Subject | Re: [PATCH 1/2] firmware, fix request_firmware_nowait() freeze with no uevent |
| |
On 10/23/2013 09:21 AM, Ming Lei wrote: > On Wed, Oct 23, 2013 at 8:02 PM, Prarit Bhargava <prarit@redhat.com> wrote: > >> >> 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. > > As I said, the 60 second delay is from udev, so that is the root cause.
Okay, so then my other option is to use NOHOTPLUG. I've correctly modified it to return and not wait for a NULL uevent. The synchronization between the cont function return and the actual application of the firmware is done in the driver (in my 2/2 patch) where I've used a completion struct. ... Am I still missing something at this point?
I also have to make that change to the dell_rbu code because it too, is broken the same way. That is, I can load the dell_rbu module and it just hangs without applying the firmware.
I'll submit a new version of these patches and we can continue from there.
P. > > There are some workarounds for your reference: >
These are workarounds for an issue that arises in the kernel.
P.
| |