- 25 Mar, 2006 40 commits
-
-
Andi Kleen authored
tcsh is not happy with the -9999 error code. Suggested by Ernie Petrides Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
I got an oops on a dual core system because the lost tick handler called cpufreq_get() on core 1 and powernow tried to follow a NULL powernow_data[] pointer there. Initialize powernow_data for all cores of a CPU. Cc: Jacob Shin <jacob.shin@amd.com> Cc: Dave Jones <davej@redhat.com> Signed-off-by:
-
Andi Kleen authored
No need to restrict to power of two here. TBD needs more double checking Signed-off-by:
-
Eric Dumazet authored
pfn_to_page() and others need to access both memnode_shift and the very first bytes of memnodemap[]. If we force memnode_shift to be just before the memnodemap array, we can reduce the memory footprint to one cache line instead of two for most setups. This patch introduce a 'memnode' structure where shift and map[] are carefully placed. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
Kevin Winchester authored
register_die_notifier is exported twice, once in traps.c and once in x8664_ksyms.c. This results in a warning on build. Signed-off-by:
Kevin Winchester <kwin@ns.sympatico.ca> Signed-off-by:
-
Navin Boppuri authored
arch/x86_64/kernel/aperture.c: The search for the AGP bridge has been extended to search for all the 256 buses instead of the first 32. This is required since on a some systems, the bridge may be located on a bus much farther than the first 32. By searching all 256 buses, we guarantee that the search succeeds on such systems. arch/x86_64/kernel/pci-gart.c: The search for the Northbridge is not limited to just bus 0 anymore. This is required because on certain systems, we may not find one on bus 0. Signed-off-by:
Navin Boppuri <navin.boppuri@newisys.com> Signed-off-by:
-
Andi Kleen authored
For consistency with other architectures Signed-off-by:
-
Jon Mason authored
Have the GART_IOMMU help text specify that this is the hardware IOMMU in amd64 processors. This will be significant if/when other IOMMUs are added to the x86-64 architecture. :-) Also, note that the previous help text stated that IOMMU was needed for >3GB memory instead of >4GB. This is fixed in the newer version. Signed-off-by:
Jon Mason <jdmason@us.ibm.com> Signed-off-by:
-
Andi Kleen authored
It was a failed experiment - all benchmarks done with it on both AMD and Intel showed it was a loss. That was probably because the store buffers of the CPUs for write combining traffic weren't large enough. Signed-off-by:
-
Andi Kleen authored
Spec just got published so we know the CPUID bit. Signed-off-by:
-
Jon Mason authored
free_bootmem_node expects a physical address to be passed in, but __alloc_bootmem_node returns a virtual one. That address needs to be translated to physical. Signed-off-by:
-
Vivek Goyal authored
o check_timer() routine fails while second kernel is booting after a crash on an opetron box. Problem happens because timer vector (0x31) seems to be locked. o After a system crash, it is not safe to service interrupts any more, hence interrupts are disabled. This leads to pending interrupts at LAPIC. LAPIC sends these interrupts to the CPU during early boot of second kernel. Other pending interrupts are discarded saying unexpected trap but timer interrupt is serviced and CPU does not issue an LAPIC EOI because it think this interrupt came from i8259 and sends ack to 8259. This leads to vector 0x31 locking as LAPIC does not clear respective ISR and keeps on waiting for EOI. o This patch issues extra EOI for the pending interrupts who have ISR set. o Though today only timer seems to be the special case because in early boot it thinks interrupts are coming from i8259 and uses mask_and_ack_8259A() as ack handler and does not issue LAPIC EOI. But probably doing it in generic manner for all vectors makes sense. Signed-off-by:
Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by:
-
Brian Gerst authored
cpu_vm_mask is of type cpumask_t, so use the proper bitops. Signed-off-by:
Brian Gerst <bgerst@didntduck.org> Signed-off-by:
-
Andi Kleen authored
This fixes problems with very large nodes (over 128GB) filling up all of the first 4GB with their mem_map and not leaving enough space for the swiotlb. Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
This means i386 processes compiled with a recent compiler will get non executable heap by default now. This is the same default as a 32bit PAE kernel would use on a NX enabled CPU. Signed-off-by:
-
Arjan van de Ven authored
This reorders the mmu_state int in the pda, such that there is no more padding (there currently is 4 bytes of padding). Boot tested. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Andi Kleen authored
Because 256 causes overflows in some code that stores them in 8 bit fields and the x86 APIC architecture cannot handle more than 255 anyways. Signed-off-by:
-
Chuck Ebbert authored
When x86_64 timer init messages were changed to use apic verbosity levels, two messages were missed and one got the wrong level. This causes the last word of a suppressed message to print on a line by itself. Fix that so either the entire message prints or none of it does. Signed-off-by:
Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by:
-
Andi Kleen authored
Only log data in microcode driver when something is changed Otherwise it was far too noisy on large systems. Also remove the printk when it is unloaded. Cc: tigran@veritas.com Signed-off-by:
-
Arjan van de Ven authored
This patch puts the infrastructure in place to allow for a reordering of functions based inside the vmlinux. The general idea is that it is possible to put all "common" functions into the first 2Mb of the code, so that they are covered by one TLB entry. This as opposed to the current situation where a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries. This is done by enabling the -ffunction-sections flag in gcc, which puts each function in its own ELF section, so that the linker can then order them in a way defined by the linker script. As per previous discussions, Linus said he wanted a "static" list for this, eg a list provided by the kernel tarbal, so that most people have the same ordering at least. A script is provided to create this list based on readprofile(1) output. The included list is provisional, and entirely biased on my own testbox and me running a few kernel compiles and some other things. I think that to get to a better list we need to invite people to submit their own profiles, and somehow add those all up and base the final list on that. I'm willing to do that effort if this is ends up being the prefered approach. Such an effort probably needs to be repeated like once a year or so to adopt to the changing nature of the kernel. Made it a CONFIG with default n because it increases link times dramatically. Signed-off-by:
-
Andi Kleen authored
I tested it on a couple of chipsets and it worked everywhere so it should be ok as default for now. So far I haven't done the great purge of the useless old check_timer code yet though. Can be overwritten with enable_8254_timer in the worst case Signed-off-by:
-
Andi Kleen authored
There is a fallback logic, so it's better to not use the OOM killer in the allocations. Signed-off-by:
-
Andi Kleen authored
Floppy can fall back to smaller buffers, so don't do OOM killing. Signed-off-by:
-
Andi Kleen authored
Was disabled due to an old bug, long gone. Signed-off-by:
-
Andi Kleen authored
Only white space changes, code should be identical Signed-off-by:
-
Andi Kleen authored
ACPIv2 has an official but optional way to get a date >2100. Use it. But all the platforms I tested didn't seem to support it. But anyways the x86-64 kernel should be ready for the 22nd century now. Actually i shouldn't care about this because I will be dead by then @) Signed-off-by:
-
Arjan van de Ven authored
This patch puts the code from head.S in a special .bootstrap.text section. I'm working on a patch to reorder the functions in the kernel (I'll post that later), but for x86-64 at least the kernel bootstrap requires that the head.S functions are on the very first page/pages of the kernel text. This is understandable since the bootstrap is complex enough already and not a problem at all, it just means they aren't allowed to be reordered. This patch puts these special functions into a separate section to document this, and to guarantee this in the light of possibly reordering the rest later. (So this patch doesn't fix a bug per se, but makes things more robust by making the order of these functions explicit) Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
There are more and more cases where we need to know DMI information early to work around bugs. i386 already had early DMI scanning, but x86-64 didn't. Implement this now. This required some cleanup in the i386 code. Signed-off-by:
-
Andi Kleen authored
- Move the core parser into dmi_scan.c. It can be useful for other subsystems too. - Differentiate between field doesn't exist and field is 0 or unparseable. The first case is likely an old BIOS with broken ACPI, the later is likely a slightly buggy BIOS where someone forget to edit the date. Don't blacklist in the later case. Signed-off-by:
-
Dave Jones authored
s/Overwrite/Override/ Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Andi Kleen authored
As suggested by Andi (and Alan), move the default kernel location from 1Mb to 2Mb, to align to the start of a TLB entry. Signed-off-by:
-
Arjan van de Ven authored
In a micro-benchmark that stresses the pagefault path, the down_read_trylock on the mmap_sem showed up quite high on the profile. Turns out this lock is bouncing between cpus quite a bit and thus is cache-cold a lot. This patch prefetches the lock (for write) as early as possible (and before some other somewhat expensive operations). With this patch, the down_read_trylock basically fell out of the top of profile. Signed-off-by:
-
Andi Kleen authored
Not for the ioctls so far because I was too lazy. Cc: bcollins@debian.org Cc: dan@dennedy.org Signed-off-by:
-
Ravikiran G Thirumalai authored
phys_proc_id[] on AMD boxes is right now populated with the initial apic id, obtained by the cpuid instruction. But, the initial apic id need not be the local apic id on clustered APIC systems (see comment at x86_64/kernel/genapic_cluster.c, line 110). On vSMPowered with AMD CPUs the cpu_to_node will turn out to be incorrect (as apicid_to_node[] is indexed by the initial apic id rather than the local apic id). On vSMPowered boxes with Intel CPUs this is working correctly as phys_proc_id[] is initialized correctly in detect_ht(). This fixes AMD boot path according to specification, to use the correct routines for local apic id and socket ids. We use hard_smp_processor_id() to read the local apic id, and phys_pkg_id() to determine socket id for phys_proc_id[] Patch tested on Tyan multicore boxes as well as vSMPowered boxes. Signed-off-by:
Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by:
Shai Fultheim <shai@scalex86.org> Signed-off-by:
-
Jan Beulich authored
- adjust limits of GDT/IDT pseudo-descriptors (some were off by one) - move empty_zero_page into .bss.page_aligned - move cpu_gdt_table into .data.page_aligned - move idt_table into .bss - align inital_code and init_rsp - eliminate pointless (re-)declaration of idt_table in traps.c Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
Andi Kleen authored
It needs num_physpages, so initialize it early. It's later overwritten again. Signed-off-by:
-
Roberto Nibali authored
Attached is a small code style cleanup patch that resulted from my skimming through the arch/x86_64/kernel/traps.c code to figure out what went haywire. Signed-off-by:
Roberto Nibali <ratz@drugphish.ch> Signed-off-by:
-
Henrik Kretzschmar authored
[description by AK] Made a cut'n'paste error when adding the entry for the ALI M1695 AGP bridge and added a second entry for the 1689 Cc: Dave Jones <davej@redhat.com> Signed-off-by:
-
