Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753339AbZKLPsc (ORCPT ); Thu, 12 Nov 2009 10:48:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753107AbZKLPsa (ORCPT ); Thu, 12 Nov 2009 10:48:30 -0500 Received: from gv-out-0910.google.com ([216.239.58.191]:30515 "EHLO gv-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753061AbZKLPs3 (ORCPT ); Thu, 12 Nov 2009 10:48:29 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rLe+gIIy3i32zWQsA7uQTVfXu163vt21rdQ6zLVYHiJiDHFoZ61CJMDvCCVbxeCIxt nPr4Io4685TyjWgnFGUoLy9rbudG0smTuv7V6mM+UqO+5+5h152vXYa99s0FHTBUt2ou BJbz4e4SWOXPjGvlHbcXEH9JJPc2QMj1QzoqM= MIME-Version: 1.0 In-Reply-To: <20091112152026.GI18592@alberich.amd.com> References: <20091106194626.GC18592@alberich.amd.com> <20091111193832.GG18592@alberich.amd.com> <20091112113343.GA1386@elte.hu> <20091112152026.GI18592@alberich.amd.com> Date: Thu, 12 Nov 2009 16:48:34 +0100 Message-ID: Subject: Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages From: Dmitry Adamushko To: Andreas Herrmann Cc: Ingo Molnar , linux-kernel@vger.kernel.org, "H. Peter Anvin" , Mike Travis , Tigran Aivazian , Thomas Gleixner , Borislav Petkov , Andreas Mohr , Jack Steiner Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2609 Lines: 57 2009/11/12 Andreas Herrmann : > On Thu, Nov 12, 2009 at 01:06:36PM +0100, Dmitry Adamushko wrote: >> 2009/11/12 Dmitry Adamushko : >> > 2009/11/12 Ingo Molnar : >> >> >> >> -tip testing found the following bug - there's a _long_ boot delay of >> >> 58.6 seconds if the CPU family is not supported: >> >> >> >> [ 1.421761] calling microcode_init+0x0/0x137 @ 1 >> >> [ 1.426532] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin >> >> [ 61.433126] microcode: failed to load file amd-ucode/microcode_amd.bin >> >> [ 61.439682] microcode: CPU0: AMD CPU family 0xf not supported >> >> [ 61.445441] microcode: CPU1: AMD CPU family 0xf not supported >> >> [ 61.451273] Microcode Update Driver: v2.00 , Peter Oruba >> >> [ 61.459116] initcall microcode_init+0x0/0x137 returned 0 after 58625622 usecs >> >> >> >> Where does this delay come from? >> > >> > My guess is that it's comming from >> > >> > static int loading_timeout = 60; /* In seconds */ >> > >> > drivers/base/firmware_class.c >> > >> > given that you seem to have MICROCODE build in kernel, so this patch >> > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commit;h=d1c84f79a6ba992dc01e312c44a21496303874d6 >> > >> > will result in sending a request for a firmware image to user-space >> > (unless that firmware image is also built-in into the kernel) and >> > user-space has not started yet. >> >> btw., it doesn't make sense for request_firmware() to even try this if >> the system_state != SYSTEM_RUNNING and current == 'init' (it'd perhaps >> make some sense if it's been done in a context of another task -- like >> in case of a parallel boot). > >> And perhaps it just makes sense for microcode to use request_firmware_nowait(). > > That would be asynchronous. What I had in mind is as follows: request_firmware_nowait() sends an async request which can be preserved (and this is an assumption -- I haven't really verified it yet) until some latter stage when user-space has been started and is capable of handling (cached) firmware-load requests. I may be (and perhaps I'm) wrong with the above assumption and the solution is either never build such a module into the kernel or only do it with built-in firmware blobs. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/