* [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages @ 2009-11-02 20:08 dimm 2009-11-04 12:27 ` Ingo Molnar 2009-11-05 15:37 ` Andreas Herrmann 0 siblings, 2 replies; 18+ messages in thread From: dimm @ 2009-11-02 20:08 UTC (permalink / raw) To: linux-kernel Cc: Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner [ resending ] Hi, this is in response to Mike's patch "Limit the number of microcode messages". What's about the following (yet preliminary and not thoroughly tested) approach? patch-1: simplify 'struct ucode_cpu_info' and related functional logic. patch-2: reduce a number of similar 'microcode version' messages by printing a single message for all cpus with equal microcode version, like: (1) [ 96.589437] microcode: original microcode versions... [ 96.589451] microcode: CPU0-1: sig=0x6f2, pf=0x20, revision=0x57 (2) [ 96.603176] microcode: microcode versions after update... [ 96.603193] microcode: CPU0-1: sig=0x6f2, pf=0x20, revision=0x57 The new approach is used in microcode_init() [ i.e. when loading a module ] and microcode_write(), that's when we update all the cpus at once. reload_for_cpu() and update-all-cpus-upon-resuming() use the old approach - a new microcode version is being reported upon applying it. The latter might employ the similar 'report-for-all' approach as above but that would somewhat complicate the logic. Anyways, there are plenty of per-cpu messages upon system resuming so having some more update-microcode related ones won't harm that muc, I guess :-) (Not-yet-)signed-off-by: Dmitry Adaushko <dmitry.adamushko@gmail.com> --- diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h index ef51b50..68fd54c 100644 --- a/arch/x86/include/asm/microcode.h +++ b/arch/x86/include/asm/microcode.h @@ -31,8 +31,6 @@ struct microcode_ops { }; struct ucode_cpu_info { - struct cpu_signature cpu_sig; - int valid; void *mc; }; extern struct ucode_cpu_info ucode_cpu_info[]; diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c index 366baa1..c205d37 100644 --- a/arch/x86/kernel/microcode_amd.c +++ b/arch/x86/kernel/microcode_amd.c @@ -156,8 +156,6 @@ static int apply_microcode_amd(int cpu) printk(KERN_INFO "microcode: CPU%d: updated (new patch_level=0x%x)\n", cpu, rev); - uci->cpu_sig.rev = rev; - return 0; } @@ -249,14 +247,18 @@ static enum ucode_state generic_load_microcode(int cpu, const u8 *data, size_t size) { struct ucode_cpu_info *uci = ucode_cpu_info + cpu; + struct cpu_signature cpu_sig; const u8 *ucode_ptr = data; - void *new_mc = NULL; - void *mc; - int new_rev = uci->cpu_sig.rev; - unsigned int leftover; + void *new_mc = NULL, *mc; + unsigned int leftover, new_rev; unsigned long offset; enum ucode_state state = UCODE_OK; + if (collect_cpu_info_amd(cpu, &cpu_sig)) + return UCODE_ERROR; + + new_rev = cpu_sig.rev; + offset = install_equiv_cpu_table(ucode_ptr); if (!offset) { printk(KERN_ERR "microcode: failed to create " @@ -293,7 +295,7 @@ generic_load_microcode(int cpu, const u8 *data, size_t size) uci->mc = new_mc; pr_debug("microcode: CPU%d found a matching microcode " "update with version 0x%x (current=0x%x)\n", - cpu, new_rev, uci->cpu_sig.rev); + cpu, new_rev, cpu_sig.rev); } else { vfree(new_mc); state = UCODE_ERROR; diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c index 378e9a8..b7ead3a 100644 --- a/arch/x86/kernel/microcode_core.c +++ b/arch/x86/kernel/microcode_core.c @@ -138,20 +138,6 @@ static int collect_cpu_info_on_target(int cpu, struct cpu_signature *cpu_sig) return ret; } -static int collect_cpu_info(int cpu) -{ - struct ucode_cpu_info *uci = ucode_cpu_info + cpu; - int ret; - - memset(uci, 0, sizeof(*uci)); - - ret = collect_cpu_info_on_target(cpu, &uci->cpu_sig); - if (!ret) - uci->valid = 1; - - return ret; -} - struct apply_microcode_ctx { int err; }; @@ -182,12 +168,8 @@ static int do_microcode_update(const void __user *buf, size_t size) int cpu; for_each_online_cpu(cpu) { - struct ucode_cpu_info *uci = ucode_cpu_info + cpu; enum ucode_state ustate; - if (!uci->valid) - continue; - ustate = microcode_ops->request_microcode_user(cpu, buf, size); if (ustate == UCODE_ERROR) { error = -1; @@ -269,23 +251,16 @@ static struct platform_device *microcode_pdev; static int reload_for_cpu(int cpu) { - struct ucode_cpu_info *uci = ucode_cpu_info + cpu; - int err = 0; + enum ucode_state ustate; mutex_lock(µcode_mutex); - if (uci->valid) { - enum ucode_state ustate; - ustate = microcode_ops->request_microcode_fw(cpu, µcode_pdev->dev); - if (ustate == UCODE_OK) - apply_microcode_on_target(cpu); - else - if (ustate == UCODE_ERROR) - err = -EINVAL; - } + ustate = microcode_ops->request_microcode_fw(cpu, µcode_pdev->dev); + if (ustate == UCODE_OK) + apply_microcode_on_target(cpu); mutex_unlock(µcode_mutex); - return err; + return (ustate == UCODE_ERROR)? -EINVAL : 0; } static ssize_t reload_store(struct sys_device *dev, @@ -317,17 +292,23 @@ static ssize_t reload_store(struct sys_device *dev, static ssize_t version_show(struct sys_device *dev, struct sysdev_attribute *attr, char *buf) { - struct ucode_cpu_info *uci = ucode_cpu_info + dev->id; + struct cpu_signature cpu_sig; - return sprintf(buf, "0x%x\n", uci->cpu_sig.rev); + if (collect_cpu_info_on_target(dev->id, &cpu_sig)) + return 0; + + return sprintf(buf, "0x%x\n", cpu_sig.rev); } static ssize_t pf_show(struct sys_device *dev, struct sysdev_attribute *attr, char *buf) { - struct ucode_cpu_info *uci = ucode_cpu_info + dev->id; + struct cpu_signature cpu_sig; + + if (collect_cpu_info_on_target(dev->id, &cpu_sig)) + return 0; - return sprintf(buf, "0x%x\n", uci->cpu_sig.pf); + return sprintf(buf, "0x%x\n", cpu_sig.pf); } static SYSDEV_ATTR(reload, 0200, NULL, reload_store); @@ -348,10 +329,7 @@ static struct attribute_group mc_attr_group = { static void microcode_fini_cpu(int cpu) { - struct ucode_cpu_info *uci = ucode_cpu_info + cpu; - microcode_ops->microcode_fini_cpu(cpu); - uci->valid = 0; } static enum ucode_state microcode_resume_cpu(int cpu) @@ -369,10 +347,10 @@ static enum ucode_state microcode_resume_cpu(int cpu) static enum ucode_state microcode_init_cpu(int cpu) { + struct ucode_cpu_info *uci = ucode_cpu_info + cpu; enum ucode_state ustate; - if (collect_cpu_info(cpu)) - return UCODE_ERROR; + memset(uci, 0, sizeof(*uci)); /* --dimm. Trigger a delayed update? */ if (system_state != SYSTEM_RUNNING) @@ -388,19 +366,6 @@ static enum ucode_state microcode_init_cpu(int cpu) return ustate; } -static enum ucode_state microcode_update_cpu(int cpu) -{ - struct ucode_cpu_info *uci = ucode_cpu_info + cpu; - enum ucode_state ustate; - - if (uci->valid) - ustate = microcode_resume_cpu(cpu); - else - ustate = microcode_init_cpu(cpu); - - return ustate; -} - static int mc_sysdev_add(struct sys_device *sys_dev) { int err, cpu = sys_dev->id; @@ -450,7 +415,7 @@ static int mc_sysdev_resume(struct sys_device *dev) */ WARN_ON(cpu != 0); - if (uci->valid && uci->mc) + if (uci->mc) microcode_ops->apply_microcode(cpu); return 0; @@ -472,7 +437,10 @@ mc_cpu_callback(struct notifier_block *nb, unsigned long action, void *hcpu) switch (action) { case CPU_ONLINE: case CPU_ONLINE_FROZEN: - microcode_update_cpu(cpu); + if (action == CPU_ONLINE_FROZEN) + microcode_resume_cpu(cpu); + else + microcode_init_cpu(cpu); case CPU_DOWN_FAILED: case CPU_DOWN_FAILED_FROZEN: pr_debug("microcode: CPU%d added\n", cpu); diff --git a/arch/x86/kernel/microcode_intel.c b/arch/x86/kernel/microcode_intel.c index 0d334dd..6589765 100644 --- a/arch/x86/kernel/microcode_intel.c +++ b/arch/x86/kernel/microcode_intel.c @@ -339,8 +339,6 @@ static int apply_microcode(int cpu) mc_intel->hdr.date >> 24, (mc_intel->hdr.date >> 16) & 0xff); - uci->cpu_sig.rev = val[1]; - return 0; } @@ -348,11 +346,16 @@ static enum ucode_state generic_load_microcode(int cpu, void *data, size_t size, int (*get_ucode_data)(void *, const void *, size_t)) { struct ucode_cpu_info *uci = ucode_cpu_info + cpu; + struct cpu_signature cpu_sig; u8 *ucode_ptr = data, *new_mc = NULL, *mc; - int new_rev = uci->cpu_sig.rev; - unsigned int leftover = size; + unsigned int leftover = size, new_rev; enum ucode_state state = UCODE_OK; + if (collect_cpu_info(cpu, &cpu_sig)) + return UCODE_ERROR; + + new_rev = cpu_sig.rev; + while (leftover) { struct microcode_header_intel mc_header; unsigned int mc_size; @@ -377,7 +380,7 @@ static enum ucode_state generic_load_microcode(int cpu, void *data, size_t size, break; } - if (get_matching_microcode(&uci->cpu_sig, mc, new_rev)) { + if (get_matching_microcode(&cpu_sig, mc, new_rev)) { if (new_mc) vfree(new_mc); new_rev = mc_header.rev; @@ -407,7 +410,7 @@ static enum ucode_state generic_load_microcode(int cpu, void *data, size_t size, pr_debug("microcode: CPU%d found a matching microcode update with" " version 0x%x (current=0x%x)\n", - cpu, new_rev, uci->cpu_sig.rev); + cpu, new_rev, cpu_sig.rev); out: return state; } ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-02 20:08 [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages dimm @ 2009-11-04 12:27 ` Ingo Molnar 2009-11-05 15:37 ` Andreas Herrmann 1 sibling, 0 replies; 18+ messages in thread From: Ingo Molnar @ 2009-11-04 12:27 UTC (permalink / raw) To: dimm Cc: linux-kernel, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner * dimm <dmitry.adamushko@gmail.com> wrote: > [ resending ] > > > Hi, > > > this is in response to Mike's patch "Limit the number of microcode > messages". > > What's about the following (yet preliminary and not thoroughly tested) > approach? > > patch-1: > > simplify 'struct ucode_cpu_info' and related functional logic. > > > patch-2: > > reduce a number of similar 'microcode version' messages by printing a > single message for all cpus with equal microcode version, like: > > (1) > [ 96.589437] microcode: original microcode versions... > [ 96.589451] microcode: CPU0-1: sig=0x6f2, pf=0x20, revision=0x57 > > (2) > [ 96.603176] microcode: microcode versions after update... > [ 96.603193] microcode: CPU0-1: sig=0x6f2, pf=0x20, revision=0x57 > > > The new approach is used in microcode_init() [ i.e. when loading a > module ] and microcode_write(), that's when we update all the cpus at > once. > > reload_for_cpu() and update-all-cpus-upon-resuming() use the old > approach - a new microcode version is being reported upon applying it. > > The latter might employ the similar 'report-for-all' approach as above > but that would somewhat complicate the logic. Anyways, there are plenty > of per-cpu messages upon system resuming so having some more > update-microcode related ones won't harm that muc, I guess :-) Seems sensible to me. Ingo ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-02 20:08 [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages dimm 2009-11-04 12:27 ` Ingo Molnar @ 2009-11-05 15:37 ` Andreas Herrmann 2009-11-05 18:40 ` Dmitry Adamushko 1 sibling, 1 reply; 18+ messages in thread From: Andreas Herrmann @ 2009-11-05 15:37 UTC (permalink / raw) To: dimm Cc: linux-kernel, Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner The patches don't properly work here. (1) For instance I got following log entries when doing suspend/resume, doing CPU offline/online test and reloading the module: microcode: original microcode versions... microcode: CPU0-3: patch_level=0x1000065 platform microcode: firmware: requesting amd-ucode/microcode_amd.bin ... microcode: CPU0-1,3: patch_level=0x1000083 microcode: CPU2-3: patch_level=0x1000065 Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba The patch levels are: # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done PATCH_LEVEL = 0x0000000001000083 PATCH_LEVEL = 0x0000000001000083 PATCH_LEVEL = 0x0000000001000065 PATCH_LEVEL = 0x0000000001000065 (2) During suspend/resume the ucode is not updated: hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done PATCH_LEVEL = 0x0000000001000083 PATCH_LEVEL = 0x0000000001000083 PATCH_LEVEL = 0x0000000001000083 PATCH_LEVEL = 0x0000000001000083 hadburg linux # pm-suspend hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done PATCH_LEVEL = 0x0000000001000065 PATCH_LEVEL = 0x0000000001000065 PATCH_LEVEL = 0x0000000001000065 PATCH_LEVEL = 0x0000000001000065 That used to work w/o your patches. Didn't have time to look why this is now failing. You've changed mc_cpu_callback() -- most likely that is causing this regression. Regards, Andreas ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-05 15:37 ` Andreas Herrmann @ 2009-11-05 18:40 ` Dmitry Adamushko 2009-11-06 12:34 ` Andreas Herrmann 0 siblings, 1 reply; 18+ messages in thread From: Dmitry Adamushko @ 2009-11-05 18:40 UTC (permalink / raw) To: Andreas Herrmann Cc: linux-kernel, Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner 2009/11/5 Andreas Herrmann <herrmann.der.user@googlemail.com>: > The patches don't properly work here. > > (1) For instance I got following log entries when doing > suspend/resume, doing CPU offline/online test and reloading the > module: To avoid possible misunderstandings, I'd like to clarify the output below. > > microcode: original microcode versions... > microcode: CPU0-3: patch_level=0x1000065 So this is the 1st time you have loaded a module. > platform microcode: firmware: requesting amd-ucode/microcode_amd.bin > ... > microcode: CPU0-1,3: patch_level=0x1000083 before or after loading a module? CPU2 is down, isn't it? > > microcode: CPU2-3: patch_level=0x1000065 same question as above. Here, either CPUs 0 and 1 are down or have a different version. Both above messages don't make sense taken together (CPU3 belongs to both sets) unless summarize_cpu_info() is utterly broken. > > Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba > > The patch levels are: > > # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done > PATCH_LEVEL = 0x0000000001000083 > PATCH_LEVEL = 0x0000000001000083 > PATCH_LEVEL = 0x0000000001000065 > PATCH_LEVEL = 0x0000000001000065 this is after your test has been stopped and all the CPUs are up, right? > > (2) During suspend/resume the ucode is not updated: > > hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done > PATCH_LEVEL = 0x0000000001000083 > PATCH_LEVEL = 0x0000000001000083 > PATCH_LEVEL = 0x0000000001000083 > PATCH_LEVEL = 0x0000000001000083 > hadburg linux # pm-suspend > hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done > PATCH_LEVEL = 0x0000000001000065 > PATCH_LEVEL = 0x0000000001000065 > PATCH_LEVEL = 0x0000000001000065 > PATCH_LEVEL = 0x0000000001000065 > > > That used to work w/o your patches. Didn't have time to look why this > is now failing. You've changed mc_cpu_callback() -- most likely that > is causing this regression. Hmm, cpu-event-callbacks seem to be working on my (Intel) setup. I have enabled pr_debug messages and also did a little trick to allow ucode of the same version to be loaded (my cpu is of the recent ucode by itself) and I can see cpu-callback events for both resuming and cpu-up cases. (firstly, upgraded with microcode_ctl as I only have a .dat file) suspend-resume ... [ 584.506371] microcode: CPU1 removed [ 584.516018] microcode: CPU0 updated to revision 0x57, date = 2007-03-15 [ 584.597326] microcode: CPU1 updated upon resume [ 584.597562] microcode: CPU1 updated to revision 0x57, date = 2007-03-15 [ 584.597565] microcode: CPU1 added ... and now cpu1 : down -> up [ 1616.932249] microcode: CPU1 removed [ 1633.942502] platform microcode: firmware: requesting intel-ucode/06-0f-02 [ 1633.954638] microcode: data file intel-ucode/06-0f-02 load failed [ 1633.954642] microcode: CPU1 added as I understand, you don't see " platform microcode: firmware: requesting intel-ucode" messages upon 'upping' a cpu, do you? sure, my test is somewhat limited... anyway, first of all I'd like to get a clear understanding of your logs. Thanks for yout test btw. :-)) > > > Regards, > Andreas > -- Dmitry ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-05 18:40 ` Dmitry Adamushko @ 2009-11-06 12:34 ` Andreas Herrmann 2009-11-06 12:56 ` Dmitry Adamushko 0 siblings, 1 reply; 18+ messages in thread From: Andreas Herrmann @ 2009-11-06 12:34 UTC (permalink / raw) To: Dmitry Adamushko Cc: linux-kernel, Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner On Thu, Nov 05, 2009 at 07:40:53PM +0100, Dmitry Adamushko wrote: > 2009/11/5 Andreas Herrmann <herrmann.der.user@googlemail.com>: > > The patches don't properly work here. > > > > (1) For instance I got following log entries when doing > > suspend/resume, doing CPU offline/online test and reloading the > > module: > > To avoid possible misunderstandings, I'd like to clarify the output below. > > > microcode: original microcode versions... > > microcode: CPU0-3: patch_level=0x1000065 > > So this is the 1st time you have loaded a module. > > > platform microcode: firmware: requesting amd-ucode/microcode_amd.bin > > ... > > microcode: CPU0-1,3: patch_level=0x1000083 > > before or after loading a module? CPU2 is down, isn't it? No, no CPU was offline at this moment. They all were brought back online after some CPU hotplug and/or suspend/resume tests. > > microcode: CPU2-3: patch_level=0x1000065 Both messages showed up after same ucode-update process. > same question as above. Same answer as above all CPUs are online. > Here, either CPUs 0 and 1 are down or have a > different version. Both above messages don't make sense taken together See, and that's the problem. > (CPU3 belongs to both sets) unless summarize_cpu_info() is utterly > broken. I didn't check that yet. > > Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba > > > > The patch levels are: > > > > # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done > > PATCH_LEVEL = 0x0000000001000083 > > PATCH_LEVEL = 0x0000000001000083 > > PATCH_LEVEL = 0x0000000001000065 > > PATCH_LEVEL = 0x0000000001000065 > > this is after your test has been stopped and all the CPUs are up, right? Yes. > > (2) During suspend/resume the ucode is not updated: > > > > hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done > > PATCH_LEVEL = 0x0000000001000083 > > PATCH_LEVEL = 0x0000000001000083 > > PATCH_LEVEL = 0x0000000001000083 > > PATCH_LEVEL = 0x0000000001000083 > > hadburg linux # pm-suspend > > hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done > > PATCH_LEVEL = 0x0000000001000065 > > PATCH_LEVEL = 0x0000000001000065 > > PATCH_LEVEL = 0x0000000001000065 > > PATCH_LEVEL = 0x0000000001000065 > > > > > > That used to work w/o your patches. Didn't have time to look why this > > is now failing. You've changed mc_cpu_callback() -- most likely that > > is causing this regression. > > Hmm, cpu-event-callbacks seem to be working on my (Intel) setup. I > have enabled pr_debug messages and also did a little trick to allow > ucode of the same version to be loaded (my cpu is of the recent ucode > by itself) and I can see cpu-callback events for both resuming and > cpu-up cases. > > (firstly, upgraded with microcode_ctl as I only have a .dat file) > > suspend-resume > ... > [ 584.506371] microcode: CPU1 removed > [ 584.516018] microcode: CPU0 updated to revision 0x57, date = 2007-03-15 > [ 584.597326] microcode: CPU1 updated upon resume > [ 584.597562] microcode: CPU1 updated to revision 0x57, date = 2007-03-15 > [ 584.597565] microcode: CPU1 added > ... > > and now cpu1 : down -> up > > [ 1616.932249] microcode: CPU1 removed > [ 1633.942502] platform microcode: firmware: requesting intel-ucode/06-0f-02 > [ 1633.954638] microcode: data file intel-ucode/06-0f-02 load failed > [ 1633.954642] microcode: CPU1 added > > > as I understand, you don't see " platform microcode: firmware: > requesting intel-ucode" messages upon 'upping' a cpu, do you? Sure, no intel-ucode messages as I tested with AMD CPUs ;-) But otherwise no, no messages. > sure, my test is somewhat limited... anyway, first of all I'd like to > get a clear understanding of your logs. Thanks for yout test btw. :-)) I'll send you full logs asap. Regards, Andreas ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-06 12:34 ` Andreas Herrmann @ 2009-11-06 12:56 ` Dmitry Adamushko 2009-11-06 19:46 ` Andreas Herrmann 0 siblings, 1 reply; 18+ messages in thread From: Dmitry Adamushko @ 2009-11-06 12:56 UTC (permalink / raw) To: Andreas Herrmann Cc: linux-kernel, Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner 2009/11/6 Andreas Herrmann <herrmann.der.user@googlemail.com>: >>> [ ... ] >> > ... >> > microcode: CPU0-1,3: patch_level=0x1000083 >> >> before or after loading a module? CPU2 is down, isn't it? > > No, no CPU was offline at this moment. They all were brought back > online after some CPU hotplug and/or suspend/resume tests. > >> > microcode: CPU2-3: patch_level=0x1000065 > > Both messages showed up after same ucode-update process. > >> same question as above. > > Same answer as above all CPUs are online. > >> Here, either CPUs 0 and 1 are down or have a >> different version. Both above messages don't make sense taken together > > See, and that's the problem. > >> (CPU3 belongs to both sets) unless summarize_cpu_info() is utterly >> broken. > > I didn't check that yet. Yeah, this behavior is likely due to a missing cpumask_clear() in summarize_cpu_info(). should be as follows: if (!alloc_cpumask_var(&cpulist, GFP_KERNEL)) return; + cpumask_clear(cpulist); >> sure, my test is somewhat limited... anyway, first of all I'd like to >> get a clear understanding of your logs. Thanks for yout test btw. :-)) > > I'll send you full logs asap. Thanks. Maybe it's something about a particular sequence of actions that triggers this behavior. Or was it reproducible with the very first pm-suspend invocation after "modprobe microcode.ko"? > > Regards, > Andreas > -- Dmitry ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-06 12:56 ` Dmitry Adamushko @ 2009-11-06 19:46 ` Andreas Herrmann 2009-11-07 12:22 ` Dmitry Adamushko 0 siblings, 1 reply; 18+ messages in thread From: Andreas Herrmann @ 2009-11-06 19:46 UTC (permalink / raw) To: Dmitry Adamushko Cc: linux-kernel, Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner [-- Attachment #1: Type: text/plain, Size: 2143 bytes --] On Fri, Nov 06, 2009 at 01:56:31PM +0100, Dmitry Adamushko wrote: > 2009/11/6 Andreas Herrmann <herrmann.der.user@googlemail.com>: <snip> > >> (CPU3 belongs to both sets) unless summarize_cpu_info() is utterly > >> broken. > > > > I didn't check that yet. > > Yeah, this behavior is likely due to a missing cpumask_clear() in > summarize_cpu_info(). Yeah, that fixes the wrong messages. The other problem of not-updated CPU microcode after suspend/resume persists. > should be as follows: > > if (!alloc_cpumask_var(&cpulist, GFP_KERNEL)) > return; > > + cpumask_clear(cpulist); Better use zalloc_cpumask instead of alloc/clear. > >> sure, my test is somewhat limited... anyway, first of all I'd like to > >> get a clear understanding of your logs. Thanks for yout test btw. :-)) > > > > I'll send you full logs asap. > > Thanks. Maybe it's something about a particular sequence of actions > that triggers this behavior. Or was it reproducible with the very > first pm-suspend invocation after "modprobe microcode.ko"? The sequence is: 1. loading microcode.ko 2. setting cpu2 offline 3. setting cpu2 online 4. suspend (pm-suspend) 5. resume microcode of CPU2 is not updated: # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done PATCH_LEVEL = 0x0000000001000083 PATCH_LEVEL = 0x0000000001000083 PATCH_LEVEL = 0x0000000001000065 PATCH_LEVEL = 0x0000000001000083 dmesg attached. As I've said, that test used to pass with all CPUs updated to new ucode in the past (at least that I think so ;-( -- but in contrast to my previous mail this doesn't seem to be related to your patch. I tested latest mainline and the test fails as well ... seems that I need to do some debugging. Regards, Andreas PS1: You should remove the needless newline from the patch level string: static int version_snprintf(char *buf, int len, struct cpu_signature *csig) { - return snprintf(buf, len, "patch_level=0x%x\n", csig->rev); + return snprintf(buf, len, "patch_level=0x%x", csig->rev); } PS2: I plan to remove further needless messages from the amd ucode driver asap. [-- Attachment #2: dmesg-dimm --] [-- Type: text/plain, Size: 40975 bytes --] Linux version 2.6.32-rc6 (root@hadburg) (gcc version 4.4.1 (Gentoo 4.4.1 p1.0) ) #8 SMP Fri Nov 6 19:54:37 CET 2009 Command line: root=/dev/sda2 video=radeonfb:noaccel console=uart,io,0xe800,115200 console=tty0 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f400 (usable) BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000cffc0000 (usable) BIOS-e820: 00000000cffc0000 - 00000000cffce000 (ACPI data) BIOS-e820: 00000000cffce000 - 00000000cfff0000 (ACPI NVS) BIOS-e820: 00000000cfff0000 - 00000000d0000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 0000000100000000 - 0000000130000000 (usable) Early serial console at I/O port 0xe800 (options '115200') bootconsole [uart0] enabled DMI present. AMI BIOS detected: BIOS may corrupt low RAM, working around it. e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) last_pfn = 0x130000 max_arch_pfn = 0x400000000 MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-EFFFF uncachable F0000-FFFFF write-protect MTRR variable ranges enabled: 0 base 000000000000 mask FFFF80000000 write-back 1 base 000080000000 mask FFFFC0000000 write-back 2 base 0000C0000000 mask FFFFF0000000 write-back 3 disabled 4 disabled 5 disabled 6 disabled 7 disabled TOM2: 0000000130000000 aka 4864M x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 e820 update range: 00000000d0000000 - 0000000100000000 (usable) ==> (reserved) last_pfn = 0xcffc0 max_arch_pfn = 0x400000000 initial memory mapped : 0 - 20000000 Using GB pages for direct mapping init_memory_mapping: 0000000000000000-00000000cffc0000 0000000000 - 00c0000000 page 1G 00c0000000 - 00cfe00000 page 2M 00cfe00000 - 00cffc0000 page 4k kernel direct mapping tables up to cffc0000 @ 10000-13000 init_memory_mapping: 0000000100000000-0000000130000000 0100000000 - 0130000000 page 2M kernel direct mapping tables up to 130000000 @ 12000-14000 ACPI: RSDP 00000000000f97e0 00024 (v02 ACPIAM) ACPI: XSDT 00000000cffc0100 00054 (v01 043008 XSDT0025 20080430 MSFT 00000097) ACPI: FACP 00000000cffc0290 000F4 (v03 043008 FACP0025 20080430 MSFT 00000097) ACPI: DSDT 00000000cffc0440 0833A (v01 MMKA0 MMKA05-3 00000000 INTL 20051117) ACPI: FACS 00000000cffce000 00040 ACPI: APIC 00000000cffc0390 0006C (v01 043008 APIC0025 20080430 MSFT 00000097) ACPI: GFCM 00000000cffc0400 0003C (v01 043008 OEMMCFG 20080430 MSFT 00000097) ACPI: OEMB 00000000cffce040 00071 (v01 043008 OEMB0025 20080430 MSFT 00000097) ACPI: HPET 00000000cffc8780 00038 (v01 043008 OEMHPET 20080430 MSFT 00000097) ACPI: SSDT 00000000cffc87c0 00544 (v01 A M I POWERNOW 00000001 AMD 00000001) ACPI: Local APIC address 0xfee00000 Scanning NUMA topology in Northbridge 24 No NUMA configuration found Faking a node at 0000000000000000-0000000130000000 Bootmem setup node 0 0000000000000000-0000000130000000 NODE_DATA [0000000000013000 - 0000000000016fff] bootmap [0000000000017000 - 000000000003cfff] pages 26 (7 early reservations) ==> bootmem [0000000000 - 0130000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000] #2 [0001000000 - 000175d184] TEXT DATA BSS ==> [0001000000 - 000175d184] #3 [000008d400 - 0000100000] BIOS reserved ==> [000008d400 - 0000100000] #4 [000175e000 - 000175e1d5] BRK ==> [000175e000 - 000175e1d5] #5 [0000010000 - 0000012000] PGTABLE ==> [0000010000 - 0000012000] #6 [0000012000 - 0000013000] PGTABLE ==> [0000012000 - 0000013000] found SMP MP-table at [ffff8800000ff780] ff780 [ffffea0000000000-ffffea00043fffff] PMD -> [ffff880028600000-ffff88002bffffff] on node 0 Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00130000 Movable zone start PFN for each node early_node_map[3] active PFN ranges 0: 0x00000010 -> 0x0000009f 0: 0x00000100 -> 0x000cffc0 0: 0x00100000 -> 0x00130000 On node 0 totalpages: 1048399 DMA zone: 56 pages used for memmap DMA zone: 120 pages reserved DMA zone: 3807 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 833528 pages, LIFO batch:31 Normal zone: 2688 pages used for memmap Normal zone: 193920 pages, LIFO batch:31 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 4, version 33, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8300 base: 0xfed00000 SMP: Allowing 4 CPUs, 0 hotplug CPUs nr_irqs_gsi: 24 Allocating PCI resources starting at d0000000 (gap: d0000000:10000000) NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1 PERCPU: Embedded 25 pages/cpu @ffff880028200000 s73432 r8192 d20776 u524288 pcpu-alloc: s73432 r8192 d20776 u524288 alloc=1*2097152 pcpu-alloc: [0] 0 1 2 3 Built 1 zonelists in Node order, mobility grouping on. Total pages: 1031255 Policy zone: Normal Kernel command line: root=/dev/sda2 video=radeonfb:noaccel console=uart,io,0xe800,115200 console=tty0 PID hash table entries: 4096 (order: 3, 32768 bytes) Initializing CPU#0 Checking aperture... No AGP bridge found Node 0: aperture @ 20000000 size 32 MB Aperture pointing to e820 RAM. Ignoring. Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Mapping aperture over 65536 KB of RAM @ 20000000 Memory: 4060412k/4980736k available (3779k kernel code, 787140k absent, 133184k reserved, 2706k data, 516k init) Hierarchical RCU implementation. NR_IRQS:384 Extended CMOS year: 2000 Console: colour VGA+ 80x25 console [tty0] enabled, bootconsole disabled hpet clockevent registered HPET: 4 timers in total, 0 timers will be used for per-cpu timer Fast TSC calibration failed TSC: Unable to calibrate against PIT TSC: using HPET reference calibration Detected 2283.669 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 4599.80 BogoMIPS (lpj=2299900) Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 0/0x0 -> Node 0 tseg: 0000000000 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 6 MCE banks using C1E aware idle routine Performance Events: AMD PMU driver. ... version: 0 ... bit width: 48 ... generic registers: 4 ... value mask: 0000ffffffffffff ... max period: 00007fffffffffff ... fixed-purpose events: 0 ... event mask: 000000000000000f ACPI: Core revision 20090903 Setting APIC routing to flat ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: AMD Phenom(tm) 9650 Quad-Core Processor stepping 03 Booting processor 1 APIC 0x1 ip 0x6000 Initializing CPU#1 Calibrating delay using timer specific routine.. 4600.09 BogoMIPS (lpj=2300048) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 1/0x1 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 CPU1: AMD Phenom(tm) 9650 Quad-Core Processor stepping 03 checking TSC synchronization [CPU#0 -> CPU#1]: passed. Booting processor 2 APIC 0x2 ip 0x6000 Initializing CPU#2 Calibrating delay using timer specific routine.. 4599.97 BogoMIPS (lpj=2299989) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 2/0x2 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 2 CPU2: AMD Phenom(tm) 9650 Quad-Core Processor stepping 03 checking TSC synchronization [CPU#0 -> CPU#2]: passed. Booting processor 3 APIC 0x3 ip 0x6000 Initializing CPU#3 Calibrating delay using timer specific routine.. 4600.00 BogoMIPS (lpj=2300004) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 3/0x3 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 3 CPU3: AMD Phenom(tm) 9650 Quad-Core Processor stepping 03 checking TSC synchronization [CPU#0 -> CPU#3]: passed. Brought up 4 CPUs Total of 4 processors activated (18399.88 BogoMIPS). CPU0 attaching sched-domain: domain 0: span 0-3 level MC groups: 0 1 2 3 CPU1 attaching sched-domain: domain 0: span 0-3 level MC groups: 1 2 3 0 CPU2 attaching sched-domain: domain 0: span 0-3 level MC groups: 2 3 0 1 CPU3 attaching sched-domain: domain 0: span 0-3 level MC groups: 3 0 1 2 NET: Registered protocol family 16 i2c-core: driver [dummy] registered node 0 link 0: io port [1000, ffffff] TOM: 00000000d0000000 aka 3328M Fam 10h mmconf [e0000000, efffffff] node 0 link 0: mmio [e0000000, efffffff] ==> none node 0 link 0: mmio [f0000000, ffffffff] node 0 link 0: mmio [a0000, bffff] node 0 link 0: mmio [d0000000, dfffffff] TOM2: 0000000130000000 aka 4864M bus: [00,07] on node 0 link 0 bus: 00 index 0 io port: [0, ffff] bus: 00 index 1 mmio: [f0000000, ffffffff] bus: 00 index 2 mmio: [a0000, bffff] bus: 00 index 3 mmio: [d0000000, dfffffff] bus: 00 index 4 mmio: [130000000, fcffffffff] ACPI: bus type pci registered PCI: Using configuration type 1 for base access PCI: Using configuration type 1 for extended access bio: create slab <bio-0> at 0 ACPI: EC: Look up EC in DSDT ACPI: Executed 3 blocks of module-level executable AML code ACPI: Interpreter enabled ACPI: (supports S0 S1 S3 S5) ACPI: Using IOAPIC for interrupt routing ACPI Warning: Incorrect checksum in table [OEMB] - FF, should be F6 (20090903/tbutils-314) ACPI: No dock devices found. ACPI: PCI Root Bridge [PCI0] (0000:00) pci 0000:00:00.0: reg 1c 64bit mmio: [0xe0000000-0xffffffff] pci 0000:00:12.0: reg 10 io port: [0x9000-0x9007] pci 0000:00:12.0: reg 14 io port: [0x8000-0x8003] pci 0000:00:12.0: reg 18 io port: [0x7000-0x7007] pci 0000:00:12.0: reg 1c io port: [0x6000-0x6003] pci 0000:00:12.0: reg 20 io port: [0x5000-0x500f] pci 0000:00:12.0: reg 24 32bit mmio: [0xfe8ff800-0xfe8ffbff] pci 0000:00:12.0: set SATA to AHCI mode pci 0000:00:13.0: reg 10 32bit mmio: [0xfe8fe000-0xfe8fefff] pci 0000:00:13.1: reg 10 32bit mmio: [0xfe8fd000-0xfe8fdfff] pci 0000:00:13.2: reg 10 32bit mmio: [0xfe8fc000-0xfe8fcfff] pci 0000:00:13.3: reg 10 32bit mmio: [0xfe8fb000-0xfe8fbfff] pci 0000:00:13.4: reg 10 32bit mmio: [0xfe8fa000-0xfe8fafff] pci 0000:00:13.5: reg 10 32bit mmio: [0xfe8ff000-0xfe8ff0ff] pci 0000:00:13.5: supports D1 D2 pci 0000:00:13.5: PME# supported from D0 D1 D2 D3hot pci 0000:00:13.5: PME# disabled pci 0000:00:14.0: reg 10 io port: [0xb00-0xb0f] pci 0000:00:14.1: reg 10 io port: [0x00-0x07] pci 0000:00:14.1: reg 14 io port: [0x00-0x03] pci 0000:00:14.1: reg 18 io port: [0x00-0x07] pci 0000:00:14.1: reg 1c io port: [0x00-0x03] pci 0000:00:14.1: reg 20 io port: [0xff00-0xff0f] pci 0000:00:14.2: reg 10 64bit mmio: [0xfe8f4000-0xfe8f7fff] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold pci 0000:00:14.2: PME# disabled pci 0000:01:00.0: reg 10 32bit mmio pref: [0xd0000000-0xdfffffff] pci 0000:01:00.0: reg 14 io port: [0xa000-0xa0ff] pci 0000:01:00.0: reg 18 32bit mmio: [0xfe9f0000-0xfe9fffff] pci 0000:01:00.0: reg 30 32bit mmio pref: [0xfe9c0000-0xfe9dffff] pci 0000:01:00.0: supports D1 D2 pci 0000:01:00.1: reg 10 32bit mmio: [0xfe9e0000-0xfe9effff] pci 0000:01:00.1: supports D1 D2 pci 0000:00:02.0: bridge io port: [0xa000-0xafff] pci 0000:00:02.0: bridge 32bit mmio: [0xfe900000-0xfe9fffff] pci 0000:00:02.0: bridge 64bit mmio pref: [0xd0000000-0xdfffffff] pci 0000:02:00.0: reg 24 32bit mmio: [0xfeafe000-0xfeafffff] pci 0000:02:00.0: PME# supported from D3hot pci 0000:02:00.0: PME# disabled pci 0000:02:00.1: reg 10 io port: [0xc800-0xc807] pci 0000:02:00.1: reg 14 io port: [0xc400-0xc403] pci 0000:02:00.1: reg 18 io port: [0xc000-0xc007] pci 0000:02:00.1: reg 1c io port: [0xb800-0xb803] pci 0000:02:00.1: reg 20 io port: [0xb400-0xb40f] pci 0000:00:09.0: bridge io port: [0xb000-0xcfff] pci 0000:00:09.0: bridge 32bit mmio: [0xfea00000-0xfeafffff] pci 0000:03:00.0: reg 10 64bit mmio: [0xfebfc000-0xfebfffff] pci 0000:03:00.0: reg 18 io port: [0xd800-0xd8ff] pci 0000:03:00.0: reg 30 32bit mmio pref: [0xfebc0000-0xfebdffff] pci 0000:03:00.0: supports D1 D2 pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold pci 0000:03:00.0: PME# disabled pci 0000:00:0a.0: bridge io port: [0xd000-0xdfff] pci 0000:00:0a.0: bridge 32bit mmio: [0xfeb00000-0xfebfffff] pci 0000:04:05.0: reg 10 io port: [0xe800-0xe81f] pci 0000:00:14.4: transparent bridge pci 0000:00:14.4: bridge io port: [0xe000-0xefff] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE2._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE9._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCEA._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 9) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled. vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing pci 0000:00:00.0: BAR 3: address space collision on of device [0xe0000000-0xffffffff] pci 0000:00:00.0: BAR 3: can't allocate resource hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0 hpet0: 4 comparators, 32-bit 14.318180 MHz counter Switching to clocksource tsc pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:0d: mem resource (0x0-0x9ffff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling pnp 00:0d: mem resource (0xe0000-0xfffff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling pnp 00:0d: mem resource (0x100000-0xcfffffff) overlaps 0000:00:00.0 BAR 3 (0x0-0x1fffffff), disabling pnp: PnP ACPI: found 14 devices ACPI: ACPI bus type pnp unregistered system 00:08: ioport range 0xe00-0xe0f has been reserved system 00:08: ioport range 0xe80-0xe8f has been reserved system 00:08: ioport range 0xf40-0xf4f has been reserved system 00:08: ioport range 0xa30-0xa3f has been reserved system 00:0a: iomem range 0xfec00000-0xfec00fff could not be reserved system 00:0a: iomem range 0xfee00000-0xfee00fff has been reserved system 00:0b: ioport range 0x4d0-0x4d1 has been reserved system 00:0b: ioport range 0x40b-0x40b has been reserved system 00:0b: ioport range 0x4d6-0x4d6 has been reserved system 00:0b: ioport range 0xc00-0xc01 has been reserved system 00:0b: ioport range 0xc14-0xc14 has been reserved system 00:0b: ioport range 0xc50-0xc51 has been reserved system 00:0b: ioport range 0xc52-0xc52 has been reserved system 00:0b: ioport range 0xc6c-0xc6c has been reserved system 00:0b: ioport range 0xc6f-0xc6f has been reserved system 00:0b: ioport range 0xcd0-0xcd1 has been reserved system 00:0b: ioport range 0xcd2-0xcd3 has been reserved system 00:0b: ioport range 0xcd4-0xcd5 has been reserved system 00:0b: ioport range 0xcd6-0xcd7 has been reserved system 00:0b: ioport range 0xcd8-0xcdf has been reserved system 00:0b: ioport range 0x800-0x89f has been reserved system 00:0b: ioport range 0xb10-0xb1f has been reserved system 00:0b: ioport range 0x900-0x90f has been reserved system 00:0b: ioport range 0x910-0x91f has been reserved system 00:0b: ioport range 0xfe00-0xfefe has been reserved system 00:0b: iomem range 0xffb80000-0xffbfffff has been reserved system 00:0b: iomem range 0xfff00000-0xffffffff has been reserved system 00:0c: iomem range 0xe0000000-0xefffffff has been reserved system 00:0d: iomem range 0xfec00000-0x10d7fffff could not be reserved pci 0000:00:02.0: PCI bridge, secondary bus 0000:01 pci 0000:00:02.0: IO window: 0xa000-0xafff pci 0000:00:02.0: MEM window: 0xfe900000-0xfe9fffff pci 0000:00:02.0: PREFETCH window: 0x000000d0000000-0x000000dfffffff pci 0000:00:09.0: PCI bridge, secondary bus 0000:02 pci 0000:00:09.0: IO window: 0xb000-0xcfff pci 0000:00:09.0: MEM window: 0xfea00000-0xfeafffff pci 0000:00:09.0: PREFETCH window: disabled pci 0000:00:0a.0: PCI bridge, secondary bus 0000:03 pci 0000:00:0a.0: IO window: 0xd000-0xdfff pci 0000:00:0a.0: MEM window: 0xfeb00000-0xfebfffff pci 0000:00:0a.0: PREFETCH window: disabled pci 0000:00:14.4: PCI bridge, secondary bus 0000:04 pci 0000:00:14.4: IO window: 0xe000-0xefff pci 0000:00:14.4: MEM window: disabled pci 0000:00:14.4: PREFETCH window: disabled pci 0000:00:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 pci 0000:00:02.0: setting latency timer to 64 pci 0000:00:09.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 pci 0000:00:09.0: setting latency timer to 64 pci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 pci 0000:00:0a.0: setting latency timer to 64 pci_bus 0000:00: resource 0 io: [0x00-0xffff] pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffffffffffff] pci_bus 0000:01: resource 0 io: [0xa000-0xafff] pci_bus 0000:01: resource 1 mem: [0xfe900000-0xfe9fffff] pci_bus 0000:01: resource 2 pref mem [0xd0000000-0xdfffffff] pci_bus 0000:02: resource 0 io: [0xb000-0xcfff] pci_bus 0000:02: resource 1 mem: [0xfea00000-0xfeafffff] pci_bus 0000:03: resource 0 io: [0xd000-0xdfff] pci_bus 0000:03: resource 1 mem: [0xfeb00000-0xfebfffff] pci_bus 0000:04: resource 0 io: [0xe000-0xefff] pci_bus 0000:04: resource 3 io: [0x00-0xffff] pci_bus 0000:04: resource 4 mem: [0x000000-0xffffffffffffffff] NET: Registered protocol family 2 IP route cache hash table entries: 131072 (order: 8, 1048576 bytes) TCP established hash table entries: 524288 (order: 11, 8388608 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 524288 bind 65536) TCP reno registered NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. pci 0000:01:00.0: Boot video device PCI-DMA: Disabling AGP. PCI-DMA: aperture base @ 20000000 size 65536 KB PCI-DMA: using GART IOMMU. PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture HugeTLB registered 2 MB page size, pre-allocated 0 pages Slow work thread pool: Starting up Slow work thread pool: Ready msgmni has been set to 7930 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pcieport 0000:00:02.0: irq 24 for MSI/MSI-X pcieport 0000:00:02.0: setting latency timer to 64 pcieport 0000:00:09.0: irq 25 for MSI/MSI-X pcieport 0000:00:09.0: setting latency timer to 64 pcieport 0000:00:0a.0: irq 26 for MSI/MSI-X pcieport 0000:00:0a.0: setting latency timer to 64 input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 ACPI: Power Button [PWRB] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 ACPI: Power Button [PWRF] processor LNXCPU:00: registered as cooling_device0 processor LNXCPU:01: registered as cooling_device1 processor LNXCPU:02: registered as cooling_device2 processor LNXCPU:03: registered as cooling_device3 Real Time Clock Driver v1.12b Linux agpgart interface v0.103 Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial 0000:04:05.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 0000:04:05.0: ttyS1 at I/O 0xe800 (irq = 20) is a 16550A console [ttyS1] enabled 0000:04:05.0: ttyS2 at I/O 0xe808 (irq = 20) is a 16550A Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 loop: module loaded Uniform Multi-Platform E-IDE driver atiixp 0000:00:14.1: IDE controller (0x1002:0x438c rev 0x00) pci 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16 atiixp 0000:00:14.1: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xff00-0xff07 Probing IDE interface ide0... hda: SONY DVD-ROM DDU1615, ATAPI CD/DVD-ROM drive hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hda: UDMA/66 mode selected ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports ide-gd driver 1.18 ide-cd driver 5.00 ide-cd: hda: ATAPI 40X DVD-ROM drive, 1727kB Cache Uniform CD-ROM driver Revision: 3.20 ahci 0000:00:12.0: version 3.0 ahci 0000:00:12.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 ahci 0000:00:12.0: controller can't do 64bit DMA, forcing 32bit ahci 0000:00:12.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci 0000:00:12.0: flags: ncq sntf ilck led clo pmp pio ccc scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci ata1: SATA max UDMA/133 abar m1024@0xfe8ff800 port 0xfe8ff900 irq 22 ata2: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 22 ata3: SATA max UDMA/133 abar m1024@0xfe8ff800 port 0xfe8ffa00 irq 22 ata4: SATA max UDMA/133 abar m1024@0xfe8ff800 port 0xfe8ffa80 irq 22 ahci 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 ahci 0000:02:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode ahci 0000:02:00.0: flags: 64bit ncq pm led clo pmp pio slum part ahci 0000:02:00.0: setting latency timer to 64 scsi4 : ahci scsi5 : ahci ata5: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe100 irq 17 ata6: SATA max UDMA/133 abar m8192@0xfeafe000 port 0xfeafe180 irq 17 sky2 driver version 1.25 sky2 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 sky2 0000:03:00.0: setting latency timer to 64 sky2 0000:03:00.0: Yukon-2 EC chip revision 2 sky2 0000:03:00.0: irq 27 for MSI/MSI-X sky2 eth0: addr 00:0c:87:00:40:20 console [netcon0] enabled netconsole: network logging started Fusion MPT base driver 3.04.12 Copyright (c) 1999-2008 LSI Corporation Fusion MPT SAS Host driver 3.04.12 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd 0000:00:13.5: PCI INT D -> GSI 19 (level, low) -> IRQ 19 ehci_hcd 0000:00:13.5: EHCI Host Controller ehci_hcd 0000:00:13.5: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:13.5: applying AMD SB600/SB700 USB freeze workaround ehci_hcd 0000:00:13.5: debug port 1 ehci_hcd 0000:00:13.5: irq 19, io mem 0xfe8ff000 ehci_hcd 0000:00:13.5: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 10 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd 0000:00:13.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:13.0: irq 16, io mem 0xfe8fe000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ohci_hcd 0000:00:13.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ohci_hcd 0000:00:13.1: OHCI Host Controller ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 3 ohci_hcd 0000:00:13.1: irq 17, io mem 0xfe8fd000 usb usb3: configuration #1 chosen from 1 choice ata3: SATA link down (SStatus 0 SControl 300) ata1: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ohci_hcd 0000:00:13.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:13.2: OHCI Host Controller ohci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 4 ohci_hcd 0000:00:13.2: irq 18, io mem 0xfe8fc000 ata6: SATA link down (SStatus 0 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected ohci_hcd 0000:00:13.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ohci_hcd 0000:00:13.3: OHCI Host Controller ohci_hcd 0000:00:13.3: new USB bus registered, assigned bus number 5 ohci_hcd 0000:00:13.3: irq 17, io mem 0xfe8fb000 usb usb5: configuration #1 chosen from 1 choice hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected ohci_hcd 0000:00:13.4: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:13.4: OHCI Host Controller ohci_hcd 0000:00:13.4: new USB bus registered, assigned bus number 6 ohci_hcd 0000:00:13.4: irq 18, io mem 0xfe8fa000 usb usb6: configuration #1 chosen from 1 choice hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected uhci_hcd: USB Universal Host Controller Interface driver Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice i2c /dev entries driver i2c-core: driver [dev_driver] registered ACPI: I/O resource piix4_smbus [0xb00-0xb07] conflicts with ACPI region SOR1 [0xb00-0xb0f] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver it87: Found IT8716F chip at 0xe80, revision 1 input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2 cpuidle: using governor ladder cpuidle: using governor menu Advanced Linux Sound Architecture Driver Version 1.0.21. HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 hda_codec: ALC889A: BIOS auto-probing. ALSA device list: #0: HDA ATI SB at 0xfe8f4000 irq 16 TCP cubic registered NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 powernow-k8: Found 1 AMD Phenom(tm) 9650 Quad-Core Processor processors (4 cpu cores) (version 2.20.00) powernow-k8: 0 : pstate 0 (2300 MHz) powernow-k8: 1 : pstate 1 (1150 MHz) ata2: softreset failed (device not ready) ata2: applying SB600 PMP SRST workaround and retrying ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-7: ST3120811AS, 3.AAE, max UDMA/133 ata2.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 31/32) ata2.00: SB600 AHCI: limiting to 255 sectors per cmd ata2.00: SB600 AHCI: limiting to 255 sectors per cmd ata2.00: configured for UDMA/133 scsi 1:0:0:0: Direct-Access ATA ST3120811AS 3.AA PQ: 0 ANSI: 5 sd 1:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 1:0:0:0: Attached scsi generic sg0 type 0 sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 > sd 1:0:0:0: [sda] Attached SCSI disk kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with writeback data mode. VFS: Mounted root (ext3 filesystem) readonly on device 8:2. Freeing unused kernel memory: 516k freed udev: starting version 141 EXT3 FS on sda2, internal journal Adding 1959920k swap on /dev/sda3. Priority:-1 extents:1 across:1959920k sky2 eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control rx ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present microcode: original microcode versions... microcode: CPU0-3: patch_level=0x1000065 platform microcode: firmware: requesting amd-ucode/microcode_amd.bin microcode: size 1936, total_size 960 microcode: CPU0: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022) microcode: size 968, total_size 960 platform microcode: firmware: requesting amd-ucode/microcode_amd.bin microcode: size 1936, total_size 960 microcode: CPU1: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022) microcode: size 968, total_size 960 platform microcode: firmware: requesting amd-ucode/microcode_amd.bin microcode: size 1936, total_size 960 microcode: CPU2: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022) microcode: size 968, total_size 960 platform microcode: firmware: requesting amd-ucode/microcode_amd.bin microcode: size 1936, total_size 960 microcode: CPU3: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022) microcode: size 968, total_size 960 microcode: microcode versions after update... microcode: CPU0-3: patch_level=0x1000083 Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba CPU 2 is now offline CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU2 attaching NULL sched-domain. CPU3 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 0-1,3 level MC groups: 0 1 3 CPU1 attaching sched-domain: domain 0: span 0-1,3 level MC groups: 1 3 0 CPU3 attaching sched-domain: domain 0: span 0-1,3 level MC groups: 3 0 1 Booting processor 2 APIC 0x2 ip 0x6000 Initializing CPU#2 Calibrating delay using timer specific routine.. 4599.83 BogoMIPS (lpj=2299918) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 2/0x2 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 2 CPU2: AMD Phenom(tm) 9650 Quad-Core Processor stepping 03 checking TSC synchronization [CPU#0 -> CPU#2]: passed. CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU3 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 0-3 level MC groups: 0 1 2 3 CPU1 attaching sched-domain: domain 0: span 0-3 level MC groups: 1 2 3 0 CPU2 attaching sched-domain: domain 0: span 0-3 level MC groups: 2 3 0 1 CPU3 attaching sched-domain: domain 0: span 0-3 level MC groups: 3 0 1 2 platform microcode: firmware: requesting amd-ucode/microcode_amd.bin microcode: size 1936, total_size 960 microcode: CPU2: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022) microcode: size 968, total_size 960 PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) sd 1:0:0:0: [sda] Synchronizing SCSI cache sd 1:0:0:0: [sda] Stopping disk ACPI handle has no context! serial 00:06: disabled sky2 eth0: disabling interface ACPI handle has no context! ACPI handle has no context! ahci 0000:02:00.0: PCI INT A disabled HDA Intel 0000:00:14.2: PCI INT A disabled ATIIXP_IDE 0000:00:14.1: PCI INT A disabled ehci_hcd 0000:00:13.5: PCI INT D disabled ohci_hcd 0000:00:13.4: PCI INT C disabled ohci_hcd 0000:00:13.3: PCI INT B disabled ohci_hcd 0000:00:13.2: PCI INT C disabled ohci_hcd 0000:00:13.1: PCI INT B disabled ohci_hcd 0000:00:13.0: PCI INT A disabled ahci 0000:00:12.0: PCI INT A disabled ACPI: Preparing to enter system sleep state S3 Disabling non-boot CPUs ... CPU 1 is now offline CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU2 attaching NULL sched-domain. CPU3 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 0,2-3 level MC groups: 0 2 3 CPU2 attaching sched-domain: domain 0: span 0,2-3 level MC groups: 2 3 0 CPU3 attaching sched-domain: domain 0: span 0,2-3 level MC groups: 3 0 2 CPU1 is down CPU 2 is now offline CPU0 attaching NULL sched-domain. CPU2 attaching NULL sched-domain. CPU3 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 0,3 level MC groups: 0 3 CPU3 attaching sched-domain: domain 0: span 0,3 level MC groups: 3 0 CPU2 is down CPU 3 is now offline SMP alternatives: switching to UP code CPU0 attaching NULL sched-domain. CPU3 attaching NULL sched-domain. CPU0 attaching NULL sched-domain. CPU3 is down Extended CMOS year: 2000 Back to C! microcode: CPU0: updated (new patch_level=0x1000083) PCI-DMA: Resuming GART IOMMU PCI-DMA: Restoring GART aperture settings Extended CMOS year: 2000 Enabling non-boot CPUs ... SMP alternatives: switching to SMP code Booting processor 1 APIC 0x1 ip 0x6000 Initializing CPU#1 Calibrating delay using timer specific routine.. 4599.84 BogoMIPS (lpj=2299922) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 1/0x1 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 CPU1: AMD Phenom(tm) 9650 Quad-Core Processor stepping 03 checking TSC synchronization [CPU#0 -> CPU#1]: passed. CPU0 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 0-1 level MC groups: 0 1 CPU1 attaching sched-domain: domain 0: span 0-1 level MC groups: 1 0 microcode: CPU1: updated (new patch_level=0x1000083) CPU1 is up Booting processor 2 APIC 0x2 ip 0x6000 Initializing CPU#2 Calibrating delay using timer specific routine.. 4599.85 BogoMIPS (lpj=2299927) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 2/0x2 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 2 CPU2: AMD Phenom(tm) 9650 Quad-Core Processor stepping 03 checking TSC synchronization [CPU#1 -> CPU#2]: passed. CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 0-2 level MC groups: 0 1 2 CPU1 attaching sched-domain: domain 0: span 0-2 level MC groups: 1 2 0 CPU2 attaching sched-domain: domain 0: span 0-2 level MC groups: 2 0 1 CPU2 is up Booting processor 3 APIC 0x3 ip 0x6000 Initializing CPU#3 Calibrating delay using timer specific routine.. 4599.96 BogoMIPS (lpj=2299984) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 3/0x3 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 3 CPU3: AMD Phenom(tm) 9650 Quad-Core Processor stepping 03 checking TSC synchronization [CPU#2 -> CPU#3]: passed. CPU0 attaching NULL sched-domain. CPU1 attaching NULL sched-domain. CPU2 attaching NULL sched-domain. CPU0 attaching sched-domain: domain 0: span 0-3 level MC groups: 0 1 2 3 CPU1 attaching sched-domain: domain 0: span 0-3 level MC groups: 1 2 3 0 CPU2 attaching sched-domain: domain 0: span 0-3 level MC groups: 2 3 0 1 CPU3 attaching sched-domain: domain 0: span 0-3 level MC groups: 3 0 1 2 microcode: CPU3: updated (new patch_level=0x1000083) CPU3 is up ACPI: Waking up from system sleep state S3 pcieport 0000:00:02.0: restoring config space at offset 0x7 (was 0x2000a1a1, writing 0xa1a1) pcieport 0000:00:02.0: restoring config space at offset 0x1 (was 0x100107, writing 0x100507) pcieport 0000:00:09.0: restoring config space at offset 0x7 (was 0x2000c1b1, writing 0xc1b1) pcieport 0000:00:09.0: restoring config space at offset 0x1 (was 0x100107, writing 0x100507) pcieport 0000:00:0a.0: restoring config space at offset 0x1 (was 0x100107, writing 0x100507) ahci 0000:00:12.0: restoring config space at offset 0xf (was 0x100, writing 0x105) ahci 0000:00:12.0: restoring config space at offset 0x2 (was 0x1018f00, writing 0x1060100) ahci 0000:00:12.0: set SATA to AHCI mode ehci_hcd 0000:00:13.5: restoring config space at offset 0x1 (was 0x2b00000, writing 0x2b00113) HDA Intel 0000:00:14.2: restoring config space at offset 0xf (was 0x103, writing 0x3) HDA Intel 0000:00:14.2: restoring config space at offset 0x1 (was 0x4100006, writing 0x4100002) pci 0000:01:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10a) pci 0000:01:00.0: restoring config space at offset 0xc (was 0x0, writing 0xfe9c0000) pci 0000:01:00.0: restoring config space at offset 0x6 (was 0x0, writing 0xfe9f0000) pci 0000:01:00.0: restoring config space at offset 0x5 (was 0x1, writing 0xa001) pci 0000:01:00.0: restoring config space at offset 0x4 (was 0x8, writing 0xd0000008) pci 0000:01:00.0: restoring config space at offset 0x3 (was 0x800000, writing 0x800010) pci 0000:01:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100107) pci 0000:01:00.1: restoring config space at offset 0x4 (was 0x0, writing 0xfe9e0000) pci 0000:01:00.1: restoring config space at offset 0x3 (was 0x0, writing 0x10) pci 0000:01:00.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100007) ahci 0000:02:00.0: restoring config space at offset 0x8 (was 0xb401, writing 0x0) ahci 0000:02:00.0: restoring config space at offset 0x7 (was 0xb801, writing 0x0) ahci 0000:02:00.0: restoring config space at offset 0x6 (was 0xc001, writing 0x0) ahci 0000:02:00.0: restoring config space at offset 0x5 (was 0xc401, writing 0x0) ahci 0000:02:00.0: restoring config space at offset 0x4 (was 0xc801, writing 0x0) ahci 0000:02:00.0: restoring config space at offset 0x3 (was 0x10, writing 0x800010) ahci 0000:02:00.0: restoring config space at offset 0x2 (was 0x1018502, writing 0x1060102) pci 0000:02:00.1: restoring config space at offset 0x8 (was 0x1, writing 0xb401) pci 0000:02:00.1: restoring config space at offset 0x7 (was 0x1, writing 0xb801) pci 0000:02:00.1: restoring config space at offset 0x6 (was 0x1, writing 0xc001) pci 0000:02:00.1: restoring config space at offset 0x5 (was 0x1, writing 0xc401) pci 0000:02:00.1: restoring config space at offset 0x4 (was 0x1, writing 0xc801) sky2 0000:03:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a) sky2 0000:03:00.0: restoring config space at offset 0xc (was 0x0, writing 0xfebc0000) sky2 0000:03:00.0: restoring config space at offset 0x6 (was 0x1, writing 0xd801) sky2 0000:03:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xfebfc004) sky2 0000:03:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10) sky2 0000:03:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100507) serial 0000:04:05.0: restoring config space at offset 0xf (was 0x1ff, writing 0x107) serial 0000:04:05.0: restoring config space at offset 0x4 (was 0x1, writing 0xe801) serial 0000:04:05.0: restoring config space at offset 0x1 (was 0x2800080, writing 0x2800181) ahci 0000:00:12.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 ohci_hcd 0000:00:13.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ohci_hcd 0000:00:13.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ohci_hcd 0000:00:13.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ohci_hcd 0000:00:13.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ohci_hcd 0000:00:13.4: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ehci_hcd 0000:00:13.5: PCI INT D -> GSI 19 (level, low) -> IRQ 19 ATIIXP_IDE 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ATIIXP_IDE 0000:00:14.1: setting latency timer to 64 HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ahci 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 ahci 0000:02:00.0: setting latency timer to 64 sky2 eth0: enabling interface serial 00:06: activated ata3: SATA link down (SStatus 0 SControl 300) ata1: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) ata2: softreset failed (device not ready) ata2: applying SB600 PMP SRST workaround and retrying ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: SB600 AHCI: limiting to 255 sectors per cmd ata2.00: SB600 AHCI: limiting to 255 sectors per cmd ata2.00: configured for UDMA/133 sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control rx floppy driver state ------------------- now=4294746204 last interrupt=4294667714 diff=78490 last called handler=ffffffff811eb342 timeout_message=lock fdc last output bytes: 8 80 4294667699 8 80 4294667699 8 80 4294667699 8 80 4294667711 8 80 4294667711 8 80 4294667711 8 80 4294667711 e 80 4294667712 13 80 4294667712 0 90 4294667712 1a 90 4294667712 0 90 4294667712 12 90 4294667712 0 90 4294667712 14 90 4294667712 18 80 4294667712 8 80 4294667714 8 80 4294667714 8 80 4294667714 8 80 4294667714 last result at 4294667714 last redo_fd_request at 4294667714 status=0 fdc_busy=1 do_floppy=ffffffff811eb342 cont=ffffffff815deb80 current_req=(null) command_status=-1 floppy0: floppy timeout called hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hda: UDMA/66 mode selected sd 1:0:0:0: [sda] Starting disk Restarting tasks ... done. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-06 19:46 ` Andreas Herrmann @ 2009-11-07 12:22 ` Dmitry Adamushko 2009-11-11 16:07 ` Dmitry Adamushko 0 siblings, 1 reply; 18+ messages in thread From: Dmitry Adamushko @ 2009-11-07 12:22 UTC (permalink / raw) To: Andreas Herrmann Cc: linux-kernel, Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner 2009/11/6 Andreas Herrmann <herrmann.der.user@googlemail.com>: > On Fri, Nov 06, 2009 at 01:56:31PM +0100, Dmitry Adamushko wrote: >> 2009/11/6 Andreas Herrmann <herrmann.der.user@googlemail.com>: > > <snip> > >> >> (CPU3 belongs to both sets) unless summarize_cpu_info() is utterly >> >> broken. >> > >> > I didn't check that yet. >> >> Yeah, this behavior is likely due to a missing cpumask_clear() in >> summarize_cpu_info(). > > Yeah, that fixes the wrong messages. > The other problem of not-updated CPU microcode after suspend/resume persists. > >> should be as follows: >> >> if (!alloc_cpumask_var(&cpulist, GFP_KERNEL)) >> return; >> >> + cpumask_clear(cpulist); > > Better use zalloc_cpumask instead of alloc/clear. ok. > >> >> sure, my test is somewhat limited... anyway, first of all I'd like to >> >> get a clear understanding of your logs. Thanks for yout test btw. :-)) >> > >> > I'll send you full logs asap. >> >> Thanks. Maybe it's something about a particular sequence of actions >> that triggers this behavior. Or was it reproducible with the very >> first pm-suspend invocation after "modprobe microcode.ko"? > > The sequence is: > > 1. loading microcode.ko > 2. setting cpu2 offline > 3. setting cpu2 online > 4. suspend (pm-suspend) > 5. resume > > microcode of CPU2 is not updated: > > # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done > PATCH_LEVEL = 0x0000000001000083 > PATCH_LEVEL = 0x0000000001000083 > PATCH_LEVEL = 0x0000000001000065 > PATCH_LEVEL = 0x0000000001000083 > > dmesg attached. It looks like the microcode of CPU2 was not updated at step (3) [ and not cached in uci->mc so that there was nothing to be loaded at resume time later on ]. ... platform microcode: firmware: requesting amd-ucode/microcode_amd.bin microcode: size 1936, total_size 960 microcode: CPU2: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022) microcode: size 968, total_size 960 PM: Syncing filesystems ... done. ... These messages are from ->request_microcode_fw() but then there is nothing from ->apply_microcode(). I'd expect to see "microcode: CPU%d: updated (new patch_level=0x%x)". So either request_fw() -> generic_load_microcode() somehow fails to find/cache a ucode (while it could do this at microcode-load time) or apply_microcode_on_target() -> smp_call_function_single() fails in this context. I made a test (some changes to load a cached ->mc at cpu-online time) to verify the latter hypothesis and it didn't reveal any problems or it requires some special conditions (also my kernel is -rc5+). > > As I've said, that test used to pass with all CPUs updated to new > ucode in the past (at least that I think so ;-( -- but in contrast to > my previous mail this doesn't seem to be related to your patch. I > tested latest mainline and the test fails as well ... seems that I > need to do some debugging. Ok. Then by instrumenting ->request_microcode_fs() and apply_microcode_on_target() we would get a hint on what's wrong. > > > Regards, > Andreas > > PS1: You should remove the needless newline from the patch level string: > > static int version_snprintf(char *buf, int len, struct cpu_signature *csig) > { > - return snprintf(buf, len, "patch_level=0x%x\n", csig->rev); > + return snprintf(buf, len, "patch_level=0x%x", csig->rev); > } ack. -- Dmitry ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-07 12:22 ` Dmitry Adamushko @ 2009-11-11 16:07 ` Dmitry Adamushko 2009-11-11 19:38 ` Andreas Herrmann 0 siblings, 1 reply; 18+ messages in thread From: Dmitry Adamushko @ 2009-11-11 16:07 UTC (permalink / raw) To: Andreas Herrmann Cc: linux-kernel, Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner 2009/11/7 Dmitry Adamushko <dmitry.adamushko@gmail.com>: > 2009/11/6 Andreas Herrmann <herrmann.der.user@googlemail.com>: >> On Fri, Nov 06, 2009 at 01:56:31PM +0100, Dmitry Adamushko wrote: >>> 2009/11/6 Andreas Herrmann <herrmann.der.user@googlemail.com>: >> >> <snip> >> >>> >> (CPU3 belongs to both sets) unless summarize_cpu_info() is utterly >>> >> broken. >>> > >>> > I didn't check that yet. >>> >>> Yeah, this behavior is likely due to a missing cpumask_clear() in >>> summarize_cpu_info(). >> >> Yeah, that fixes the wrong messages. >> The other problem of not-updated CPU microcode after suspend/resume persists. >> >>> should be as follows: >>> >>> if (!alloc_cpumask_var(&cpulist, GFP_KERNEL)) >>> return; >>> >>> + cpumask_clear(cpulist); >> >> Better use zalloc_cpumask instead of alloc/clear. > > ok. > >> >>> >> sure, my test is somewhat limited... anyway, first of all I'd like to >>> >> get a clear understanding of your logs. Thanks for yout test btw. :-)) >>> > >>> > I'll send you full logs asap. >>> >>> Thanks. Maybe it's something about a particular sequence of actions >>> that triggers this behavior. Or was it reproducible with the very >>> first pm-suspend invocation after "modprobe microcode.ko"? >> >> The sequence is: >> >> 1. loading microcode.ko >> 2. setting cpu2 offline >> 3. setting cpu2 online >> 4. suspend (pm-suspend) >> 5. resume >> >> microcode of CPU2 is not updated: >> >> # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done >> PATCH_LEVEL = 0x0000000001000083 >> PATCH_LEVEL = 0x0000000001000083 >> PATCH_LEVEL = 0x0000000001000065 >> PATCH_LEVEL = 0x0000000001000083 >> >> dmesg attached. > > It looks like the microcode of CPU2 was not updated at step (3) [ and > not cached in uci->mc so that there was nothing to be loaded at resume > time later on ]. > > ... > platform microcode: firmware: requesting amd-ucode/microcode_amd.bin > microcode: size 1936, total_size 960 > microcode: CPU2: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022) > microcode: size 968, total_size 960 > PM: Syncing filesystems ... done. > ... > > These messages are from ->request_microcode_fw() but then there is > nothing from ->apply_microcode(). I'd expect to see "microcode: CPU%d: > updated (new patch_level=0x%x)". > > So either request_fw() -> generic_load_microcode() somehow fails to > find/cache a ucode (while it could do this at microcode-load time) or > apply_microcode_on_target() -> smp_call_function_single() fails in > this context. I made a test (some changes to load a cached ->mc at > cpu-online time) to verify the latter hypothesis and it didn't reveal > any problems or it requires some special conditions (also my kernel is > -rc5+). Andreas, any progress with this issue? You mentioned that the problem is also reproducible without my patches, right? --Dmitry ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-11 16:07 ` Dmitry Adamushko @ 2009-11-11 19:38 ` Andreas Herrmann 2009-11-12 11:33 ` Ingo Molnar 0 siblings, 1 reply; 18+ messages in thread From: Andreas Herrmann @ 2009-11-11 19:38 UTC (permalink / raw) To: Dmitry Adamushko Cc: linux-kernel, Ingo Molnar, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner On Wed, Nov 11, 2009 at 05:07:22PM +0100, Dmitry Adamushko wrote: > Andreas, > > > any progress with this issue? Yes > You mentioned that the problem is also reproducible without my > patches, right? ... and yes. Fixed with http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=9f15226e75583547aaf542c6be4bdac1060dd425 Andreas ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-11 19:38 ` Andreas Herrmann @ 2009-11-12 11:33 ` Ingo Molnar 2009-11-12 11:54 ` Dmitry Adamushko 2009-11-17 7:06 ` [PATCH] x86, ucode-amd: Move family check to microcde_amd.c's init function Andreas Herrmann 0 siblings, 2 replies; 18+ messages in thread From: Ingo Molnar @ 2009-11-12 11:33 UTC (permalink / raw) To: Andreas Herrmann Cc: Dmitry Adamushko, linux-kernel, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner -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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 61.459116] initcall microcode_init+0x0/0x137 returned 0 after 58625622 usecs Where does this delay come from? Ingo ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-12 11:33 ` Ingo Molnar @ 2009-11-12 11:54 ` Dmitry Adamushko 2009-11-12 12:06 ` Dmitry Adamushko 2009-11-17 7:06 ` [PATCH] x86, ucode-amd: Move family check to microcde_amd.c's init function Andreas Herrmann 1 sibling, 1 reply; 18+ messages in thread From: Dmitry Adamushko @ 2009-11-12 11:54 UTC (permalink / raw) To: Ingo Molnar Cc: Andreas Herrmann, linux-kernel, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner 2009/11/12 Ingo Molnar <mingo@elte.hu>: > > -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 <tigran@aivazian.fsnet.co.uk>, 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. If so, copying the following block from microcode_cpu_init() into init_microcode_amd() will help. /* Trigger a delayed update? */ if (system_state != SYSTEM_RUNNING) return UCODE_NFOUND; > > Ingo > -- Dmitry ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-12 11:54 ` Dmitry Adamushko @ 2009-11-12 12:06 ` Dmitry Adamushko 2009-11-12 15:20 ` Andreas Herrmann 0 siblings, 1 reply; 18+ messages in thread From: Dmitry Adamushko @ 2009-11-12 12:06 UTC (permalink / raw) To: Ingo Molnar Cc: Andreas Herrmann, linux-kernel, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner 2009/11/12 Dmitry Adamushko <dmitry.adamushko@gmail.com>: > 2009/11/12 Ingo Molnar <mingo@elte.hu>: >> >> -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 <tigran@aivazian.fsnet.co.uk>, 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(). -- Dmitry ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-12 12:06 ` Dmitry Adamushko @ 2009-11-12 15:20 ` Andreas Herrmann 2009-11-12 15:48 ` Dmitry Adamushko 0 siblings, 1 reply; 18+ messages in thread From: Andreas Herrmann @ 2009-11-12 15:20 UTC (permalink / raw) To: Dmitry Adamushko Cc: Ingo Molnar, linux-kernel, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner On Thu, Nov 12, 2009 at 01:06:36PM +0100, Dmitry Adamushko wrote: > 2009/11/12 Dmitry Adamushko <dmitry.adamushko@gmail.com>: > > 2009/11/12 Ingo Molnar <mingo@elte.hu>: > >> > >> -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 <tigran@aivazian.fsnet.co.uk>, 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. I think I should ensure that microcode_amd.c is compiled into microcode.o if and only if its built as module. microcode_amd.c supports only the firmware interface. Thus I suggest to add below. Regards, Andreas ---- >From 99cd1e170a30ea81164fd13333a5e5bb9587e4e8 Mon Sep 17 00:00:00 2001 From: Andreas Herrmann <andreas.herrmann3@amd.com> Date: Thu, 12 Nov 2009 16:08:38 +0100 Subject: [PATCH] x86, ucode-amd: Provide it only if microcode is compiled as module microcode_amd.c supports only the firmware interface. Thus it depends on the udev firmware helper. As we won't compile the micorode patches into the kernel it also doesn't make sense to compile microcode_amd.c into kernel. This also ensures that loading an updated AMD microcode patch container file is always possible via Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> --- arch/x86/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 17abcfa..0559ca3 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -959,7 +959,7 @@ config MICROCODE_INTEL config MICROCODE_AMD bool "AMD microcode patch loading support" - depends on MICROCODE + depends on MICROCODE=m select FW_LOADER ---help--- If you select this option, microcode patch loading support for AMD -- 1.6.5.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-12 15:20 ` Andreas Herrmann @ 2009-11-12 15:48 ` Dmitry Adamushko 2009-11-12 17:09 ` Borislav Petkov 0 siblings, 1 reply; 18+ messages in thread From: Dmitry Adamushko @ 2009-11-12 15:48 UTC (permalink / raw) To: Andreas Herrmann Cc: Ingo Molnar, linux-kernel, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner 2009/11/12 Andreas Herrmann <herrmann.der.user@googlemail.com>: > On Thu, Nov 12, 2009 at 01:06:36PM +0100, Dmitry Adamushko wrote: >> 2009/11/12 Dmitry Adamushko <dmitry.adamushko@gmail.com>: >> > 2009/11/12 Ingo Molnar <mingo@elte.hu>: >> >> >> >> -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 <tigran@aivazian.fsnet.co.uk>, 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages 2009-11-12 15:48 ` Dmitry Adamushko @ 2009-11-12 17:09 ` Borislav Petkov 0 siblings, 0 replies; 18+ messages in thread From: Borislav Petkov @ 2009-11-12 17:09 UTC (permalink / raw) To: Dmitry Adamushko Cc: Andreas Herrmann, Ingo Molnar, linux-kernel, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Andreas Mohr, Jack Steiner On Thu, Nov 12, 2009 at 04:48:34PM +0100, Dmitry Adamushko wrote: > 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. I don't think built-in blobs is the way we want to go here - in that case updating the microcode would require rebuilding the kernel, which is a clear overkill and exactly the opposite of what we should be doing. Imagine a big supercomputer consisting of several thousand nodes, all with identical CPUs. Now, everytime there's microcode patch available, you have to reboot all those machines after having distributed the updated kernel images just so that all nodes have their microcode updated. Many admins would go: "Hmm, no!" What actually got somehow dropped from Andreas' patch and which we talked about and agreed upon earlier is that the best thing to do would be to do $ rmmod microcode $ modprobe microcode after having copied the new ucode patch to /lib/firmware without disturbing the machine execution. The async _nowait() version sounds good but in that case you're still going to need to trigger the microcode update somehow (and AFAIK there's no mechanism for that yet.) So reloading the module is the easiest thing and it doesn't need any code changes except the Kconfig oneliner. Hmm... -- Regards/Gruss, Boris. Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] x86, ucode-amd: Move family check to microcde_amd.c's init function 2009-11-12 11:33 ` Ingo Molnar 2009-11-12 11:54 ` Dmitry Adamushko @ 2009-11-17 7:06 ` Andreas Herrmann 2009-11-17 9:24 ` [tip:x86/microcode] x86: " tip-bot for Andreas Herrmann 1 sibling, 1 reply; 18+ messages in thread From: Andreas Herrmann @ 2009-11-17 7:06 UTC (permalink / raw) To: Ingo Molnar Cc: Dmitry Adamushko, linux-kernel, H. Peter Anvin, Mike Travis, Tigran Aivazian, Thomas Gleixner, Borislav Petkov, Andreas Mohr, Jack Steiner ... to avoid useless trial to load firmware on systems with unsupported AMD CPUs. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> --- arch/x86/kernel/microcode_amd.c | 21 +++++++++++++++------ 1 files changed, 15 insertions(+), 6 deletions(-) Patch is against tip/master. Regards, Andreas diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c index 26e33bd..d0bb5ad 100644 --- a/arch/x86/kernel/microcode_amd.c +++ b/arch/x86/kernel/microcode_amd.c @@ -34,6 +34,7 @@ MODULE_LICENSE("GPL v2"); #define UCODE_UCODE_TYPE 0x00000001 const struct firmware *firmware; +static int supported_cpu; struct equiv_cpu_entry { u32 installed_cpu; @@ -73,15 +74,12 @@ static struct equiv_cpu_entry *equiv_cpu_table; static int collect_cpu_info_amd(int cpu, struct cpu_signature *csig) { - struct cpuinfo_x86 *c = &cpu_data(cpu); u32 dummy; - memset(csig, 0, sizeof(*csig)); - if (c->x86_vendor != X86_VENDOR_AMD || c->x86 < 0x10) { - pr_warning("microcode: CPU%d: AMD CPU family 0x%x not " - "supported\n", cpu, c->x86); + if (!supported_cpu) return -1; - } + + memset(csig, 0, sizeof(*csig)); rdmsr(MSR_AMD64_PATCH_LEVEL, csig->rev, dummy); pr_info("microcode: CPU%d: patch_level=0x%x\n", cpu, csig->rev); return 0; @@ -331,6 +329,17 @@ static void microcode_fini_cpu_amd(int cpu) void init_microcode_amd(struct device *device) { const char *fw_name = "amd-ucode/microcode_amd.bin"; + struct cpuinfo_x86 *c = &boot_cpu_data; + + BUG_ON(c->x86_vendor != X86_VENDOR_AMD); + + if (c->x86 < 0x10) { + pr_warning("microcode: AMD CPU family 0x%x not supported\n", + c->x86); + return; + } + supported_cpu = 1; + if (request_firmware(&firmware, fw_name, device)) pr_err("microcode: failed to load file %s\n", fw_name); } -- 1.6.5.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [tip:x86/microcode] x86: ucode-amd: Move family check to microcde_amd.c's init function 2009-11-17 7:06 ` [PATCH] x86, ucode-amd: Move family check to microcde_amd.c's init function Andreas Herrmann @ 2009-11-17 9:24 ` tip-bot for Andreas Herrmann 0 siblings, 0 replies; 18+ messages in thread From: tip-bot for Andreas Herrmann @ 2009-11-17 9:24 UTC (permalink / raw) To: linux-tip-commits Cc: linux-kernel, hpa, mingo, travis, andreas.herrmann3, tigran, steiner, dmitry.adamushko, herrmann.der.user, tglx, mingo, andi, borislav.petkov Commit-ID: 8cc2361bd00e87aab2827a3996a71fe9b2c9f9c4 Gitweb: http://git.kernel.org/tip/8cc2361bd00e87aab2827a3996a71fe9b2c9f9c4 Author: Andreas Herrmann <herrmann.der.user@googlemail.com> AuthorDate: Tue, 17 Nov 2009 08:06:38 +0100 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Tue, 17 Nov 2009 10:10:40 +0100 x86: ucode-amd: Move family check to microcde_amd.c's init function ... to avoid useless trial to load firmware on systems with unsupported AMD CPUs. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com> Cc: Mike Travis <travis@sgi.com> Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: Andreas Mohr <andi@lisas.de> Cc: Jack Steiner <steiner@sgi.com> LKML-Reference: <20091117070638.GA27691@alberich.amd.com> [ v2: changed BUG_ON() to WARN_ON() ] Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/kernel/microcode_amd.c | 21 +++++++++++++++------ 1 files changed, 15 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c index 26e33bd..63123d9 100644 --- a/arch/x86/kernel/microcode_amd.c +++ b/arch/x86/kernel/microcode_amd.c @@ -34,6 +34,7 @@ MODULE_LICENSE("GPL v2"); #define UCODE_UCODE_TYPE 0x00000001 const struct firmware *firmware; +static int supported_cpu; struct equiv_cpu_entry { u32 installed_cpu; @@ -73,15 +74,12 @@ static struct equiv_cpu_entry *equiv_cpu_table; static int collect_cpu_info_amd(int cpu, struct cpu_signature *csig) { - struct cpuinfo_x86 *c = &cpu_data(cpu); u32 dummy; - memset(csig, 0, sizeof(*csig)); - if (c->x86_vendor != X86_VENDOR_AMD || c->x86 < 0x10) { - pr_warning("microcode: CPU%d: AMD CPU family 0x%x not " - "supported\n", cpu, c->x86); + if (!supported_cpu) return -1; - } + + memset(csig, 0, sizeof(*csig)); rdmsr(MSR_AMD64_PATCH_LEVEL, csig->rev, dummy); pr_info("microcode: CPU%d: patch_level=0x%x\n", cpu, csig->rev); return 0; @@ -331,6 +329,17 @@ static void microcode_fini_cpu_amd(int cpu) void init_microcode_amd(struct device *device) { const char *fw_name = "amd-ucode/microcode_amd.bin"; + struct cpuinfo_x86 *c = &boot_cpu_data; + + WARN_ON(c->x86_vendor != X86_VENDOR_AMD); + + if (c->x86 < 0x10) { + pr_warning("microcode: AMD CPU family 0x%x not supported\n", + c->x86); + return; + } + supported_cpu = 1; + if (request_firmware(&firmware, fw_name, device)) pr_err("microcode: failed to load file %s\n", fw_name); } ^ permalink raw reply related [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-11-17 9:25 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-11-02 20:08 [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages dimm 2009-11-04 12:27 ` Ingo Molnar 2009-11-05 15:37 ` Andreas Herrmann 2009-11-05 18:40 ` Dmitry Adamushko 2009-11-06 12:34 ` Andreas Herrmann 2009-11-06 12:56 ` Dmitry Adamushko 2009-11-06 19:46 ` Andreas Herrmann 2009-11-07 12:22 ` Dmitry Adamushko 2009-11-11 16:07 ` Dmitry Adamushko 2009-11-11 19:38 ` Andreas Herrmann 2009-11-12 11:33 ` Ingo Molnar 2009-11-12 11:54 ` Dmitry Adamushko 2009-11-12 12:06 ` Dmitry Adamushko 2009-11-12 15:20 ` Andreas Herrmann 2009-11-12 15:48 ` Dmitry Adamushko 2009-11-12 17:09 ` Borislav Petkov 2009-11-17 7:06 ` [PATCH] x86, ucode-amd: Move family check to microcde_amd.c's init function Andreas Herrmann 2009-11-17 9:24 ` [tip:x86/microcode] x86: " tip-bot for Andreas Herrmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox