Re: 3.2-rc2 freezes on boot for AMD K6 - bisected to commit bcb80e53877c2045d9e52f4a71372c3fe6501f6f

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, Dec 3, 2011 at 12:43 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > On 11/30/2011 01:09 AM, Larry Finger wrote:
> >> On 11/29/2011 11:59 PM, Srivatsa S. Bhat wrote:
> >>>
> >>> Can you please try out the patch posted in
> >>> https://lkml.org/lkml/2011/11/28/178 ?
> 
> Ugh. I hate that patch.
> 
> It's completely stupid. If "rdmsr_safe()" doesn't work at that point
> in the boot, then it's pointless to call it.
> 
> So this change is pure and utter crap:
> 
>   -	rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
>   +	if (c->x86 >= 0xf)
>   +		rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
> 
> because it is misleading as hell: that rdmsr isn't *safe* at all, so
> why are we calling "rdmsr_safe()"?

Yeah.

> It's wrong.
> 
> The right patch would either just remove the "safe" part (and 
> just say that the register has to be supported if c->x86 >= 
> 0xf), but quite honestly, I don't see why we do that thing in 
> early_init_amd() AT ALL. Afaik, the microcode version field 
> isn't really *needed* by the kernelin the first place, much 
> less is it needed by the *early* boot, so why isn't this in 
> 'init_amd()' a bit later when the "safe" version actually 
> *works*?
> 
> IOW, I think the patch should be something like the attached 
> (TOTALLY UNTESTED) patch. Larry, does this work for you? It 
> just moves the rdmsr_safe() to the later function.

Looks sane to me.

We can improve the early init properties some more - but there's 
always going to be a chicken-and-egg problem there. At minimum 
we should add a comment to rdmsr_safe() that explains its 
dependencies.

Thanks,

	Ingo