- 30 Jan, 2008 40 commits
-
-
Jeremy Fitzhardinge authored
Signed-off-by:
Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Andrew Morton authored
WARNING: vmlinux.o(__ksymtab+0x670): Section mismatch: reference to .init.data:x86_cpu_to_node_map_init (between '__ksymtab_x86_cpu_to_node_map_init' and '__ksymtab_node_data') Cc: Matthew Dobson <colpatch@us.ibm.com> Cc: Mike Travis <travis@sgi.com> Cc: Christoph Lameter <clameter@sgi.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Mike Travis authored
Signed-off-by:
-
Jan Beulich authored
Based on patch from Jan Beulich <jbeulich@novell.com>. Don't rely on kmalloc(PAGE_SIZE) returning PAGE_SIZE aligned memory (Xen requires GDT *and* LDT to be page-aligned). Using the page allocator interface also removes the (albeit small) slab allocator overhead. The same change being done for 64-bits for consistency. Further, the Xen hypercall interface expects the LDT address to be virtual, not machine. [ Adjusted to unified ldt.c - Jeremy ] Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
-
Jan Beulich authored
Remove the dead .text.lock. Move _etext and __{start,stop}___ex_table into their sections. Signed-off-by: -
Alan Cox authored
I can find no reason for the _p on the serverworks IRQ routing logic, and a review of the documentation contains no indication that any such delay is needed so lets try this Signed-off-by:
-
Alan Cox authored
Rather than remove and/or mangle inb_p/outb_p we want to remove the use of them from inappropriate places. For the PIC/PIT this may eventually depend on 32/64bitism or similar so start by adding inb/outb_pit and inb/outb_pic so that we can make them use any scheme we settle on without disturbing the existing, correct (for ISA), port 0x80 usage. (eg we can make inb_pit use udelay without messing up inb_p). Floppy already does this for the fdc. That really only leaves the CMOS as a core logic item to tackle, and bits of parallel port handling in the chipset layers. Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Abhishek Sagar authored
Highlight peculiar cases in singles-step kprobe handling. In reenter_kprobe(), a breakpoint in KPROBE_HIT_SS case can only occur when single-stepping a breakpoint on which a probe was installed. Since such probes are single-stepped inline, identifying these cases is unambiguous. All other cases leading up to KPROBE_HIT_SS are possible bugs. Identify and WARN_ON such cases. Signed-off-by:
Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by:
-
Benjamin LaHaise authored
an otherwise idle system takes about 3 ticks per network interface in unregister_netdev() due to multiple calls to synchronize_rcu(), which adds up to quite a few seconds for tearing down thousands of interfaces. By flushing pending rcu callbacks in the idle loop, the system makes progress hundreds of times faster. If this is indeed a sane thing to, it probably needs to be done for other architectures than x86. And yes, the network stack shouldn't call synchronize_rcu() quite so much, but fixing that is a little more involved. Signed-off-by:
-
John Reiser authored
The ENDPROCs() were not used everywhere. Some code used just END() instead, while other code used nothing. um/sys-i386/checksum.S didn't #include <linux/linkage.h> . I also got confused because gcc puts the .type near the ENTRY, while ENDPROC puts it on the opposite end. Signed off by: John Reiser <jreiser@BitWagon.com> Signed-off-by:
-
Harvey Harrison authored
Add caller of is_errata93() to X86_32, ifdef'd to do nothing. Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Harvey Harrison authored
Comments, indentation, printk format. Uses task_pid_nr() on X86_64 now, but this is always defined to task->pid. Signed-off-by:
-
Harvey Harrison authored
Copy the prefetch of map_sem from X86_64 and move the check notify_page_fault (soon to be kprobe_handle_fault) out of the unlikely if() statement. This makes the X86_32|64 pagefault handlers closer to each other. Signed-off-by:
-
Harvey Harrison authored
is_prefetch was the last user of get_segment_eip and only on X86_32. This function returned the faulting instruction's address and set the upper segment limit. Instead, use the convert_ip_to_linear helper and rely on probe_kernel_address to do the segment checks which was already done everywhere the segment limit was being checked on X86_32. Remove get_segment_eip as well. Signed-off-by:
-
Harvey Harrison authored
Rename convert_rip_to_linear to convert_ip_to_linear for shared X86_32|64 use. Signed-off-by:
-
Harvey Harrison authored
Where x86_32 passed zero in the high 32 bits, use wrmsrl which will zero extend for us. This allows ifdefs for 32/64 bit to be eliminated. Eliminate ifdef in step.c. Similar cleanup was done when unifying kprobes_32|64.c and wrmsr() was chosen there over wrmsrl(). This patch changes these to wrmsrl. Signed-off-by:
-
travis@sgi.com authored
Change static bios_cpu_apicid array to a per_cpu data variable. This includes using a static array used during initialization similar to the way x86_cpu_to_apicid[] is handled. There is one early use of bios_cpu_apicid in apic_is_clustered_box(). The other reference in cpu_present_to_apicid() is called after smp_set_apicids() has setup the percpu version of bios_cpu_apicid. [ mingo@elte.hu: build fix ] Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
travis@sgi.com authored
Change the following static arrays sized by NR_CPUS to per_cpu data variables: acpi_cpufreq_data *drv_data[NR_CPUS] Signed-off-by:
-
travis@sgi.com authored
Change the following static arrays sized by NR_CPUS to per_cpu data variables: char cpu_to_node_map[NR_CPUS]; Signed-off-by:
-
travis@sgi.com authored
Clean up references to x86_cpu_to_apicid. Removes extraneous comments and standardizes on "x86_*_early_ptr" for the early kernel init references. Signed-off-by:
-
travis@sgi.com authored
Change the following static arrays sized by NR_CPUS to per_cpu data variables: i386_cpu cpu_devices[NR_CPUS]; (And change the struct name to x86_cpu.) Signed-off-by:
-
travis@sgi.com authored
Change the following static arrays sized by NR_CPUS to per_cpu data variables: task_struct *idle_thread_array[NR_CPUS]; This is only done if CONFIG_HOTPLUG_CPU is defined as otherwise, the array is removed after initialization anyways. Signed-off-by:
-
travis@sgi.com authored
Change the following static arrays sized by NR_CPUS to per_cpu data variables: powernow_k8_data *powernow_data[NR_CPUS]; Signed-off-by:
-
travis@sgi.com authored
Change the size of node ids from 8 bits to 16 bits to accomodate more than 256 nodes. Signed-off-by:
-
travis@sgi.com authored
Change the size of APICIDs from u8 to u16. This partially supports the new x2apic mode that will be present on future processor chips. (Chips actually support 32-bit APICIDs, but that change is more intrusive. Supporting 16-bit is sufficient for now). Signed-off-by:
Jack Steiner <steiner@sgi.com> I've included just the partial change from u8 to u16 apicids. The remaining x2apic changes will be in a separate patch. In addition, the fake_node_to_pxm_map[] and fake_apicid_to_node[] tables have been moved from local data to the __initdata section reducing stack pressure when MAX_NUMNODES and MAX_LOCAL_APIC are increased in size. Signed-off-by:
-
Chris Wright authored
Refactor ioport unification to pull out common code. Cc: mboton@gmail.com Cc: Kevin Winchester <kjwinchester@gmail.com> Cc: Zach Brown <zach.brown@oracle.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
-
Chris Wright authored
ioport unification was broken for 32-bit; it was missing the acutal pushf/popf EFLAGS manipulation (set_iopl_mask()). Also, use of volatile looks like leftover cruft. Cc: mboton@gmail.com Cc: Kevin Winchester <kjwinchester@gmail.com> Cc: Zach Brown <zach.brown@oracle.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
mboton@gmail.com authored
ioport_{32|64}.c unification. This patch unifies the code from the ioport_32.c and ioport_64.c files. Tested and working fine with i386 and x86_64 kernels. Signed-off-by:Miguel Botón <mboton@gmail.com> Signed-off-by:
-
Yinghai Lu authored
For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM installed. when try to use kexec second kernel, and the first doesn't include gart_shutdown. the second kernel could have different aper position than the first kernel. and second kernel could use that hole as RAM that is still used by GART set by the first kernel. esp. when try to kexec 2.6.24 with sparse mem enable from previous kernel (from RHEL 5 or SLES 10). the new kernel will use aper by GART (set by first kernel) for vmemmap. and after new kernel setting one new GART. the position will be real RAM. the _mapcount set is lost. Bad page state in process 'swapper' page:ffffe2000e600020 flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0 Trying to fix it up, but a reboot is needed Backtrace: Pid: 0, comm: swapper Not tainted 2.6.24-rc7-smp-gcdf71a10-dirty #13 Call Trace: [<ffffffff8026401f>] bad_page+0x63/0x8d [<ffffffff80264169>] __free_pages_ok+0x7c/0x2a5 [<ffffffff80ba75d1>] free_all_bootmem_core+0xd0/0x198 [<ffffffff80ba3a42>] numa_free_all_bootmem+0x3b/0x76 [<ffffffff80ba3461>] mem_init+0x3b/0x152 [<ffffffff80b959d3>] start_kernel+0x236/0x2c2 [<ffffffff80b9511a>] _sinittext+0x11a/0x121 and [ffffe2000e600000-ffffe2000e7fffff] PMD ->ffff81001c200000 on node 0 phys addr is : 0x1c200000 RHEL 5.1 kernel -53 said: PCI-DMA: aperture base @ 1c000000 size 65536 KB new kernel said: Mapping aperture over 65536 KB of RAM @ 3c000000 So could try to disable that GART if possible. According to Ingo > hm, i'm wondering, instead of modifying the GART, why dont we simply > _detect_ whatever GART settings we have inherited, and propagate that > into our e820 maps? I.e. if there's inconsistency, then punch that out > from the memory maps and just dont use that memory. > > that way it would not matter whether the GART settings came from a [old > or crashing] Linux kernel that has not called gart_iommu_shutdown(), or > whether it's a BIOS that has set up an aperture hole inconsistent with > the memory map it passed. (or the memory map we _think_ i tried to pass > us) > > it would also be more robust to only read and do a memory map quirk > based on that, than actively trying to change the GART so early in the > bootup. Later on we have to re-enable the GART _anyway_ and have to > punch a hole for it. > > and as a bonus, we would have shored up our defenses against crappy > BIOSes as well. add e820 modification for gart inconsistent setting. gart_fix_e820=off could be used to disable e820 fix. Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Signed-off-by:
-
Yinghai Lu authored
setup_node_zones() calcuates some variables but only use them when FLAT_NODE_MEM_MAP is set so change the MACRO postion to avoid calculating. also change it to static, and rename it to flat_setup_node_zones(). Signed-off-by:
-
Ingo Molnar authored
Signed-off-by:
-
Ingo Molnar authored
Signed-off-by:
-
Ingo Molnar authored
NOP change. Signed-off-by:
-
Ingo Molnar authored
These are useful in figuring out early-mapping problems. Signed-off-by:
-
Arjan van de Ven authored
printk_address()'s second parameter is the reliability indication, not the ebp. If we're printing regs->ip we're reliable by definition, so pass a 1 here. Signed-off-by: Arjan van de Ven Signed-off-by:
-
Arjan van de Ven authored
The 32 bit x86 tree has a very useful feature that prints the Code: line for the code even before the trapping instrution (and the start of the trapping instruction is then denoted with a <>). Unfortunately, the 64 bit x86 tree does not yet have this feature, making diagnosing backtraces harder than needed. This patch adds this feature in the same was as the 32 bit tree has (including the same kernel boot parameter), and including a bugfix to make the code use probe_kernel_address() rarther than a buggy (deadlocking) __get_user. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Arjan van de Ven authored
During the work on the x86 32 and 64 bit backtrace code I found it useful to have a simple test module to test a process and irq context backtrace. Since the existing backtrace code was buggy, I figure it might be useful to have such a test module in the kernel so that maybe we can even detect such bugs earlier.. [ mingo@elte.hu: build fix ] Signed-off-by:
-
Arjan van de Ven authored
x86 32 bit already has this feature: This patch uses the stack frames with frame pointer into an exact stack trace, by following the frame pointer. This only affects kernels built with the CONFIG_FRAME_POINTER config option enabled, and greatly reduces the amount of noise in oopses. This code uses the traditional method of doing backtraces, but if it finds a valid frame pointer chain, will use that to show which parts of the backtrace are reliable and which parts are not Due to the fragility and importance of the backtrace code, this needs to be well reviewed and well tested before merging into mainlne. Signed-off-by:
-
Arjan van de Ven authored
This patch turns the x86 64 bit HANDLE_STACK macro in the backtrace code into a function, just like 32 bit has. This is needed pre work in order to get exact backtraces for CONFIG_FRAME_POINTER to work. The function and it's arguments are not the same as 32 bit; due to the exception/interrupt stack way of x86-64 there are a few differences. This patch should not have any behavior changes, only code movement. Due to the fragility and importance of the backtrace code, this needs to be well reviewed and well tested before merging into mainlne. Signed-off-by:
-
Arjan van de Ven authored
Right now, we take the stack pointer early during the backtrace path, but only calculate bp several functions deep later, making it hard to reconcile the stack and bp backtraces (as well as showing several internal backtrace functions on the stack with bp based backtracing). This patch moves the bp taking to the same place we take the stack pointer; sadly this ripples through several layers of the back tracing stack, but it's not all that bad in the end I hope. Signed-off-by:
-
