Messages in this thread | | | Date | Tue, 2 Jun 2015 20:31:58 +0300 | Subject | Re: [PATCH 1/1] x86/microcode: vsnprintf() might be unavailable | From | Andy Shevchenko <> |
| |
On Tue, Jun 2, 2015 at 8:00 PM, Borislav Petkov <bp@suse.de> wrote: > On Tue, Jun 02, 2015 at 07:49:53PM +0300, Andy Shevchenko wrote: >> Initial paging setup is involved? > > Yes, load_ucode_bsp happens before paging is enabled on 32-bit. And > that should remain that way - we want microcode application as early as > possible. > >> Hmm… which Intel CPUs you run on? > > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 58 > model name : Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz > stepping : 9 > microcode : 0x1b > > and an SNB one too.
Now at home already. Will check tomorrow what we have.
> >> Ah, one more thing we run our kernel from kexec (I hope it's not a >> case, but who knows). > > Does it work when you boot a normal 32-bit kernel with builtin microcode > on it?
Ditto.
> > In order to load built-in microcode, you'll have to enable the boot > options in the commit message to > > 760d765b2bb6 ("x86/microcode: Parse built-in microcode early") > > Let me know if something's not clear.
We are using slightly different (to upstream) i386_defconfig with some devices enabled like serial console. As environment the Buildroot is used with uclibc and busybox. No extra microcode is enabled.
By default as far as I remember the FIRMWARE* is set to y for all options.
> On Tue, Jun 02, 2015 at 07:46:29PM +0300, Andy Shevchenko wrote: >> > @@ -533,7 +533,12 @@ static bool __init load_builtin_intel_microcode(struct cpio_data *cp) >> > model = x86_model(eax); >> > stepping = eax & 0xf; >> > >> > - sprintf(name, "intel-ucode/%02x-%02x-%02x", family, model, stepping); >> > + *p++ = '/'; >> > + p = hex_byte_pack(p, family); >> > + *p++ = '-'; >> > + p = hex_byte_pack(p, model); >> > + *p++ = '-'; >> > + p = hex_byte_pack(p, stepping); >> > >> >> Forgot to add *p = '\0'; here, but it doesn't really mater for the idea. >> >> What I would like to tell that if I move 'call load_ucode_bsp' after >> paging is done, it seems sprintf() starts working nicely. > > Hmm, ok, so something's not able to stomach pre-paging. Can you dump > something from the failure, RIP, stack, whatever?
I have a totally empty screen (serial console). So, if you teach me how to gather that I could do it later on.
> > Can I reproduce it?
I can send our defconfig and kexec command line for sure.
[]
>> and wondering if we need to fix AMD part. > > No need, AFAICT. It did work in my testing.
Ok. We have no AMD here :-)
-- With Best Regards, Andy Shevchenko
| |