aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86
Commit message (Collapse)AuthorAge
* Pull suspend-2.6.24 into release branchLen Brown2007-12-06
|\
| * ACPI: suspend: old debugging hacks sneaked backPavel Machek2007-12-06
| | | | | | | | | | | | | | | | Old debugging hack sneaked back during x86 merge, this removes it. Signed-off-by: Pavel Machek <pavel@suse.cz> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* | Tiny clean-up of OPROFILE/KPROBES configurationLinus Torvalds2007-12-06
| | | | | | | | | | | | | | Make the Kconfig.instrumentation file a bit easier on the eyes, and use the new ARCH_SUPPORTS_OPROFILE for x86[-64]. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | x86: arch_register_cpu() section fixAndrew Morton2007-12-04
| | | | | | | | | | | | | | | | | | | | fix this on i386 allnoconfig: WARNING: vmlinux.o(.text+0x6f2e): Section mismatch: reference to .init.text:register_cpu (between 'arch_register_cpu' and 'text_poke') Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: free_cache_attributes() section fixAdrian Bunk2007-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | free_cache_attributes() must be __cpuinit since it calls the __cpuinit cache_remove_shared_cpu_map(). This patch fixes the following section mismatch reported by Chris Clayton: ... WARNING: vmlinux.o(.text+0x90b6): Section mismatch: reference to .init.text:cache_remove_shared_cpu_map (between 'free_cache_attributes' and 'show_level') ... Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: add the word 'WARNING' in check_nmi_watchdog() outputDon Zickus2007-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Our automated test suite looks for keywords like error, fail, warning in the boot log. In the case when the nmi watchdog is determined to be stuck in check_nmi_watchdog(), none of those keywords are displayed. This patch adds a keyword, "WARNING:", so it makes it easier to notice when the nmi watchdog isn't working correctly. Also add a proper KERN_WARNING mark to this printout. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: revert CONFIG_X86_HT semantics changeAdrian Bunk2007-12-04
|/ | | | | | | | | | | | | | | | | | | The recent Kconfig changes in x86 resulted in CONFIG_X86_HT no longer being set if (X86_32 && MK8). After grep'ing through the tree I think the problem is that different places have different assumptions about the semantics of CONFIG_X86_HT, either: - hyperthreading or - multicore This should be sorted out properly, but until then we should keep the 2.6.23 status quo. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: fix x86-32 early fixmap initialization.Eric W. Biederman2007-12-03
| | | | | | | | | | | | | | | | | | | | pageexec@freemail.hu writes: > i've just noticed that the chunk in i386/kernel/head.S ended up in a > weird place, namely, it's not going to be executed as it's just after > a 'jmp 3f' and before startup_32_smp, probably not what you intended. > on a sidenote, the whole thing can be done in a single insn, like: > > movl $(swapper_pg_pmd - __PAGE_OFFSET + 0x067), (swapper_pg_dir - > __PAGE_OFFSET+ 4092) Thanks for the reminder I thought we had fixed this problem a while ago. Needed to get fixed virtual address for USB debug and earlycon with mmio. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: disable hpet legacy replacement for kdumpOGAWA Hirofumi2007-12-03
| | | | | | | | we should also add hpet_disable() for kdump. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: disable hpet on shutdownOGAWA Hirofumi2007-12-03
| | | | | | | | | | | | | | | | If HPET was enabled by pci quirks, we use i8253 as initial clockevent because pci quirks doesn't run until pci is initialized. The above means the kernel (or something) is assuming HPET legacy replacement is disabled and can use i8253 at boot. If we used kexec, it isn't true. So, this patch disables HPET legacy replacement for kexec in machine_shutdown(). Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* Merge branch 'for-linus' of ↵Linus Torvalds2007-11-29
|\ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup: x86 setup: don't recalculate ss:esp unless really necessary
| * x86 setup: don't recalculate ss:esp unless really necessaryJens Rottmann2007-11-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to work around old LILO versions providing an invalid ss register, the current setup code always sets up a new stack, immediately following .bss and the heap. But this breaks LOADLIN. This rewrite of the workaround checks for an invalid stack (ss!=ds) first, and leaves ss:sp alone otherwise (apart from aligning esp). [hpa note: LOADLIN has a number of arbitrary hard-coded limits that are being pushed up against. Without some major revision of LOADLIN itself it will not be sustainable keeping it alive. This gives it another brief lease on life, however. This patch also helps the cmdline truncation problem with old versions of SYSLINUX.] Signed-off-by: Jens Rottmann <JRottmann at LiPPERT-AT. de> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* | x86/paravirt: revert exports to restore old behaviourJeremy Fitzhardinge2007-11-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subdividing the paravirt_ops structure caused a regression in certain non-GPL modules which try to use mmu_ops and cpu_ops. This restores the old behaviour, and makes it consistent with the non-CONFIG_PARAVIRT case. Takashi Iwai <tiwai@suse.de> adds: > I took at this problem (as I have an nvidia card on one of my > workstations), and found out that the following suffer from > EXPORT_SYMBOL_GPL changes: > > * local_disable_irq(), local_irq_save*(), etc. > * MSR-related macros like rdmsr(), wrmsr(), read_cr0(), etc. > wbinvd(), too. > * pmd_val(), pgd_val(), etc are all involved with pv_mm_ops. > pmd_large() and pmd_bad() is also indirectly involved. > __flush_tlb() and friends suffer, too. Christoph Hellwig objects to this patch on the grounds that modules shouldn't be using these operations anyway. I don't think this is a particularly good reason to reject the patch, for several reasons: 1. These operations are still available to modules when not using CONFIG_PARAVIRT, since they are implicitly exported as inline functions via the kernel headers. Exporting the same functionality as GPL-only symbols just adds a gratuitious difference between CONFIG_PARAVIRT and non-CONFIG_PARAVIRT configurations. If we really think these operations are not for module use (or non-GPL module use), then we should solve the problem in a general way. 2. It's a regression from previous kernels, which would work these modules even with CONFIG_PARAVIRT enabled. 3. The operations in question seem pretty reasonable for modules to use. The control registers/MSRs can be accessed directly anyway, so there's no benefit in preventing modules from using standard interfaces. And it seems reasonable to allow a graphics driver to create its own mappings if it wants. Therefore, I think this patch should go in for 2.6.24. If people really think that these operations should not be available to modules, then we can address that separately. Signed-off-by: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com> Cc: Tobias Powalowski <t.powa@gmx.de> Cc: Christoph Hellwig <hch@infradead.org> Cc: Takashi Iwai <tiwai@suse.de> Cc: Zachary Amsden <zach@vmware.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | lguest: prevent VISWS or VOYAGER randconfigsRandy Dunlap2007-11-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keep lguest from being enabled on VISWS or VOYAGER configs, just as is already done for VMI and XEN. Otherwise randconfigs with VISWS and LGUEST have this problem: In file included from arch/x86/kernel/setup_32.c:61: include/asm-x86/mach-visws/setup_arch.h:8:1: warning: "ARCH_SETUP" redefined In file included from include/asm/msr.h:80, from include/asm/processor_32.h:17, from include/asm/processor.h:2, from include/asm/thread_info_32.h:16, from include/asm/thread_info.h:2, from include/linux/thread_info.h:21, from include/linux/preempt.h:9, from include/linux/spinlock.h:49, from include/linux/seqlock.h:29, from include/linux/time.h:8, from include/linux/timex.h:57, from include/linux/sched.h:53, from arch/x86/kernel/setup_32.c:24: include/asm/paravirt.h:458:1: warning: this is the location of the previous definition (and of course, this happens because kconfig does not follow dependencies when [evil] select is used...) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | memory hotplug x86_64: fix section mismatch in init_memory_mapping()KAMEZAWA Hiroyuki2007-11-29
| | | | | | | | | | | | | | | | | | | | | | | | | | Changes __meminit to __init_refok. WARNING: vmlinux.o(.text+0x1d07c): Section mismatch: reference to .init.text:find_e820_area (between 'init_memory_mapping' and 'arch_add_memory') Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | xen: mask _PAGE_PCD from ptesJeremy Fitzhardinge2007-11-29
|/ | | | | | | | | | | | | | | _PAGE_PCD maps a page with caching disabled, which is typically used for mapping harware registers. Xen never allows it to be set on a mapping, and unprivileged guests never need it since they can't see the real underlying hardware. However, some uncached mappings are made early when probing the (non-existent) APIC, and its OK to mask off the PCD flag in these cases. This became necessary because Xen started checking for this bit, rather than silently masking it off. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86Linus Torvalds2007-11-26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86: x86: fix APIC related bootup crash on Athlon XP CPUs time: add ADJ_OFFSET_SS_READ x86: export the symbol empty_zero_page on the 32-bit x86 architecture x86: fix kprobes_64.c inlining borkage pci: use pci=bfsort for HP DL385 G2, DL585 G2 x86: correctly set UTS_MACHINE for "make ARCH=x86" lockdep: annotate do_debug() trap handler x86: turn off iommu merge by default x86: fix ACPI compile for LOCAL_APIC=n x86: printk kernel version in WARN_ON and other dump_stack users ACPI: Set max_cstate to 1 for early Opterons. x86: fix NMI watchdog & 'stopped time' problem
| * x86: fix APIC related bootup crash on Athlon XP CPUsIngo Molnar2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | warmbloodedcreature@gmail.com reported that an APIC-enabled Asus a7v8x-x with an Athlon XP reboots early in the bootup: http://bugzilla.kernel.org/show_bug.cgi?id=8723 after a long marathon of spontaneous-reboot debugging, it turns out to be caused by sync_Arb_ids(). AMD CPUs never really needed this sequence anyway, so just return early if we meet an AMD CPU. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * x86: export the symbol empty_zero_page on the 32-bit x86 architectureTheodore Ts'o2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | The latest KVM driver wants to use the empty_zero_page symbol, and it's not exported in 32-bit x86 (although it is exported by x86_64, s390, and uml architectures). Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: tglx@linutronix.de Cc: linux-kernel@vger.kernel.com Cc: kvm-devel@lists.sourceforge.net Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * x86: fix kprobes_64.c inlining borkageAndrew Morton2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix: arch/x86/kernel/kprobes_64.c: In function 'set_current_kprobe': arch/x86/kernel/kprobes_64.c:152: sorry, unimplemented: inlining failed in call to 'is_IF_modifier': recursive inlining arch/x86/kernel/kprobes_64.c:166: sorry, unimplemented: called from here Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: mingo@elte.hu Cc: akpm@linux-foundation.org Cc: tglx@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * pci: use pci=bfsort for HP DL385 G2, DL585 G2Michal Schmidt2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI devices in the expected order. Matt sayeth: biosdevname is a userspace app I wrote to help solve this so we don't need to patch the kernel for future systems. It's not integrated into any distributions properly yet, but is included in openSUSE 10.3 and Fedora 8 for people who want to download and install it there. It acts as a udev helper. For the time being, patching the kernel is necessary. I really hope biosdevname eliminates that need in future distributions. http://linux.dell.com/biosdevname/ Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Acked-by: Andy Gospodarek <andy@greyhouse.net> Cc: mingo@elte.hu Cc: andy@greyhouse.net Cc: john.cagle@hp.com Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: Greg KH <greg@kroah.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * x86: correctly set UTS_MACHINE for "make ARCH=x86"Andreas Herrmann2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | x86: correctly set UTS_MACHINE for "make ARCH=x86" For a kernel built with "make ARCH=x86" the following system information is displayed when running the new kernel $ uname -m x86 On some i386 systems (e.g. K7) we even have the following information $ uname -m x66 This is weird. The usual information for "uname -m" should be "x86_64" on 64-bit and "i386" or "i686" on 32-bit. This patch fixes the issue by setting UTS_MACHINE to "i386" for 32-bit kernel builds and to "x86_64" for 64-bit kernel builds. I.e., "x86" won't be used for UTS_MACHINE anymore. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andreas Herrmann <aherrman@arcor.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@redhat.com>
| * lockdep: annotate do_debug() trap handlerPeter Zijlstra2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure the hardirq state is consistent before using locks. Use the rare trace_hardirqs_fixup() because the trap can happen in any context. resolves this rare lockdep warning: WARNING: at kernel/lockdep.c:2658 check_flags() [<c013571e>] check_flags+0x90/0x140 [<c0138a69>] lock_release+0x4b/0x1d0 [<c0507fea>] notifier_call_chain+0x2a/0x47 [<c050806b>] __atomic_notifier_call_chain+0x64/0x6d [<c0508007>] __atomic_notifier_call_chain+0x0/0x6d [<c050808b>] atomic_notifier_call_chain+0x17/0x1a [<c0131802>] notify_die+0x30/0x34 [<c0506b09>] do_debug+0x3e/0xd4 [<c050658f>] debug_stack_correct+0x27/0x2c [<c04be389>] tcp_rcv_established+0x1/0x620 [<c04c38c2>] tcp_v4_do_rcv+0x2b/0x313 [<c04c56b6>] tcp_v4_rcv+0x467/0x85d [<c0505ff2>] _spin_lock_nested+0x27/0x32 [<c04c5a4d>] tcp_v4_rcv+0x7fe/0x85d [<c04c560e>] tcp_v4_rcv+0x3bf/0x85d [<c04adbb5>] ip_local_deliver_finish+0x11b/0x1b0 [<c04adac8>] ip_local_deliver_finish+0x2e/0x1b0 [<c04ada7b>] ip_rcv_finish+0x27b/0x29a [<c04961e5>] netif_receive_skb+0xfb/0x2a6 [<c04add0f>] ip_rcv+0x0/0x1fb [<c0496354>] netif_receive_skb+0x26a/0x2a6 [<c04961e5>] netif_receive_skb+0xfb/0x2a6 [<c049872e>] process_backlog+0x7f/0xc6 [<c04983ba>] net_rx_action+0xb9/0x1ac [<c0498348>] net_rx_action+0x47/0x1ac [<c01376cb>] trace_hardirqs_on+0x118/0x16b [<c01225e2>] __do_softirq+0x49/0xa2 [<c010595f>] do_softirq+0x60/0xdd [<c0506300>] _spin_unlock_irq+0x20/0x2c [<c0103e4f>] restore_nocheck+0x12/0x15 [<c01440e1>] handle_fasteoi_irq+0x0/0x9b [<c0105a70>] do_IRQ+0x94/0xaa [<c0506300>] _spin_unlock_irq+0x20/0x2c [<c0104832>] common_interrupt+0x2e/0x34 [<c0114703>] native_safe_halt+0x2/0x3 [<c0102c01>] default_idle+0x44/0x65 [<c010257f>] cpu_idle+0x42/0x50 [<c076ea09>] start_kernel+0x26b/0x270 [<c076e317>] unknown_bootoption+0x0/0x196 ======================= irq event stamp: 559190 hardirqs last enabled at (559190): [<c0507316>] kprobe_exceptions_notify+0x299/0x305 hardirqs last disabled at (559189): [<c05067bf>] do_int3+0x1d/0x95 softirqs last enabled at (559172): [<c010595f>] do_softirq+0x60/0xdd softirqs last disabled at (559181): [<c010595f>] do_softirq+0x60/0xdd Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * x86: turn off iommu merge by defaultIngo Molnar2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | revert this commit for now: commit 948062683004d13ca21c8c05ac052d387978a449 Author: Andi Kleen <ak@suse.de> Date: Fri Oct 19 20:35:03 2007 +0200 x86: enable iommu_merge by default it's causing regressions: http://bugzilla.kernel.org/show_bug.cgi?id=9412 Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * x86: printk kernel version in WARN_ON and other dump_stack usersArjan van de Ven2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | today, all oopses contain a version number of the kernel, which is nice because the people who actually do bother to read the oops get this vital bit of information always without having to ask the reporter in another round trip. However, WARN_ON() and many other dump_stack() users right now lack this information; the patch below adds this. This information is essential for getting people to use their time effectively when looking at these things; in addition, it's essential for tools that try to collect statistics about defects. Please consider, since its so simple and important for long term kernel quality processes. The code is identical between 32/64 bit; a lot of this code should be unified over time, the patch keeps the identical-ness intact. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * x86: fix NMI watchdog & 'stopped time' problemMaciej W. Rozycki2007-11-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | More than 3 years ago Niclas Gustafsson reported a 'stopped time' problem: > Watching the /proc/interrupts with 10s apart after the "stop". > > [root@s151 root]# more /proc/interrupts > CPU0 > 0: 66413955 local-APIC-edge timer [...] > LOC: 67355837 > ERR: 0 > MIS: 0 > [root@s151 root]# more /proc/interrupts > CPU0 > 0: 66413955 local-APIC-edge timer [...] > LOC: 67379568 > ERR: 0 > MIS: 0 This may be because buggy SMM firmware messes with the 8259A (configured for a transparent mode -- yes that rare "local-APIC-edge" mode is tricky ;-) ) insanely. this should resolve: http://bugzilla.kernel.org/show_bug.cgi?id=2544 http://bugzilla.kernel.org/show_bug.cgi?id=6296 Patch-dusted-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | Merge branch 'release' of ↵Linus Torvalds2007-11-26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (39 commits) ACPI: EC: Workaround for optimized controllers (version 3) ACPI: EC: use printk_ratelimit(), add some DEBUG mode messages Revert "ACPI: EC: Workaround for optimized controllers" ACPI: fix two IRQ8 issues in IOAPIC mode ACPI: Add missing spaces to printk format cpuidle: fix HP nx6125 regression cpuidle: add sched_clock_idle_[sleep|wakeup]_event() hooks cpuidle: fix C3 for no bus-master control case ACPI: thinkpad-acpi: fix oops when a module parameter has no value Revert "Fix very high interrupt rate for IRQ8 (rtc) unless pnpacpi=off" ACPI: EC: Don't init EC early if it has no _INI Revert "acpi: make ACPI_PROCFS default to y" Revert "ACPI: add documentation for deprecated /proc/acpi/battery in ACPI_PROCFS" ACPI: Split out control for /proc/acpi entries from battery, ac, and sbs. ACPI: Video: Increase buffer size for writes to brightness proc file. ACPI: EC: Workaround for optimized controllers ACPI: SBS: Fix retval warning ACPI: Enable MSR (FixedHW) support for T-States ACPI: Get throttling info from BIOS only after evaluating _PDC ACPI: Use _TSS for throttling control, when present. Add error checks. ...
| * \ Pull fluff into release branchLen Brown2007-11-20
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/ec.c Signed-off-by: Len Brown <len.brown@intel.com>
| | * | x86: acpi_pciprobe_dmi_table[] must be __devinitdataAdrian Bunk2007-11-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the following section mismatches with CONFIG_HOTPLUG=n: <-- snip --> ... WARNING: vmlinux.o(.data+0x23640): Section mismatch: reference to .init.text.20:can_skip_ioresource_align (between 'acpi_pciprobe_dmi_table' and 'pcibios_irq_mask') WARNING: vmlinux.o(.data+0x2366c): Section mismatch: reference to .init.text.20:can_skip_ioresource_align (between 'acpi_pciprobe_dmi_table' and 'pcibios_irq_mask') WARNING: vmlinux.o(.data+0x23698): Section mismatch: reference to .init.text.20:can_skip_ioresource_align (between 'acpi_pciprobe_dmi_table' and 'pcibios_irq_mask') ... <-- snip --> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | x86_64: remove acpi_pci_link_exit()Adrian Bunk2007-11-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi_pci_link_exit() is both unused and empty. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | Pull thermal into release branchLen Brown2007-11-20
| |\ \ \
| | * | | ACPI: Enable MSR (FixedHW) support for T-StatesZhao Yakui2007-11-16
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add throttling control via MSR when T-states uses the FixHW Control Status registers. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Li Shaohua <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | / ACPI: fix two IRQ8 issues in IOAPIC modeShaohua Li2007-11-20
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use mp_irqs[] to get PNP device's interrupt polarity and trigger. There are two reasons to do this: 1. BIOS bug for PNP interrupt 2. BIOS explictly does override mp_irqs[] should cover all the cases. http://bugzilla.kernel.org/show_bug.cgi?id=5243 http://bugzilla.kernel.org/show_bug.cgi?id=7679 http://bugzilla.kernel.org/show_bug.cgi?id=9153 [lenb: fixed !IOAPIC and 64-bit !SMP builds] Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* / | x86: correctly set UTS_MACHINE for "make ARCH=x86"Andreas Herrmann2007-11-26
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For a kernel built with "make ARCH=x86" the following system information is displayed when running the new kernel $ uname -m x86 On some i386 systems (e.g. K7) we even have the following information $ uname -m x66 This is weird. The usual information for "uname -m" should be "x86_64" on 64-bit and "i386" or "i686" on 32-bit. This patch fixes the issue by setting UTS_MACHINE to "i386" for 32-bit kernel builds and to "x86_64" for 64-bit kernel builds. I.e., "x86" won't be used for UTS_MACHINE anymore. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andreas Herrmann <aherrman@arcor.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | x86: simplify "make ARCH=x86" and fix kconfig all.configSam Ravnborg2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in all.config. For a fix the diffstat is nice: 6 files changed, 3 insertions(+), 36 deletions(-) The patch reverts these commits: 0f855aa64b3f63d35a891510cf7db932a435c116 -> kconfig: add helper to set config symbol from environment variable 2a113281f5cd2febbab21a93c8943f8d3eece4d3 -> kconfig: use $K64BIT to set 64BIT with all*config targets Roman Zippel pointed out that kconfig supported string compares so the additional complexity introduced by the above two patches were not needed. With this patch we have following behaviour: # make {allno,allyes,allmod,rand}config [ARCH=...] option \ host arch | 32bit | 64bit ===================================================== ./. | 32bit | 64bit ARCH=x86 | 32bit | 32bit ARCH=i386 | 32bit | 32bit ARCH=x86_64 | 64bit | 64bit The general rule are that ARCH= and native architecture takes precedence over the configuration. So make ARCH=i386 [whatever] will always build a 32-bit kernel no matter what the configuration says. The configuration will be updated to 32-bit if it was configured to 64-bit and the other way around. This behaviour is consistent with previous behaviour so no suprises here. make ARCH=x86 will per default result in a 32-bit kernel but as the only ARCH= value x86 allow the user to select between 32-bit and 64-bit using menuconfig. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Andreas Herrmann <aherrman@arcor.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
* | x86: reboot fixup for wrap2c boardDenys2007-11-17
| | | | | | | | | | | | | | | | Needed to make the wireless board, WRAP2C reboot. Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: check boundary in count setup resourceYinghai Lu2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so info->bus->resource[info->res_num] = res will not beyond of bus resource array when acpi returns too many resource entries. Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Gary Hade <gary.hade@us.ibm.com> Cc: Len Brown <lenb@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: add hpet sanity checksThomas Gleixner2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | Some BIOSes advertise HPET at 0x0. We really do no want to allocate a resource there. Check for it and leave early. Other BIOSes tell us the HPET is at 0xfed0000000000000 instead of 0xfed00000. Add a check and fix it up with a warning on user request. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: on x86_64, correct reading of PC RTC when update in progress in time_64.cDavid P. Reed2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correct potentially unstable PC RTC time register reading in time_64.c Stop the use of an incorrect technique for reading the standard PC RTC timer, which is documented to "disconnect" time registers from the bus while updates are in progress. The use of UIP flag while interrupts are disabled to protect a 244 microsecond window is one of the Motorola spec sheet's documented ways to read the RTC time registers reliably. tglx: removed locking changes from original patch, as they gain nothing (read_persistent_clock is only called during boot, suspend, resume - so no hot path affected) and conflict with the paravirt locking scheme (see 32bit code), which we do not want to complicate for no benefit. Signed-off-by: David P. Reed <dpreed@reed.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: fix freeze in x86_64 RTC update code in time_64.cDavid P. Reed2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix hard freeze on x86_64 when the ntpd service calls update_persistent_clock() A repeatable but randomly timed freeze has been happening in Fedora 6 and 7 for the last year, whenever I run the ntpd service on my AMD64x2 HP Pavilion dv9000z laptop. This freeze is due to the use of spin_lock(&rtc_lock) under the assumption (per a bad comment) that set_rtc_mmss is called only with interrupts disabled. The call from ntp.c to update_persistent_clock is made with interrupts enabled. Signed-off-by: David P. Reed <dpreed@reed.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: fixup cpu_info array conversionThomas Gleixner2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | 92cb7612aee39642d109b8d935ad265e602c0563 sets cpu_info->cpu_index to zero for no reason. Referencing cpu_info->cpu_index now points always to CPU#0, which is apparently not what we want. Remove it. Spotted-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: show cpuinfo only for online CPUsAndreas Herrmann2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix regressions introduced with 92cb7612aee39642d109b8d935ad265e602c0563. It can happen that cpuinfo is displayed for CPUs that are not online or even worse for CPUs not present at all. As an example, following was shown for a "second" CPU of a single core K8 variant: processor : 0 vendor_id : unknown cpu family : 0 model : 0 model name : unknown stepping : 0 cache size : 0 KB fpu : yes fpu_exception : yes cpuid level : 0 wp : yes flags : bogomips : 0.00 clflush size : 0 cache_alignment : 0 address sizes : 0 bits physical, 0 bits virtual power management: Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: fix cpu-hotplug regressionAndreas Herrmann2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit d435d862baca3e25e5eec236762a43251b1e7ffc ("cpu hotplug: mce: fix cpu hotplug error handling") changed the error handling in mce_cpu_callback. In cases where not all CPUs are brought up during boot (e.g. using maxcpus and additional_cpus parameters) mce_cpu_callback now returns NOTFIY_BAD because for such CPUs cpu_data is not completely filled when the notifier is called. Thus mce_create_device fails right at its beginning: if (!mce_available(&cpu_data[cpu])) return -EIO; As a quick fix I suggest to check boot_cpu_data for MCE. To reproduce this regression: (1) boot with maxcpus=2 addtional_cpus=2 on a 4 CPU x86-64 system (2) # echo 1 >/sys/devices/system/cpu/cpu2/online -bash: echo: write error: Invalid argument dmesg shows: _cpu_up: attempt to bring up CPU 2 failed Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: ignore the sys_getcpu() tcache parameterIngo Molnar2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dont use the vgetcpu tcache - it's causing problems with tasks migrating, they'll see the old cache up to a jiffy after the migration, further increasing the costs of the migration. In the worst case they see a complete bogus information from the tcache, when a sys_getcpu() call "invalidated" the cache info by incrementing the jiffies _and_ the cpuid info in the cache and the following vdso_getcpu() call happens after vdso_jiffies have been incremented. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: fix smp init sectionsRandy Dunlap2007-11-17
| | | | | | | | | | | | | | | | | | Fix Voyager section mismatch due to using __devinit instead of __cpuinit. WARNING: vmlinux.o(.text+0xd943): Section mismatch: reference to .init.text:init_gdt (between 'voyager_smp_prepare_boot_cpu' and 'smp_vic_cmn_interrupt') Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | x86: fix voyager_cat_init sectionRandy Dunlap2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix Voyager section mismatches: voyager_cat_init() should be __init. WARNING: vmlinux.o(.text+0xee83): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeea6): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeeac): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xeeb2): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xef4c): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xef56): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf10f): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf13b): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf14b): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf159): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1b1): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1bb): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1c1): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1c7): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk') WARNING: vmlinux.o(.text+0xf1e6): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk') Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds2007-11-16
|\ \ | |/ |/| | | | | | | | | * master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] Fix up whitespace in conservative governor. [CPUFREQ] Make cpufreq_conservative handle out-of-sync events properly [CPUFREQ] architectural pstate driver for powernow-k8
| * [CPUFREQ] architectural pstate driver for powernow-k8Mark Langsdorf2007-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch should apply cleanly to the 2.6.23-git7 kernel.  It changes the powernow-k8 driver code that deals with 3rd generation Opteron, Phenom, and later processors to match the architectural pstate driver described in the AMD64 Architecture Programmer's Manual Volume 2 Chapter 18.  The initial implementation of the hardware pstate driver for PowerNow! used some processor-version specific features, and would not be maintainable in the long term as the processor features changed. This architectural driver should work on all future AMD processors.   Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/x86Linus Torvalds2007-11-14
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/sam/x86: x86: enable "make ARCH=x86" x86: do not use $(ARCH) when not needed kconfig: use $K64BIT to set 64BIT with all*config targets kconfig: add helper to set config symbol from environment variable kconfig: factor out code in confdata.c x86: move the rest of the menu's to Kconfig x86: move all simple arch settings to Kconfig x86: copy x86_64 specific Kconfig symbols to Kconfig.i386 x86: add X86_64 dependency to x86_64 specific symbols in Kconfig.x86_64 x86: add X86_32 dependency to i386 specific symbols in Kconfig.i386 x86: arch/x86/Kconfig.cpu unification x86: start unification of arch/x86/Kconfig.* x86: unification of cfufreq/Kconfig
| * | x86: enable "make ARCH=x86"Sam Ravnborg2007-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After unification of the Kconfig files and introducing K64BIT support in kconfig it required only trivial changes to enable "make ARCH=x86". With this patch you can build for x86_64 in several ways: 1) make ARCH=x86_64 2) make ARCH=x86 K64BIT=y 3) make ARCH=x86 menuconfig => select 64-bit Likewise for i386 with the addition that i386 is default is you say ARCH=x86. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-24 00:36:53 -0500