* BAD APICID ? @ 2011-11-07 17:39 Dave Jones 2011-11-07 17:54 ` Borislav Petkov 0 siblings, 1 reply; 4+ messages in thread From: Dave Jones @ 2011-11-07 17:39 UTC (permalink / raw) To: x86; +Cc: Linux Kernel We got a report from a Fedora user hitting a WARN_ON in the apic setup code. Here.. 1230 #ifdef CONFIG_X86_32 1231 /* 1232 * APIC LDR is initialized. If logical_apicid mapping was 1233 * initialized during get_smp_config(), make sure it matches the 1234 * actual value. 1235 */ 1236 i = early_per_cpu(x86_cpu_to_logical_apicid, cpu); 1237 WARN_ON(i != BAD_APICID && i != logical_smp_processor_id()); 1238 /* always use the value from LDR */ 1239 early_per_cpu(x86_cpu_to_logical_apicid, cpu) = 1240 logical_smp_processor_id(); The full report is at https://bugzilla.redhat.com/show_bug.cgi?id=743930 Report is against our 3.0 builds, but that code look unchanged in 3.1 too, and even in current Linus head. Any thoughts on what could cause this ? Dave ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BAD APICID ? 2011-11-07 17:39 BAD APICID ? Dave Jones @ 2011-11-07 17:54 ` Borislav Petkov 2011-11-07 18:09 ` Dave Jones 0 siblings, 1 reply; 4+ messages in thread From: Borislav Petkov @ 2011-11-07 17:54 UTC (permalink / raw) To: Dave Jones; +Cc: x86, Linux Kernel On Mon, Nov 07, 2011 at 12:39:48PM -0500, Dave Jones wrote: > We got a report from a Fedora user hitting a WARN_ON in the apic setup code. > > Here.. > > 1230 #ifdef CONFIG_X86_32 > 1231 /* > 1232 * APIC LDR is initialized. If logical_apicid mapping was > 1233 * initialized during get_smp_config(), make sure it matches the > 1234 * actual value. > 1235 */ > 1236 i = early_per_cpu(x86_cpu_to_logical_apicid, cpu); > 1237 WARN_ON(i != BAD_APICID && i != logical_smp_processor_id()); > 1238 /* always use the value from LDR */ > 1239 early_per_cpu(x86_cpu_to_logical_apicid, cpu) = > 1240 logical_smp_processor_id(); > > The full report is at https://bugzilla.redhat.com/show_bug.cgi?id=743930 > > Report is against our 3.0 builds, but that code look unchanged in 3.1 too, > and even in current Linus head. > > Any thoughts on what could cause this ? Already fixed upstream: 838312be46f3abfbdc175f81c3e54a857994476d Here's the whole thread: http://lkml.org/lkml/2011/10/14/231 HTH. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BAD APICID ? 2011-11-07 17:54 ` Borislav Petkov @ 2011-11-07 18:09 ` Dave Jones 2011-11-07 20:17 ` Greg KH 0 siblings, 1 reply; 4+ messages in thread From: Dave Jones @ 2011-11-07 18:09 UTC (permalink / raw) To: Borislav Petkov; +Cc: x86, Linux Kernel, gregkh On Mon, Nov 07, 2011 at 06:54:02PM +0100, Borislav Petkov wrote: > On Mon, Nov 07, 2011 at 12:39:48PM -0500, Dave Jones wrote: > > We got a report from a Fedora user hitting a WARN_ON in the apic setup code. > > > > Here.. > > > > 1230 #ifdef CONFIG_X86_32 > > 1231 /* > > 1232 * APIC LDR is initialized. If logical_apicid mapping was > > 1233 * initialized during get_smp_config(), make sure it matches the > > 1234 * actual value. > > 1235 */ > > 1236 i = early_per_cpu(x86_cpu_to_logical_apicid, cpu); > > 1237 WARN_ON(i != BAD_APICID && i != logical_smp_processor_id()); > > 1238 /* always use the value from LDR */ > > 1239 early_per_cpu(x86_cpu_to_logical_apicid, cpu) = > > 1240 logical_smp_processor_id(); > > > > The full report is at https://bugzilla.redhat.com/show_bug.cgi?id=743930 > > > > Report is against our 3.0 builds, but that code look unchanged in 3.1 too, > > and even in current Linus head. > > > > Any thoughts on what could cause this ? > > Already fixed upstream: 838312be46f3abfbdc175f81c3e54a857994476d > > Here's the whole thread: http://lkml.org/lkml/2011/10/14/231 > > HTH. ah, excellent, thanks. That seems to have not hit stable, even though it was cc'd. Greg ? Dave ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: BAD APICID ? 2011-11-07 18:09 ` Dave Jones @ 2011-11-07 20:17 ` Greg KH 0 siblings, 0 replies; 4+ messages in thread From: Greg KH @ 2011-11-07 20:17 UTC (permalink / raw) To: Dave Jones, Borislav Petkov, x86, Linux Kernel On Mon, Nov 07, 2011 at 01:09:50PM -0500, Dave Jones wrote: > On Mon, Nov 07, 2011 at 06:54:02PM +0100, Borislav Petkov wrote: > > On Mon, Nov 07, 2011 at 12:39:48PM -0500, Dave Jones wrote: > > > We got a report from a Fedora user hitting a WARN_ON in the apic setup code. > > > > > > Here.. > > > > > > 1230 #ifdef CONFIG_X86_32 > > > 1231 /* > > > 1232 * APIC LDR is initialized. If logical_apicid mapping was > > > 1233 * initialized during get_smp_config(), make sure it matches the > > > 1234 * actual value. > > > 1235 */ > > > 1236 i = early_per_cpu(x86_cpu_to_logical_apicid, cpu); > > > 1237 WARN_ON(i != BAD_APICID && i != logical_smp_processor_id()); > > > 1238 /* always use the value from LDR */ > > > 1239 early_per_cpu(x86_cpu_to_logical_apicid, cpu) = > > > 1240 logical_smp_processor_id(); > > > > > > The full report is at https://bugzilla.redhat.com/show_bug.cgi?id=743930 > > > > > > Report is against our 3.0 builds, but that code look unchanged in 3.1 too, > > > and even in current Linus head. > > > > > > Any thoughts on what could cause this ? > > > > Already fixed upstream: 838312be46f3abfbdc175f81c3e54a857994476d > > > > Here's the whole thread: http://lkml.org/lkml/2011/10/14/231 > > > > HTH. > > ah, excellent, thanks. > That seems to have not hit stable, even though it was cc'd. Greg ? It's already been queued up for the next stable release, which should be coming out later this week once the firehose of the 3.2 merge window slows down. thanks, greg k-h ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-11-07 20:23 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-07 17:39 BAD APICID ? Dave Jones 2011-11-07 17:54 ` Borislav Petkov 2011-11-07 18:09 ` Dave Jones 2011-11-07 20:17 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox