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 <pra...@redhat.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
