On Fri, Nov 06, 2009 at 01:56:31PM +0100, Dmitry Adamushko wrote: > 2009/11/6 Andreas Herrmann : > >> (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.