Re: [PATCH] fix x86 cpuid keys used in alternative_smp()

>> By hard-coding the cpuid keys for alternative_smp() rather than using
>> the symbolic constant it turned out that incorrect values were used on
>> both i386 (0x68 instead of 0x69) and x86-64 (0x66 instead of 0x68).
>
>Thanks. Applied.
>
>I wonder if that was the reason why the .fill misassembly the 
>2.16.91.0.5 (10.1) binutils commits (see recent discuss report from
>Rafael) didn't cause crashes on UP machines.  Do you have
>an opinion on that?

That is well possible - I saw the mail, and I also wondered why this
wouldn't result in a broken kernel.

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • [PATCH] fix x86 cpuid keys used in alternative_smp()
    • From: "Jan Beulich" <[email protected]>
  • Re: [PATCH] fix x86 cpuid keys used in alternative_smp()
    • From: Andi Kleen <[email protected]>

• Prev by Date: Re: [-mm patch] hdaps: Add explicit hardware configuration functions - fix
• Next by Date: Re: [Containers] [PATCH 5/7] pid: Implement pid_nr
• Previous by thread: Re: [PATCH] fix x86 cpuid keys used in alternative_smp()
• Next by thread: How to find a sick router with 2.6.17+ and tcp_window_scaling enabled
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]