- 13 2月, 2007 40 次提交
-
-
由 Rusty Russell 提交于
When I implemented the DECLARE_PER_CPU(var) macros, I was careful that people couldn't use "var" in a non-percpu context, by prepending percpu__. I never considered that this would allow them to overload the same name for a per-cpu and a non-percpu variable. It is only one of many horrors in the i386 boot code, but let's rename the non-perpcu cpu_gdt_descr to early_gdt_descr (not boot_gdt_descr, that's something else...) Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NAndi Kleen <ak@suse.de> ===================================================================
-
由 Rusty Russell 提交于
Allows external actors to disable mce. Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NAndi Kleen <ak@suse.de> ===================================================================
-
由 Rusty Russell 提交于
The current code simply calls "start_kernel" directly if we're under a hypervisor and no paravirt_ops backend wants us, because paravirt.c registers that as a backend. This was always a vain hope; start_kernel won't get far without setup. It's also impossible for paravirt_ops backends which don't sit in the arch/i386/kernel directory: they can't link before paravirt.o anyway. Keep it simple: if we pass all the registered paravirt probes, BUG(). Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Ralf Baechle 提交于
> Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Signed-off-by: NRalf Baechle <ralf@linux-mips.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
and in other strange binfmts. vDSO is not necessarily mapped there. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Alan 提交于
The old Cyrix 5520 CPU detection code relied upon the PCI layer setup being done earlier than the CPU setup, which is no longer true. Fortunately we know that if the processor is a MediaGX we can do type 1 pci config accesses to check the companion chip. We thus do those directly and from this find the 5520 and implement the workarounds for the timer problem Original report from takada@mbf.nifty.com, I sent a proposed patch which Takara then corrected, tested and sent back to the list on 10th January. Submitting for merging as it seems to have been missed AK: Changed to use pci-direct.h and fix warning for !CONFIG_PCI (later AK: originally from akpm) Signed-off-by: NAlan Cox <alan@redhat.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: <takada@mbf.nifty.com> Cc: Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Andi Kleen 提交于
Fix bogus warning linux/arch/i386/kernel/cpu/transmeta.c:12: warning: ‘cpu_freq’ may be used uninitialized in this function Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Fix bogus gcc warning linux/arch/i386/kernel/microcode.c:387: warning: ‘new_mc’ may be used uninitialized in this function Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
For i386/x86-64. Straight forward -- just reuse the Family 0xf code. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Just various new acronyms. The new popcnt bit is in the middle of Intel space. This looks a little weird, but I've been assured it's ok. Also I fixed RDTSCP for i386 which was at the wrong place. For i386 and x86-64. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Not needed because fastcall is always default now Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
gcc 5.0 will likely not have the constraint problem Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Eric W. Biederman 提交于
Occasionally the kernel has bugs that result in no irq being found for a given cpu vector. If we acknowledge the irq the system has a good chance of continuing even though we dropped an irq message. If we continue to simply print a message and not acknowledge the irq the system is likely to become non-responsive shortly there after. AK: Fixed compilation for UP kernels Signed-off-by: NEric W. Biederman <ebiederm@xmission.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: "Luigi Genoni" <luigi.genoni@pirelli.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 TAKADA Yoshihito 提交于
Original code doesn't write back to CCR4 register. This patch reflects a value of a register. Cc: Jordan Crouse <jordan.crouse@amd.com> Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> Cc: Andi Kleen <ak@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Chuck Ebbert 提交于
Sometimes developers need to see more object code in an oops report, e.g. when kernel may be corrupted at runtime. Add the "code_bytes" option for this. Signed-off-by: NChuck Ebbert <cebbert@redhat.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Evgeniy Polyakov 提交于
If DEBUG_SIG is enbaled in source code, ia32_signal.c compiles with warning due to wrong format string. Attached patch fixes that. It is quite minor update, since by default DEBUG_SIG is not enabled and can not be turned on without code modification. Signed-off-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Roland Dreier 提交于
I've seen my box paralyzed by an endless spew of rtc: lost some interrupts at 1024Hz. messages on the serial console. What seems to be happening is that something real causes an interrupt to be lost and triggers the message. But then printing the message to the serial console (from the hpet interrupt handler) takes more than 1/1024th of a second, and then some more interrupts are lost, so the message triggers again.... Fix this by adding a printk_ratelimit() before printing the warning. Signed-off-by: NRoland Dreier <rolandd@cisco.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Benjamin Romer 提交于
On the Unisys ES7000/ONE system, we encountered a problem where performing a kexec reboot or dump on any cell other than cell 0 causes the system timer to stop working, resulting in a hang during timer calibration in the new kernel. We traced the problem to one line of code in disable_IO_APIC(), which needs to restore the timer's IO-APIC configuration before rebooting. The code is currently using the 4-bit physical destination field, rather than using the 8-bit logical destination field, and it cuts off the upper 4 bits of the timer's APIC ID. If we change this to use the logical destination field, the timer works and we can kexec on the upper cells. This was tested on two different cells (0 and 2) in an ES7000/ONE system. For reference, the relevant Intel xAPIC spec is kept at ftp://download.intel.com/design/chipsets/e8501/datashts/30962001.pdf, specifically on page 334. Signed-off-by: NBenjamin M Romer <benjamin.romer@unisys.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Robert P. J. Day 提交于
Remove the unused kernel config option X86_XADD, which is unused in any source or header file. Signed-off-by: NRobert P. J. Day <rpjday@mindspring.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@muc.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Bob Picco 提交于
Eliminate arch specific memory_present call x86_64 NUMA by utilizing sparse_memory_present_with_active_regions. Acked-by: NMel Gorman <mel@csn.ul.ie> Signed-off-by: NBob Picco <bob.picco@hp.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@muc.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Jan Beulich 提交于
Annotate i386/kernel/entry.S with END/ENDPROC to assist disassemblers and other analysis tools. Signed-off-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 takada 提交于
I hope to support "classic" MediaGXm in kernel. The DIR1 register of MediaGXm( or Geode) shows the following values for identify CPU. For example, My MediaGXm shows 0x42. We can read National Semiconductor's datasheet without any NDAs. http://www.national.com/pf/GX/GXLV.html from datasheets: DIR1 0x30 - 0x33 GXm rev. 1.0 - 2.3 0x34 - 0x4f GXm rev. 2.4 - 3.x 0x5x GXm rev. 5.0 - 5.4 0x6x GXLV 0x7x (unknow) 0x8x Gx1 In nsc driver of X, accept 0x30 through 0x82. What will 0x7x mean? Cc: Jordan Crouse <jordan.crouse@amd.com> Cc: Andi Kleen <ak@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Randy Dunlap 提交于
setcc() in math-emu is written as a gcc extension statement expression macro that returns a value. However, it's not used that way and it's not needed like that, so just make it a inline function so that we don't use an extension when it's not needed. Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: Christoph Hellwig <hch@infradead.org> Cc: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 H. Peter Anvin 提交于
All Transmeta CPUs ever produced have constant-rate TSCs. Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Ingo Molnar 提交于
During kernel bootup, a new T60 laptop (CoreDuo, 32-bit) hangs about 10%-20% of the time in acpi_init(): Calling initcall 0xc055ce1a: topology_init+0x0/0x2f() Calling initcall 0xc055d75e: mtrr_init_finialize+0x0/0x2c() Calling initcall 0xc05664f3: param_sysfs_init+0x0/0x175() Calling initcall 0xc014cb65: pm_sysrq_init+0x0/0x17() Calling initcall 0xc0569f99: init_bio+0x0/0xf4() Calling initcall 0xc056b865: genhd_device_init+0x0/0x50() Calling initcall 0xc056c4bd: fbmem_init+0x0/0x87() Calling initcall 0xc056dd74: acpi_init+0x0/0x1ee() It's a hard hang that not even an NMI could punch through! Frustratingly, adding printks or function tracing to the ACPI code made the hangs go away ... After some time an additional detail emerged: disabling the NMI watchdog made these occasional hangs go away. So i spent the better part of today trying to debug this and trying out various theories when i finally found the likely reason for the hang: if acpi_ns_initialize_devices() executes an _INI AML method and an NMI happens to hit that AML execution in the wrong moment, the machine would hang. (my theory is that this must be some sort of chipset setup method doing stores to chipset mmio registers?) Unfortunately given the characteristics of the hang it was sheer impossible to figure out which of the numerous AML methods is impacted by this problem. As a workaround i wrote an interface to disable chipset-based NMIs while executing _INI sections - and indeed this fixed the hang. I did a boot-loop of 100 separate reboots and none hung - while without the patch it would hang every 5-10 attempts. Out of caution i did not touch the nmi_watchdog=2 case (it's not related to the chipset anyway and didnt hang). I implemented this for both x86_64 and i686, tested the i686 laptop both with nmi_watchdog=1 [which triggered the hangs] and nmi_watchdog=2, and tested an Athlon64 box with the 64-bit kernel as well. Everything builds and works with the patch applied. Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: Len Brown <lenb@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Muli Ben-Yehuda 提交于
- set bad_dma_address explicitly to 0x0 - reserve 32 pages from bad_dma_address and up - WARN_ON() a driver feeding us bad_dma_address Thanks to Leo Duran <leo.duran@amd.com> for the suggestion. Signed-off-by: NMuli Ben-Yehuda <muli@il.ibm.com> Signed-off-by: NAndi Kleen <ak@suse.de> Cc: Leo Duran <leo.duran@amd.com> Cc: Job Mason <jdmason@kudzu.us>
-
由 Jeff Garzik 提交于
x86-64 is missing these: Signed-off-by: NJeff Garzik <jeff@garzik.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
We trust the e820 table, so explicitely reserving ROMs shouldn't be needed. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
Should be harmless because there is normally no memory there, but technically it was incorrect. Pointed out by Leo Duran Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Zachary Amsden 提交于
Initialize FS and GS to __KERNEL_DS as well. The actual value of them is not important, but it is important to reload them in protected mode. At this time, they still retain the real mode values from initial boot. VT disallows execution of code under such conditions, which means hardware virtualization can not be used to boot the kernel on Intel platforms, making the boot time painfully slow. This requires moving the GS load before the load of GS_BASE, so just move all the segments loads there to keep them together in the code. Signed-off-by: NZachary Amsden <zach@vmware.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
The symbol is needed to manipulate page tables, and modules shouldn't do that. Leftover from 2.4, but no in tree module should need it now. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
This means if an illegal value is set for the segment registers there ptrace will error out now with an errno instead of silently ignoring it. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Jack Steiner 提交于
Add failsafe mechanism to HPET/TSC clock calibration. Signed-off-by: NJack Steiner <steiner@sgi.com> Updated to include failsafe mechanism & additional community feedback. Patch built on latest 2.6.20-rc4-mm1 tree. Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andreas Herrmann 提交于
mtrr: fix size_or_mask and size_and_mask This fixes two bugs in /proc/mtrr interface: o If physical address size crosses the 44 bit boundary size_or_mask is evaluated wrong. o size_and_mask limits width of physical base address for an MTRR to be less than 44 bits. TBD: later patch had one more change, but I think that was bogus. TBD: need to double check Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Alexey Dobriyan 提交于
Byte-to-byte identical /proc/apm here. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Josef 'Jeff' Sipek 提交于
Old code was legal standard C, but apparently not sparse-C. Signed-off-by: NJosef 'Jeff' Sipek <jsipek@cs.sunysb.edu> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Alexey Dobriyan 提交于
It will execure cpuid only on the cpu we need. Signed-off-by: NAlexey Dobriyan <adobriyan@openvz.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Alexey Dobriyan 提交于
It will execute rdmsr and wrmsr only on the cpu we need. Signed-off-by: NAlexey Dobriyan <adobriyan@openvz.org> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Nicolas Kaiser 提交于
Some typos in Kconfig. Signed-off-by: NNicolas Kaiser <nikai@nikai.net> Signed-off-by: NAndi Kleen <ak@suse.de>
-
由 Andi Kleen 提交于
- Remove outdated comment - Use cpu_relax() in a busy loop Signed-off-by: NAndi Kleen <ak@suse.de>
-