Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
- From: "H. Peter Anvin" <hpa@xxxxxxxxx>
- Date: Wed, 19 Dec 2012 14:59:07 -0800
- Cc: Jacob Shin <jacob.shin@xxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxxxxxxxx>, "Yu, Fenghua" <fenghua.yu@xxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>, "linux-tip-commits@xxxxxxxxxxxxxxx" <linux-tip-commits@xxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
- In-reply-to: <CAE9FiQWbyA4BgNFsxipdn=Mgc5c5tdSKzwbP_0nvs8BTqR0QUQ@mail.gmail.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
On 12/19/2012 02:47 PM, Yinghai Lu wrote:
>
> on demand to only map 2M will help ?
> or have to return to v6 version for-x86-boot ?
>
Why would 2M be inherently better than 1G? I realize it works for the
*one particular system* that you have a specimen for, but that is not a
sensible approach for architecture.
The problem remains no matter how you slice it; we need a general
solution. The fact that this system was ever built reflects a number of
critical failures that should be surprising but sadly are not.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]
