From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756906AbbFCP17 (ORCPT ); Wed, 3 Jun 2015 11:27:59 -0400 Received: from mga14.intel.com ([192.55.52.115]:29633 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753892AbbFCP1u (ORCPT ); Wed, 3 Jun 2015 11:27:50 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,547,1427785200"; d="scan'208";a="736401623" Message-ID: <1433345266.26331.57.camel@linux.intel.com> Subject: Re: [PATCH 1/1] x86/microcode: vsnprintf() might be unavailable From: Andy Shevchenko To: Borislav Petkov Cc: Andy Shevchenko , Ingo Molnar , "linux-kernel@vger.kernel.org" , Mika Westerberg Date: Wed, 03 Jun 2015 18:27:46 +0300 In-Reply-To: <20150603105640.GA4706@pd.tnic> References: <1433257003-159485-1-git-send-email-andriy.shevchenko@linux.intel.com> <20150602162403.GD20576@pd.tnic> <1433263793.26331.42.camel@linux.intel.com> <20150602170040.GE20576@pd.tnic> <20150603105640.GA4706@pd.tnic> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2015-06-03 at 12:56 +0200, Borislav Petkov wrote: > On Tue, Jun 02, 2015 at 08:31:58PM +0300, Andy Shevchenko wrote: > > Ditto. > > "Ditto" means it doesn't work booting a normal 32-bit kernel too? Ditto, meant to test when I will be at work again :-) But, unfortunately it doesn't. I did two images of next-20150602 with and without this patch and 100% success and failure respectively (do each test twice). I have tested with 32-bit kernel run as EFI 32 binary from EFI Shell on ASuS T100TA (Intel BayTrail-T): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 55 model name : Intel(R) Atom(TM) CPU Z3740 @ 1.33GHz stepping : 3 microcode : 0x31e cpu MHz : 1330.000 > > I have a totally empty screen (serial console). So, if you teach me > > how to gather that I could do it later on. > > That'll be hard - you'd probably need a hardware debugger or something > special to get a RIP or other data that early... Or hack up some very > early console printing with BIOS methods and so on. hpa had something > like that somewhere AFAIR... I could try kvm / qemu as well, though there might be not the same conditions. > > I can send our defconfig and kexec command line for sure. > > Yes please. Here is the difference to the i386_defconfig as in next-20150602: diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index aaa1118..7579120 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -204,7 +204,7 @@ CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y CONFIG_HW_RANDOM=y CONFIG_NVRAM=y -CONFIG_HPET=y +# CONFIG_HPET is not set # CONFIG_HPET_MMAP is not set CONFIG_I2C_I801=y CONFIG_WATCHDOG=y @@ -212,7 +212,8 @@ CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_DRM=y -CONFIG_DRM_I915=y +# CONFIG_DRM_I915 is not set +CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_EFI=y @@ -229,8 +230,8 @@ CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=y -CONFIG_SND_HDA_INTEL=y -CONFIG_SND_HDA_HWDEP=y +# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_HDA_HWDEP is not set CONFIG_HIDRAW=y CONFIG_HID_GYRATION=y CONFIG_LOGITECH_FF=y @@ -310,3 +311,55 @@ CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_CRYPTO_AES_586=y # CONFIG_CRYPTO_ANSI_CPRNG is not set +CONFIG_FUNCTION_TRACER=y +CONFIG_I2C_DESIGNWARE_PCI=y +CONFIG_I2C_DESIGNWARE_PLATFORM=m +CONFIG_GPIOLIB=y +CONFIG_GPIO_INTEL_MID=y +CONFIG_INTEL_MID_WATCHDOG=y +CONFIG_NOP_USB_XCEIV=y +CONFIG_USB_CHIPIDEA=y +CONFIG_USB_CHIPIDEA_UDC=y +CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_X86_EXTENDED_PLATFORM=y +CONFIG_X86_INTEL_MID=y +CONFIG_EFI_STUB=y +CONFIG_EARLY_PRINTK_EFI=y +CONFIG_FB=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_DYNAMIC_DEBUG=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GADGET=y +CONFIG_USB_SERIAL=y +CONFIG_USB_SERIAL_PL2303=y +CONFIG_USB_USBNET=y +CONFIG_USB_NET_AX88179_178A=y +CONFIG_USB_NET_MCS7830=y +CONFIG_USB_NET_AX8817X=y +CONFIG_X86_INTEL_LPSS=y +CONFIG_PM_RUNTIME=y +CONFIG_DW_DMAC_CORE=m +CONFIG_DW_DMAC=m +CONFIG_DW_DMAC_PCI=m +CONFIG_DMATEST=m +CONFIG_SERIAL_8250_DMA=y +CONFIG_SERIAL_8250_PCI=y +CONFIG_SERIAL_8250_DW=m +CONFIG_MMC=m +CONFIG_MMC_SDHCI=m +CONFIG_MMC_SDHCI_ACPI=m +CONFIG_ACPI_DEBUG=y +CONFIG_ACPI_PROCFS_POWER=y +CONFIG_DMA_API_DEBUG=y +CONFIG_DEBUG_LOCKDEP=y +CONFIG_DEBUG_SHIRQ=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_BAYTRAIL=y +CONFIG_PWM=y +CONFIG_PWM_LPSS=m +CONFIG_PWM_LPSS_PCI=m +CONFIG_PWM_LPSS_PLATFORM=m +CONFIG_SPI=y +CONFIG_SPI_PXA2XX_PCI=m +CONFIG_SPI_PXA2XX=m kexec command: kexec -l $bootdir/vmlinuz --initrd $bootdir/initrd --command-line="$cmdline" cmdline (in case of kexec the acpi_rdsp=0xdeadbeaf is added, 0xdeadbeaf not an actual address): console=tty1 console=ttyS0,115200n8 ignore_loglevel spidev.bufsiz=8192 P.S. I could test any configuration you suppose if it's needed. -- Andy Shevchenko Intel Finland Oy