linux/arch/x86/kernel/apic, branch v3.2.27

x86, apic: APIC code touches invalid MSR on P5 class machines

2012-05-11T12:14:31Z

commit cbf2829b61c136edcba302a5e1b6b40e97d32c00 upstream. Current APIC code assumes MSR_IA32_APICBASE is present for all systems. Pentium Classic P5 and friends didn't have this MSR. MSR_IA32_APICBASE was introduced as an architectural MSR by Intel @ P6. Code paths that can touch this MSR invalidly are when vendor == Intel && cpu-family == 5 and APIC bit is set in CPUID - or when you simply pass lapic on the kernel command line, on a P5. The below patch stops Linux incorrectly interfering with the MSR_IA32_APICBASE for P5 class machines. Other code paths exist that touch the MSR - however those paths are not currently reachable for a conformant P5. Signed-off-by: Bryan O'Donoghue Link: http://lkml.kernel.org/r/4F8EEDD3.1080404@linux.intel.com Signed-off-by: H. Peter Anvin Signed-off-by: Ben Hutchings

Revert "x86/ioapic: Add register level checks to detect bogus io-apic entries"

2012-04-13T15:33:49Z

This reverts commit 273fb194e86b795b08a724c7646d0f694949070b [73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream] It causes problems, so needs to be reverted from 3.2-stable for now. Reported-by: Konrad Rzeszutek Wilk Cc: Jon Dufresne Cc: Suresh Siddha Cc: Cc: Josh Boyer Cc: Ingo Molnar Cc: Teck Choon Giam Cc: Ben Guthro Signed-off-by: Greg Kroah-Hartman

x86/ioapic: Add register level checks to detect bogus io-apic entries

2012-04-02T16:52:36Z

commit 73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream. With the recent changes to clear_IO_APIC_pin() which tries to clear remoteIRR bit explicitly, some of the users started to see "Unable to reset IRR for apic .." messages. Close look shows that these are related to bogus IO-APIC entries which return's all 1's for their io-apic registers. And the above mentioned error messages are benign. But kernel should have ignored such io-apic's in the first place. Check if register 0, 1, 2 of the listed io-apic are all 1's and ignore such io-apic. Reported-by: Álvaro Castillo Tested-by: Jon Dufresne Signed-off-by: Suresh Siddha Cc: yinghai@kernel.org Cc: kernel-team@fedoraproject.org Cc: Josh Boyer Link: http://lkml.kernel.org/r/1331577393.31585.94.camel@sbsiddha-desk.sc.intel.com [ Performed minor cleanup of affected code. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86, UV: Update Boot messages for SGI UV2 platform

2012-01-26T00:13:33Z

commit da517a08ac5913cd80ce3507cddd00f2a091b13c upstream. SGI UV systems print a message during boot: UV: Found blades Due to packaging changes, the blade count is not accurate for on the next generation of the platform. This patch corrects the count. Signed-off-by: Jack Steiner Link: http://lkml.kernel.org/r/20120106191900.GA19772@sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86, UV: Fix UV2 hub part number

2011-12-05T10:49:52Z

There was a mixup when the SGI UV2 hub chip was sent to be fabricated, and it ended up with the wrong part number in the HRP_NODE_ID mmr. Future versions of the chip will (may) have the correct part number. Change the UV infrastructure to recognize both part numbers as valid IDs of a UV2 hub chip. Signed-off-by: Jack Steiner Link: http://lkml.kernel.org/r/20111129210058.GA20452@sgi.com Signed-off-by: Ingo Molnar

x86, ioapic: Only print ioapic debug information for IRQs belonging to an ioapic chip

2011-11-10T17:31:23Z

with "apic=verbose" the print_IO_APIC() function tries to print IRQ to pin mappings for every active irq. It assumes chip_data is of type irq_cfg and may cause an oops if not. As the print_IO_APIC() is called from a late_initcall other chained irq chips may already be registered with custom chip_data information, causing an oops. This is the case with intel MID SoC devices with gpio demuxers registered as irq_chips. Signed-off-by: Mathias Nyman Signed-off-by: Alan Cox [ -v2: fixed build failure ] Signed-off-by: Ingo Molnar

x86/apic: Allow use of lapic timer early calibration result

2011-11-10T15:20:57Z

lapic timer calibration can be combined with tsc in platform specific calibration functions. if such calibration result is obtained early, we can skip the redundant calibration loops. Signed-off-by: Jacob Pan Signed-off-by: Jacob Pan Signed-off-by: Alan Cox Signed-off-by: Dirk Brandewie Signed-off-by: Ingo Molnar

x86/apic: Do not clear nr_irqs_gsi if no legacy irqs

2011-11-10T15:20:55Z

nr_legacy_irqs is set in probe_nr_irqs_gsi, we should not clear it after that. Otherwise, the result is that MSI irqs will be allocated from the wrong range for the systems without legacy PIC. Signed-off-by: Jacob Pan Signed-off-by: Dirk Brandewie Signed-off-by: Ingo Molnar

Merge branch 'x86-uv-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2011-10-28T12:43:56Z

* 'x86-uv-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86: uv2: Workaround for UV2 Hub bug (system global address format)

Merge branch 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2011-10-26T15:30:33Z

* 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/irq: Standardize on CONFIG_SPARSE_IRQ=y x86, ioapic: Clean up ioapic/apic_id usage x86, ioapic: Factor out print_IO_APIC() to only print one io apic x86, ioapic: Print out irte with right ioapic index x86, ioapic: Split up setup_ioapic_entry() x86, ioapic: Pass struct irq_attr * to setup_ioapic_irq() apic, i386/bigsmp: Fix false warnings regarding logical APIC ID mismatches