Re: early microcode on amd is broken when no initramfs provided
On Sun, 21 Jul 2013 00:59:11 +0200
Borislav Petkov wrote:
> On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote:
> > On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov
> > wrote:
> > > On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
> > >> config is attached
> > >
> > > Ok, I can reproduce the hang with your config but even with:
> > >
> > > $ grep MICROCODE .config
> > > # CONFIG_MICROCODE is not set
> > > # CONFIG_MICROCODE_INTEL_EARLY is not set
> > > # CONFIG_MICROCODE_AMD_EARLY is not set
> > >
> > > which means, it cannot be microcode-related.
> > >
> > > And I'd bet if you wait a minute (yep, it should be exactly 60
> > > seconds) the boot would probably continue. And if so, this is
> > > that 60 sec delay where the kernel tries to find firmware.
> > >
> > > Hmm...
> >
> > I have the same problem: Booting 3.11-rc1 hangs after the line:
> > ACPI: Executed 3 blocks of module-level executable AML code
> >
> > I bisected it down to the early microcode changes:
> > 757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading
> > implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small
> > fixup) completely fail to boot (No output beyond "Booting kernel") ,
> > from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 ("Make
> > find_ucode_in_initrd() __init") I'm seeing this hang.
> >
> > Just turning CONFIG_MICROCODE_EARLY off solves the problem: The
> > system now sucessfully boots 3.11-rc1.
>
> Ok, I need to be able to reproduce that first - I wasn't that
> successful with Johannes' setup.
Strange, I've bisected to the same commit with the config I've send you.
> So, can you please send .config and how you're loading your microcode?
> Is it in the initrd or are you doing that later, how? Grub entry
> please.
>
> Also, is it just plain v3.11-rc1 or with patches ontop?
>
> Also, /proc/cpuinfo please.
>
> Thanks.
/proc/cpuinfo:
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 6
model name : AMD Athlon(tm) II P320 Dual-Core Processor
stepping: 3
microcode : 0x1b6
cpu MHz : 800.000
cache size : 512 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl
nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm
extapic cr8_legacy abm sse4a 3dnowprefetch osvw ibs skinit wdt
nodeid_msr hw_pstate npt lbrv svm_lock nrip_save bogomips:
4189.33 TLB size: 1024 4K pages clflush size: 64
cache_alignment : 64 address sizes : 48 bits physical, 48 bits
virtual power management: ts ttp tm stc 100mhzsteps hwpstate
processor : 1
vendor_id : AuthenticAMD
cpu family : 16
model : 6
model name : AMD Athlon(tm) II P320 Dual-Core Processor
stepping: 3
microcode : 0x1b6
cpu MHz : 800.000
cache size : 512 KB
physical id : 0
siblings: 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl
nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm
extapic cr8_legacy abm sse4a 3dnowprefetch osvw ibs skinit wdt
nodeid_msr hw_pstate npt lbrv svm_lock nrip_save bogomips:
4189.33 TLB size: 1024 4K pages clflush size: 64
cache_alignment : 64 address sizes : 48 bits physical, 48 bits
virtual power management: ts ttp tm stc 100mhzsteps hwpstate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Sun, 21 Jul 2013 00:59:11 +0200 Borislav Petkov b...@alien8.de wrote: On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote: On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov b...@alien8.de wrote: On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote: config is attached Ok, I can reproduce the hang with your config but even with: $ grep MICROCODE .config # CONFIG_MICROCODE is not set # CONFIG_MICROCODE_INTEL_EARLY is not set # CONFIG_MICROCODE_AMD_EARLY is not set which means, it cannot be microcode-related. And I'd bet if you wait a minute (yep, it should be exactly 60 seconds) the boot would probably continue. And if so, this is that 60 sec delay where the kernel tries to find firmware. Hmm... I have the same problem: Booting 3.11-rc1 hangs after the line: ACPI: Executed 3 blocks of module-level executable AML code I bisected it down to the early microcode changes: 757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small fixup) completely fail to boot (No output beyond Booting kernel) , from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 (Make find_ucode_in_initrd() __init) I'm seeing this hang. Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system now sucessfully boots 3.11-rc1. Ok, I need to be able to reproduce that first - I wasn't that successful with Johannes' setup. Strange, I've bisected to the same commit with the config I've send you. So, can you please send .config and how you're loading your microcode? Is it in the initrd or are you doing that later, how? Grub entry please. Also, is it just plain v3.11-rc1 or with patches ontop? Also, /proc/cpuinfo please. Thanks. /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Athlon(tm) II P320 Dual-Core Processor stepping: 3 microcode : 0x1b6 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save bogomips: 4189.33 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Athlon(tm) II P320 Dual-Core Processor stepping: 3 microcode : 0x1b6 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save bogomips: 4189.33 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Sun, Jul 21, 2013 at 12:59 AM, Borislav Petkov wrote:
> On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote:
>> On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov wrote:
>> > On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
>> >> config is attached
>> >
>> > Ok, I can reproduce the hang with your config but even with:
>> >
>> > $ grep MICROCODE .config
>> > # CONFIG_MICROCODE is not set
>> > # CONFIG_MICROCODE_INTEL_EARLY is not set
>> > # CONFIG_MICROCODE_AMD_EARLY is not set
>> >
>> > which means, it cannot be microcode-related.
>> >
>> > And I'd bet if you wait a minute (yep, it should be exactly 60 seconds)
>> > the boot would probably continue. And if so, this is that 60 sec delay
>> > where the kernel tries to find firmware.
>> >
>> > Hmm...
>>
>> I have the same problem: Booting 3.11-rc1 hangs after the line:
>> ACPI: Executed 3 blocks of module-level executable AML code
>>
>> I bisected it down to the early microcode changes:
>> 757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading
>> implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small
>> fixup) completely fail to boot (No output beyond "Booting kernel") ,
>> from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 ("Make
>> find_ucode_in_initrd() __init") I'm seeing this hang.
>>
>> Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system
>> now sucessfully boots 3.11-rc1.
>
> Ok, I need to be able to reproduce that first - I wasn't that successful
> with Johannes' setup.
>
> So, can you please send .config and how you're loading your microcode?
> Is it in the initrd or are you doing that later, how? Grub entry please.
>
> Also, is it just plain v3.11-rc1 or with patches ontop?
>
> Also, /proc/cpuinfo please.
.config and cpuinfo attached.
Microcode seems not to be loaded at all, for MICROCODE_EARLY I did not
attach the needed file / cpio and the normal update mechanism seems to
not have a newer microcode that what the BIOS is providing.
I'm using a custom initrd, but that can't be used for MICROCODE_EARLY
because its compressed and does not contain a AuthenticAMD.bin. Its
also not containing microcode_amd.bin, because I'm suppling that via
CONFIG_EXTRA_FIRMWARE.
Grub entry:
title 3.11.0-rc1-crypt
root (hd0,0)
kernel (hd0,0)/boot/kernel-3.11.0-rc1 fastboot crypt_root=/dev/md6
video=1280x1024 radeon.dpm=1
initrd (hd0,0)/boot/ramfs-2011.gz
savedefault
I was using plain 3.11-rc1 except the changes I made to debug this.
What I think you need: A system that is fatally affected by AMD
Erratum 400 and an 64bit kernel.
>From my debugging I found the following sequence of events occurs on my system:
The BSP will call load_ucode_ap().
That will call collect_cpu_info_amd_early(), which will fill the
cpuinfo_x86.x86 and cpuinfo_x86.microcode fields of the
cpu_info-per-cpu-structure that has not yet been setup. Because this
code will only be used with MICROCODE_EARLY disabling this options
make my system boot. OTOH this function is called regardless if
AuthenticAMD.bin is available or not, thats why I'm hitting it even
without the special cpio.
Then the BSP will call init_amd() to apply the errata fixes. That uses
cpu_has_amd_erratum(), but that function is not using the cpuinfo_x86
that was supplied to init_amd() (And used for the following
set_cpu_bug() is the erratum was found!), but instead is guessing
itself if it should use the per-cpu data or boot_cpu_data. And it uses
the not yet initialized per-cpu data for that guess. Which normally
works fine, because that will all be zeroed out, but
collect_cpu_info_amd_early() has filled ->x86 and so
cpu_has_amd_erratum() wil use the partly filled per-cpu data instead
of the correct boot_cpu_data. But because collect_cpu_info_amd_early()
did not fill ->x86_vendor that field is still 0 == X86_VENDOR_INTEL
and cpu_has_amd_erratum() will lie that no erratum is present.
So the C1E work around is not applied and as soon as ACPI enables this
the boot hangs.
Something like the following (whitespace mangled by Gmail, if it looks
OK for you, I will send it as a clean patch) fixes
cpu_has_amd_erratum() for me, but I did not look how the early
microcode loading should work if AuthenticAMD.bin is available to
offer a fix the premature accesses to per-cpu cpu_info.
--- 3.11-rc1/arch/x86/kernel/cpu/amd.c.orig 2013-07-21
05:42:42.130346496 +0200
+++ 3.11-rc1/arch/x86/kernel/cpu/amd.c 2013-07-21 05:45:09.420345843 +0200
@@ -512,7 +512,7 @@
static const int amd_erratum_383[];
static const int amd_erratum_400[];
-static bool cpu_has_amd_erratum(const int *erratum);
+static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);
static void __cpuinit init_amd(struct cpuinfo_x86 *c)
{
@@ -729,11 +729,11 @@
value &= ~(1ULL << 24);
wrmsrl_safe(MSR_AMD64_BU_CFG2, value);
- if (cpu_has_amd_erratum(amd_erratum_383))
+ if (cpu_has_amd_erratum(c, amd_erratum_383))
Re: early microcode on amd is broken when no initramfs provided
On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote:
> On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov wrote:
> > On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
> >> config is attached
> >
> > Ok, I can reproduce the hang with your config but even with:
> >
> > $ grep MICROCODE .config
> > # CONFIG_MICROCODE is not set
> > # CONFIG_MICROCODE_INTEL_EARLY is not set
> > # CONFIG_MICROCODE_AMD_EARLY is not set
> >
> > which means, it cannot be microcode-related.
> >
> > And I'd bet if you wait a minute (yep, it should be exactly 60 seconds)
> > the boot would probably continue. And if so, this is that 60 sec delay
> > where the kernel tries to find firmware.
> >
> > Hmm...
>
> I have the same problem: Booting 3.11-rc1 hangs after the line:
> ACPI: Executed 3 blocks of module-level executable AML code
>
> I bisected it down to the early microcode changes:
> 757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading
> implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small
> fixup) completely fail to boot (No output beyond "Booting kernel") ,
> from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 ("Make
> find_ucode_in_initrd() __init") I'm seeing this hang.
>
> Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system
> now sucessfully boots 3.11-rc1.
Ok, I need to be able to reproduce that first - I wasn't that successful
with Johannes' setup.
So, can you please send .config and how you're loading your microcode?
Is it in the initrd or are you doing that later, how? Grub entry please.
Also, is it just plain v3.11-rc1 or with patches ontop?
Also, /proc/cpuinfo please.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov wrote:
> On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
>> config is attached
>
> Ok, I can reproduce the hang with your config but even with:
>
> $ grep MICROCODE .config
> # CONFIG_MICROCODE is not set
> # CONFIG_MICROCODE_INTEL_EARLY is not set
> # CONFIG_MICROCODE_AMD_EARLY is not set
>
> which means, it cannot be microcode-related.
>
> And I'd bet if you wait a minute (yep, it should be exactly 60 seconds)
> the boot would probably continue. And if so, this is that 60 sec delay
> where the kernel tries to find firmware.
>
> Hmm...
I have the same problem: Booting 3.11-rc1 hangs after the line:
ACPI: Executed 3 blocks of module-level executable AML code
I bisected it down to the early microcode changes:
757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading
implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small
fixup) completely fail to boot (No output beyond "Booting kernel") ,
from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 ("Make
find_ucode_in_initrd() __init") I'm seeing this hang.
Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system
now sucessfully boots 3.11-rc1.
Trying to debug this I found the following hack to also solve the boot problem:
Removing the following two lines from collect_cpu_info_amd_early()
from arch/x86/kernel/microcode_amd_early.c:
c->microcode = rev;
c->x86 = ((eax >> 8) & 0xf) + ((eax >> 20) & 0xff);
But I can't make sense out of that. And if I try to trace who updates
->x86 it get even more confusing.
Normaly only cpu_detect() seems to update cpuinfo_x86.x86 but now it
seems to fight with collect_cpu_info_amd_early().
On my system this happens:
(Output is always address of the struct cpuinfo_x86 -> value that gets
written into it)
Very early boot:
cpu_detect 81c8ba40 -> 16
BSP == CPU0 calls load_ucode_ap() via cpu_init():
collect_cpu_info_amd_early 880337c10fc0 -> 16
(That is the place I patched out to get the system to boot)
BSP == CPU0 via identify_boot_cpu():
cpu_detect 81c8ba40 -> 16
BSP == CPU0 stores boot_cpu_data in its per-cpu structure via
smp_store_boot_cpu_info():
smpboot: BSP: store 81c8ba40 in 880337c10fc0
smpboot starts activating the secondary CPUs: Each would in
start_secondary() first call load_ucode_ap() via cpu_init() and then
identidfy_secondary_cpu() via smp_callin():
collect_cpu_info_amd_early 880337c50fc0
smpboot: identify_sec_cpu:1/880337c50fc0
cpu_detect 880337c50fc0 -> 16
collect_cpu_info_amd_early 880337c90fc0
smpboot: identify_sec_cpu:2/880337c90fc0
cpu_detect 880337c90fc0 -> 16
collect_cpu_info_amd_early 880337cd0fc0
smpboot: identify_sec_cpu:3/880337cd0fc0
cpu_detect 880337cd0fc0 -> 16
collect_cpu_info_amd_early 880337d10fc0
smpboot: identify_sec_cpu:4/880337d10fc0
cpu_detect 880337d10fc0 -> 16
collect_cpu_info_amd_early 880337d50fc0
smpboot: identify_sec_cpu:5/880337d50fc0
cpu_detect 880337d50fc0 -> 16
It seems the code for updating 'struct cpuinfo_x86 *C' in
collect_cpu_info_amd_early() is useless, because it will be
overwritten first by smp_store_cpu_info() and then again by
identify_secondary_cpu(c) and wrong, because at that point the per-cpu
structure should not be used yet, as smp_store_cpu_info() did not run
yet.
But something else seems to be using the per-cpu structure of the BSP
between its cpu_init() and smp_store_boot_cpu_info().
And its cpu_has_amd_erratum(): It uses cpuinfo_x86.x86 do decide if it
need to fall back to boot_cpu_data, but because
collect_cpu_info_amd_early() has filled that field, but not
.x86_vendor (that is still 0 == X86_VENDOR_INTEL) the erratas are not
applied to the BSP and then something in ACPI gets stuck.
Does this diagnostic make sense / should I send a patch?
Torsten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov b...@alien8.de wrote: On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote: config is attached Ok, I can reproduce the hang with your config but even with: $ grep MICROCODE .config # CONFIG_MICROCODE is not set # CONFIG_MICROCODE_INTEL_EARLY is not set # CONFIG_MICROCODE_AMD_EARLY is not set which means, it cannot be microcode-related. And I'd bet if you wait a minute (yep, it should be exactly 60 seconds) the boot would probably continue. And if so, this is that 60 sec delay where the kernel tries to find firmware. Hmm... I have the same problem: Booting 3.11-rc1 hangs after the line: ACPI: Executed 3 blocks of module-level executable AML code I bisected it down to the early microcode changes: 757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small fixup) completely fail to boot (No output beyond Booting kernel) , from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 (Make find_ucode_in_initrd() __init) I'm seeing this hang. Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system now sucessfully boots 3.11-rc1. Trying to debug this I found the following hack to also solve the boot problem: Removing the following two lines from collect_cpu_info_amd_early() from arch/x86/kernel/microcode_amd_early.c: c-microcode = rev; c-x86 = ((eax 8) 0xf) + ((eax 20) 0xff); But I can't make sense out of that. And if I try to trace who updates -x86 it get even more confusing. Normaly only cpu_detect() seems to update cpuinfo_x86.x86 but now it seems to fight with collect_cpu_info_amd_early(). On my system this happens: (Output is always address of the struct cpuinfo_x86 - value that gets written into it) Very early boot: cpu_detect 81c8ba40 - 16 BSP == CPU0 calls load_ucode_ap() via cpu_init(): collect_cpu_info_amd_early 880337c10fc0 - 16 (That is the place I patched out to get the system to boot) BSP == CPU0 via identify_boot_cpu(): cpu_detect 81c8ba40 - 16 BSP == CPU0 stores boot_cpu_data in its per-cpu structure via smp_store_boot_cpu_info(): smpboot: BSP: store 81c8ba40 in 880337c10fc0 smpboot starts activating the secondary CPUs: Each would in start_secondary() first call load_ucode_ap() via cpu_init() and then identidfy_secondary_cpu() via smp_callin(): collect_cpu_info_amd_early 880337c50fc0 smpboot: identify_sec_cpu:1/880337c50fc0 cpu_detect 880337c50fc0 - 16 collect_cpu_info_amd_early 880337c90fc0 smpboot: identify_sec_cpu:2/880337c90fc0 cpu_detect 880337c90fc0 - 16 collect_cpu_info_amd_early 880337cd0fc0 smpboot: identify_sec_cpu:3/880337cd0fc0 cpu_detect 880337cd0fc0 - 16 collect_cpu_info_amd_early 880337d10fc0 smpboot: identify_sec_cpu:4/880337d10fc0 cpu_detect 880337d10fc0 - 16 collect_cpu_info_amd_early 880337d50fc0 smpboot: identify_sec_cpu:5/880337d50fc0 cpu_detect 880337d50fc0 - 16 It seems the code for updating 'struct cpuinfo_x86 *C' in collect_cpu_info_amd_early() is useless, because it will be overwritten first by smp_store_cpu_info() and then again by identify_secondary_cpu(c) and wrong, because at that point the per-cpu structure should not be used yet, as smp_store_cpu_info() did not run yet. But something else seems to be using the per-cpu structure of the BSP between its cpu_init() and smp_store_boot_cpu_info(). And its cpu_has_amd_erratum(): It uses cpuinfo_x86.x86 do decide if it need to fall back to boot_cpu_data, but because collect_cpu_info_amd_early() has filled that field, but not .x86_vendor (that is still 0 == X86_VENDOR_INTEL) the erratas are not applied to the BSP and then something in ACPI gets stuck. Does this diagnostic make sense / should I send a patch? Torsten -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote: On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov b...@alien8.de wrote: On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote: config is attached Ok, I can reproduce the hang with your config but even with: $ grep MICROCODE .config # CONFIG_MICROCODE is not set # CONFIG_MICROCODE_INTEL_EARLY is not set # CONFIG_MICROCODE_AMD_EARLY is not set which means, it cannot be microcode-related. And I'd bet if you wait a minute (yep, it should be exactly 60 seconds) the boot would probably continue. And if so, this is that 60 sec delay where the kernel tries to find firmware. Hmm... I have the same problem: Booting 3.11-rc1 hangs after the line: ACPI: Executed 3 blocks of module-level executable AML code I bisected it down to the early microcode changes: 757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small fixup) completely fail to boot (No output beyond Booting kernel) , from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 (Make find_ucode_in_initrd() __init) I'm seeing this hang. Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system now sucessfully boots 3.11-rc1. Ok, I need to be able to reproduce that first - I wasn't that successful with Johannes' setup. So, can you please send .config and how you're loading your microcode? Is it in the initrd or are you doing that later, how? Grub entry please. Also, is it just plain v3.11-rc1 or with patches ontop? Also, /proc/cpuinfo please. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Sun, Jul 21, 2013 at 12:59 AM, Borislav Petkov b...@alien8.de wrote:
On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote:
On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov b...@alien8.de wrote:
On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
config is attached
Ok, I can reproduce the hang with your config but even with:
$ grep MICROCODE .config
# CONFIG_MICROCODE is not set
# CONFIG_MICROCODE_INTEL_EARLY is not set
# CONFIG_MICROCODE_AMD_EARLY is not set
which means, it cannot be microcode-related.
And I'd bet if you wait a minute (yep, it should be exactly 60 seconds)
the boot would probably continue. And if so, this is that 60 sec delay
where the kernel tries to find firmware.
Hmm...
I have the same problem: Booting 3.11-rc1 hangs after the line:
ACPI: Executed 3 blocks of module-level executable AML code
I bisected it down to the early microcode changes:
757885e94a22bcc82beb9b1445c95218cb20ceab (the new early loading
implementation) and 6b3389ac21b5e557b957f1497d0ff22bf733e8c3 (small
fixup) completely fail to boot (No output beyond Booting kernel) ,
from 275bbe2e299f1820ec8faa443d689469a9e6ecc5 (Make
find_ucode_in_initrd() __init) I'm seeing this hang.
Just turning CONFIG_MICROCODE_EARLY off solves the problem: The system
now sucessfully boots 3.11-rc1.
Ok, I need to be able to reproduce that first - I wasn't that successful
with Johannes' setup.
So, can you please send .config and how you're loading your microcode?
Is it in the initrd or are you doing that later, how? Grub entry please.
Also, is it just plain v3.11-rc1 or with patches ontop?
Also, /proc/cpuinfo please.
.config and cpuinfo attached.
Microcode seems not to be loaded at all, for MICROCODE_EARLY I did not
attach the needed file / cpio and the normal update mechanism seems to
not have a newer microcode that what the BIOS is providing.
I'm using a custom initrd, but that can't be used for MICROCODE_EARLY
because its compressed and does not contain a AuthenticAMD.bin. Its
also not containing microcode_amd.bin, because I'm suppling that via
CONFIG_EXTRA_FIRMWARE.
Grub entry:
title 3.11.0-rc1-crypt
root (hd0,0)
kernel (hd0,0)/boot/kernel-3.11.0-rc1 fastboot crypt_root=/dev/md6
video=1280x1024 radeon.dpm=1
initrd (hd0,0)/boot/ramfs-2011.gz
savedefault
I was using plain 3.11-rc1 except the changes I made to debug this.
What I think you need: A system that is fatally affected by AMD
Erratum 400 and an 64bit kernel.
From my debugging I found the following sequence of events occurs on my system:
The BSP will call load_ucode_ap().
That will call collect_cpu_info_amd_early(), which will fill the
cpuinfo_x86.x86 and cpuinfo_x86.microcode fields of the
cpu_info-per-cpu-structure that has not yet been setup. Because this
code will only be used with MICROCODE_EARLY disabling this options
make my system boot. OTOH this function is called regardless if
AuthenticAMD.bin is available or not, thats why I'm hitting it even
without the special cpio.
Then the BSP will call init_amd() to apply the errata fixes. That uses
cpu_has_amd_erratum(), but that function is not using the cpuinfo_x86
that was supplied to init_amd() (And used for the following
set_cpu_bug() is the erratum was found!), but instead is guessing
itself if it should use the per-cpu data or boot_cpu_data. And it uses
the not yet initialized per-cpu data for that guess. Which normally
works fine, because that will all be zeroed out, but
collect_cpu_info_amd_early() has filled -x86 and so
cpu_has_amd_erratum() wil use the partly filled per-cpu data instead
of the correct boot_cpu_data. But because collect_cpu_info_amd_early()
did not fill -x86_vendor that field is still 0 == X86_VENDOR_INTEL
and cpu_has_amd_erratum() will lie that no erratum is present.
So the C1E work around is not applied and as soon as ACPI enables this
the boot hangs.
Something like the following (whitespace mangled by Gmail, if it looks
OK for you, I will send it as a clean patch) fixes
cpu_has_amd_erratum() for me, but I did not look how the early
microcode loading should work if AuthenticAMD.bin is available to
offer a fix the premature accesses to per-cpu cpu_info.
--- 3.11-rc1/arch/x86/kernel/cpu/amd.c.orig 2013-07-21
05:42:42.130346496 +0200
+++ 3.11-rc1/arch/x86/kernel/cpu/amd.c 2013-07-21 05:45:09.420345843 +0200
@@ -512,7 +512,7 @@
static const int amd_erratum_383[];
static const int amd_erratum_400[];
-static bool cpu_has_amd_erratum(const int *erratum);
+static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);
static void __cpuinit init_amd(struct cpuinfo_x86 *c)
{
@@ -729,11 +729,11 @@
value = ~(1ULL 24);
wrmsrl_safe(MSR_AMD64_BU_CFG2, value);
- if (cpu_has_amd_erratum(amd_erratum_383))
+ if (cpu_has_amd_erratum(c, amd_erratum_383))
set_cpu_bug(c, X86_BUG_AMD_TLB_MMATCH);
}
- if
Re: early microcode on amd is broken when no initramfs provided
On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote: > config is attached Ok, I can reproduce the hang with your config but even with: $ grep MICROCODE .config # CONFIG_MICROCODE is not set # CONFIG_MICROCODE_INTEL_EARLY is not set # CONFIG_MICROCODE_AMD_EARLY is not set which means, it cannot be microcode-related. And I'd bet if you wait a minute (yep, it should be exactly 60 seconds) the boot would probably continue. And if so, this is that 60 sec delay where the kernel tries to find firmware. Hmm... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote: config is attached Ok, I can reproduce the hang with your config but even with: $ grep MICROCODE .config # CONFIG_MICROCODE is not set # CONFIG_MICROCODE_INTEL_EARLY is not set # CONFIG_MICROCODE_AMD_EARLY is not set which means, it cannot be microcode-related. And I'd bet if you wait a minute (yep, it should be exactly 60 seconds) the boot would probably continue. And if so, this is that 60 sec delay where the kernel tries to find firmware. Hmm... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Wed, 10 Jul 2013 09:30:49 +0200
Borislav Petkov wrote:
> On Tue, Jul 09, 2013 at 06:36:01PM +0200, Johannes Hirte wrote:
> > When CONFIG_MICROCODE_EARLY is enabled on AMD but no initramfs is
> > provided in the bootmanager (grub2), the system hangs here:
>
> Hmm, I can't reproduce it here.
>
> grub2 entry is:
>
> menuentry 'Debian GNU/Linux, with Linux 3.10.0+' --class debian
> --class gnu-linux --class gnu --class os { load_video
> insmod gzio
> insmod part_msdos
> insmod ext2
> set root='(hd0,msdos1)'
> search --no-floppy --fs-uuid --set=root
> adbbd17b-6e04-4458-814f-9a2b75a4d91e echo'Loading Linux
> 3.10.0+ ...' linux /boot/vmlinuz-3.10.0+ root=/dev/sda1 ro
> resume=/dev/sda2 ignore_loglevel }
>
> Kernel is: v3.10-8587-g496322b
>
> .config settings are:
>
> $ zgrep -E "(INITRD|MICROCODE)" /proc/config.gz
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_MICROCODE=y
> CONFIG_MICROCODE_INTEL=y
> CONFIG_MICROCODE_AMD=y
> CONFIG_MICROCODE_OLD_INTERFACE=y
> CONFIG_MICROCODE_INTEL_LIB=y
> CONFIG_MICROCODE_INTEL_EARLY=y
> CONFIG_MICROCODE_AMD_EARLY=y
> CONFIG_MICROCODE_EARLY=y
> # CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
>
> Can you send me your .config and your grub entry please?
>
> Thanks.
>
grub entry:
menuentry 'Gentoo GNU/Linux 3.10.0-09080-g19d2f8e' --class gentoo
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-simple-d044ac73-1dd2-4250-b864-5cb25fd67192' { load_video
insmod gzio insmod part_msdos
insmod btrfs
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3
--hint-baremetal=ahci0,msdos3 c684c3ff-5bac-4ba8-8f63-c9036c2ad233
else search --no-floppy --fs-uuid --set=root
c684c3ff-5bac-4ba8-8f63-c9036c2ad233 fi echo'Linux
3.10.0-09080-g19d2f8e wird geladen …'
linux /vmlinuz-3.10.0-09080-g19d2f8e root=/dev/sda1 ro
pcie_aspm=force radeon.dpm=1 }
config is attached
config.bz2
Description: application/bzip
Re: early microcode on amd is broken when no initramfs provided
On Wed, 10 Jul 2013 09:30:49 +0200
Borislav Petkov b...@alien8.de wrote:
On Tue, Jul 09, 2013 at 06:36:01PM +0200, Johannes Hirte wrote:
When CONFIG_MICROCODE_EARLY is enabled on AMD but no initramfs is
provided in the bootmanager (grub2), the system hangs here:
Hmm, I can't reproduce it here.
grub2 entry is:
menuentry 'Debian GNU/Linux, with Linux 3.10.0+' --class debian
--class gnu-linux --class gnu --class os { load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root
adbbd17b-6e04-4458-814f-9a2b75a4d91e echo'Loading Linux
3.10.0+ ...' linux /boot/vmlinuz-3.10.0+ root=/dev/sda1 ro
resume=/dev/sda2 ignore_loglevel }
Kernel is: v3.10-8587-g496322b
.config settings are:
$ zgrep -E (INITRD|MICROCODE) /proc/config.gz
CONFIG_BLK_DEV_INITRD=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD_EARLY=y
CONFIG_MICROCODE_EARLY=y
# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
Can you send me your .config and your grub entry please?
Thanks.
grub entry:
menuentry 'Gentoo GNU/Linux 3.10.0-09080-g19d2f8e' --class gentoo
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-simple-d044ac73-1dd2-4250-b864-5cb25fd67192' { load_video
insmod gzio insmod part_msdos
insmod btrfs
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3
--hint-baremetal=ahci0,msdos3 c684c3ff-5bac-4ba8-8f63-c9036c2ad233
else search --no-floppy --fs-uuid --set=root
c684c3ff-5bac-4ba8-8f63-c9036c2ad233 fi echo'Linux
3.10.0-09080-g19d2f8e wird geladen …'
linux /vmlinuz-3.10.0-09080-g19d2f8e root=/dev/sda1 ro
pcie_aspm=force radeon.dpm=1 }
config is attached
config.bz2
Description: application/bzip
Re: early microcode on amd is broken when no initramfs provided
On Tue, Jul 09, 2013 at 06:36:01PM +0200, Johannes Hirte wrote:
> When CONFIG_MICROCODE_EARLY is enabled on AMD but no initramfs is provided in
> the
> bootmanager (grub2), the system hangs here:
Hmm, I can't reproduce it here.
grub2 entry is:
menuentry 'Debian GNU/Linux, with Linux 3.10.0+' --class debian --class
gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root
adbbd17b-6e04-4458-814f-9a2b75a4d91e
echo'Loading Linux 3.10.0+ ...'
linux /boot/vmlinuz-3.10.0+ root=/dev/sda1 ro resume=/dev/sda2
ignore_loglevel
}
Kernel is: v3.10-8587-g496322b
.config settings are:
$ zgrep -E "(INITRD|MICROCODE)" /proc/config.gz
CONFIG_BLK_DEV_INITRD=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD_EARLY=y
CONFIG_MICROCODE_EARLY=y
# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
Can you send me your .config and your grub entry please?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Tue, Jul 09, 2013 at 06:36:01PM +0200, Johannes Hirte wrote:
When CONFIG_MICROCODE_EARLY is enabled on AMD but no initramfs is provided in
the
bootmanager (grub2), the system hangs here:
Hmm, I can't reproduce it here.
grub2 entry is:
menuentry 'Debian GNU/Linux, with Linux 3.10.0+' --class debian --class
gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root
adbbd17b-6e04-4458-814f-9a2b75a4d91e
echo'Loading Linux 3.10.0+ ...'
linux /boot/vmlinuz-3.10.0+ root=/dev/sda1 ro resume=/dev/sda2
ignore_loglevel
}
Kernel is: v3.10-8587-g496322b
.config settings are:
$ zgrep -E (INITRD|MICROCODE) /proc/config.gz
CONFIG_BLK_DEV_INITRD=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD_EARLY=y
CONFIG_MICROCODE_EARLY=y
# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
Can you send me your .config and your grub entry please?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Tue, Jul 09, 2013 at 10:53:31PM -0500, Jacob Shin wrote: > I won't have access to a box for a while, Boris or Suravee, could you > please try and reproduce it and get the stack trace when you get the > chance? > > So sorry, No worries, Jacob, I'm on it. Take your time. :) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: early microcode on amd is broken when no initramfs provided
On Tue, Jul 09, 2013 at 06:36:01PM +0200, Johannes Hirte wrote: > When CONFIG_MICROCODE_EARLY is enabled on AMD but no initramfs is provided in > the > bootmanager (grub2), the system hangs here: I'll take a look soonish if Jacob doesn't beat me to it. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
early microcode on amd is broken when no initramfs provided
When CONFIG_MICROCODE_EARLY is enabled on AMD but no initramfs is provided in the bootmanager (grub2), the system hangs here: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.10.0-06005-gd2b4a64 (puck@acer) (gcc version 4.8.1 (Gentoo 4.8.1 p1.0, pie-0.5.6) ) #69 SMP PREEMPT Tue Jul 9 18:22:09 CEST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-06005-gd2b4a64 root=/dev/sda1 ro pcie_aspm=force radeon.dpm=1 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xde555fff] usable [0.00] BIOS-e820: [mem 0xde556000-0xde755fff] ACPI NVS [0.00] BIOS-e820: [mem 0xde756000-0xdfd3efff] usable [0.00] BIOS-e820: [mem 0xdfd3f000-0xdfdbefff] reserved [0.00] BIOS-e820: [mem 0xdfdbf000-0xdfebefff] ACPI NVS [0.00] BIOS-e820: [mem 0xdfebf000-0xdfef6fff] ACPI data [0.00] BIOS-e820: [mem 0xdfef7000-0xdfef] usable [0.00] BIOS-e820: [mem 0xdff0-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf700-0xf7ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffe0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00011fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: Packard Bell EasyNote TK81/SJV52_DN, BIOS V2.14 07/27/2011 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x12 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask C000 write-back [0.00] 2 base C000 mask E000 write-back [0.00] 3 base FFE0 mask FFE0 write-protect [0.00] 4 base 0001 mask E000 write-back [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00012000 aka 4608M [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xdff00 max_arch_pfn = 0x4 [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88098000] 98000 size 28672 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x01c08000, 0x01c08fff] PGTABLE [0.00] BRK [0x01c09000, 0x01c09fff] PGTABLE [0.00] BRK [0x01c0a000, 0x01c0afff] PGTABLE [0.00] init_memory_mapping: [mem 0x11fe0-0x11fff] [0.00] [mem 0x11fe0-0x11fff] page 2M [0.00] BRK [0x01c0b000, 0x01c0bfff] PGTABLE [0.00] init_memory_mapping: [mem 0x11c00-0x11fdf] [0.00] [mem 0x11c00-0x11fdf] page 2M [0.00] init_memory_mapping: [mem 0x1-0x11bff] [0.00] [mem 0x1-0x11bff] page 2M [0.00] init_memory_mapping: [mem 0x0010-0xde555fff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x3fff] page 2M [0.00] [mem 0x4000-0xbfff] page 1G [0.00] [mem 0xc000-0xde3f] page 2M [0.00] [mem 0xde40-0xde555fff] page 4k [0.00] init_memory_mapping: [mem 0xde756000-0xdfd3efff] [0.00] [mem 0xde756000-0xde7f] page 4k [0.00] [mem 0xde80-0xdfbf] page 2M [0.00] [mem 0xdfc0-0xdfd3efff] page 4k [0.00] BRK [0x01c0c000, 0x01c0cfff] PGTABLE [0.00] init_memory_mapping:
Re: early microcode on amd is broken when no initramfs provided
On Tue, Jul 09, 2013 at 10:53:31PM -0500, Jacob Shin wrote: I won't have access to a box for a while, Boris or Suravee, could you please try and reproduce it and get the stack trace when you get the chance? So sorry, No worries, Jacob, I'm on it. Take your time. :) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
early microcode on amd is broken when no initramfs provided
When CONFIG_MICROCODE_EARLY is enabled on AMD but no initramfs is provided in the bootmanager (grub2), the system hangs here: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.10.0-06005-gd2b4a64 (puck@acer) (gcc version 4.8.1 (Gentoo 4.8.1 p1.0, pie-0.5.6) ) #69 SMP PREEMPT Tue Jul 9 18:22:09 CEST 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-06005-gd2b4a64 root=/dev/sda1 ro pcie_aspm=force radeon.dpm=1 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xde555fff] usable [0.00] BIOS-e820: [mem 0xde556000-0xde755fff] ACPI NVS [0.00] BIOS-e820: [mem 0xde756000-0xdfd3efff] usable [0.00] BIOS-e820: [mem 0xdfd3f000-0xdfdbefff] reserved [0.00] BIOS-e820: [mem 0xdfdbf000-0xdfebefff] ACPI NVS [0.00] BIOS-e820: [mem 0xdfebf000-0xdfef6fff] ACPI data [0.00] BIOS-e820: [mem 0xdfef7000-0xdfef] usable [0.00] BIOS-e820: [mem 0xdff0-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf700-0xf7ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffe0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00011fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: Packard Bell EasyNote TK81/SJV52_DN, BIOS V2.14 07/27/2011 [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x12 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask C000 write-back [0.00] 2 base C000 mask E000 write-back [0.00] 3 base FFE0 mask FFE0 write-protect [0.00] 4 base 0001 mask E000 write-back [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00012000 aka 4608M [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xdff00 max_arch_pfn = 0x4 [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88098000] 98000 size 28672 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x01c08000, 0x01c08fff] PGTABLE [0.00] BRK [0x01c09000, 0x01c09fff] PGTABLE [0.00] BRK [0x01c0a000, 0x01c0afff] PGTABLE [0.00] init_memory_mapping: [mem 0x11fe0-0x11fff] [0.00] [mem 0x11fe0-0x11fff] page 2M [0.00] BRK [0x01c0b000, 0x01c0bfff] PGTABLE [0.00] init_memory_mapping: [mem 0x11c00-0x11fdf] [0.00] [mem 0x11c00-0x11fdf] page 2M [0.00] init_memory_mapping: [mem 0x1-0x11bff] [0.00] [mem 0x1-0x11bff] page 2M [0.00] init_memory_mapping: [mem 0x0010-0xde555fff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x3fff] page 2M [0.00] [mem 0x4000-0xbfff] page 1G [0.00] [mem 0xc000-0xde3f] page 2M [0.00] [mem 0xde40-0xde555fff] page 4k [0.00] init_memory_mapping: [mem 0xde756000-0xdfd3efff] [0.00] [mem 0xde756000-0xde7f] page 4k [0.00] [mem 0xde80-0xdfbf] page 2M [0.00] [mem 0xdfc0-0xdfd3efff] page 4k [0.00] BRK [0x01c0c000, 0x01c0cfff] PGTABLE [0.00] init_memory_mapping:
Re: early microcode on amd is broken when no initramfs provided
On Tue, Jul 09, 2013 at 06:36:01PM +0200, Johannes Hirte wrote: When CONFIG_MICROCODE_EARLY is enabled on AMD but no initramfs is provided in the bootmanager (grub2), the system hangs here: I'll take a look soonish if Jacob doesn't beat me to it. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
