lkml.org 
[lkml]   [2018]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 03/16] x86/mtrr: get MTRR number and support TOP_MEM2
On Tue, Sep 04, 2018 at 11:02:41AM +0800, Pu Wen wrote:
> > > - if (!((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
> > > - (boot_cpu_data.x86 >= 0x0f)))
> > > + if (!((boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
> > > + boot_cpu_data.x86 >= 0x0f) ||
> > > + boot_cpu_data.x86_vendor == X86_VENDOR_HYGON))
> >
> > Why are you even touching this statement? The function returns early on
> > !X86_VENDOR_AMD.
>
> The statement is briefly equal to !(X86_VENDOR_AMD || X86_VENDOR_HYGON).
> So the function will not return early on !X86_VENDOR_AMD. :-)

I meant the *original* version - not yours!

My question is why are you even touching a K8-old BIOS workaround?! Your
commit message says:

The MtrrFixDramModEn bit on Hygon platform should also be set to 1
during BIOS initialization of the fixed MTRRs, then cleared to 0 for
operation.

Is your BIOS already broken?

Searching the net for

pr_err(FW_WARN "MTRR: CPU %u: SYSCFG[MtrrFixDramModEn]"
" not cleared by BIOS, clearing this bit\n",

shows only old mails so I'm going to assume this got fixed, finally! And
you probably have received a *fixed* BIOS even, allegedly.

So what's up?

--
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

\
 
 \ /
  Last update: 2018-09-04 10:04    [W:0.054 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site