- 06 Jan, 2006 40 commits
-
-
Ashok Raj authored
When we bring up a new CPU via INIT/startup IPI messages, the CPU that's coming up sends a xTPR message to the chipset. Intel chipsets (at least) don't provide any architectural guarantee on what the chipset will do with this message. For example, the E850x chipsets uses this xTPR message to interpret the interrupt operating mode of the platform. When the CPU coming online sends this message, it always indicates that it is in logical flat mode. For the CPU hotplug case, the platform may already be functioning in cluster APIC mode at this time, the chipset can get confused and mishandle I/O device and IPI interrupt routing. The situation eventually gets corrected when the new CPU sends another xTPR update when we switch it to cluster mode, but there's a window during which the chipset may be in an inconsistent state. This patch avoids this problem by using the flat physical interrupt delivery mode instead of cluster mode for bigsmp (>8 cpu) support. Signed-off-by:
Ashok Raj <ashok.raj@intel.com> Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Anton Blanchard authored
On architectures that implement sparsemem but not discontigmem we want to be able to hide the flatmem option in some cases. On ppc64 for example, when we select NUMA we must not select flatmem. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Signed-off-by:
-
Andy Whitcroft authored
Allow SPARSEMEM to be enabled on non-numa x86 systems. This is made dependant on EXPERIMENTAL also being set. When an in-tree user (such as simulated numa) exists it should be made dependant on that. The plan is to have no options and no selector as normal when !EXPERIMENTAL. When EXPERIMENTAL we enable the FLATMEM and SPARSEMEM options for X86_PC whilst maintaining DISCONTIGMEM and SPARSEMEM for NUMA. Signed-off-by:
-
Arjan van de Ven authored
Mark some key kernel datastructures readonly. This patch was previously posted on Jun 28th but was back then not merged because nothing was enforcing rodata anyway.. well that changed now :) Patch by Christoph Lameter <christoph@lameter.com> and Dave Jones <davej@redhat.com> Signed-off-by:
Arjan van de Ven <arjan@infradead.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
Arjan van de Ven authored
x86-64 specific parts to make the .rodata section read only Signed-off-by:
-
Arjan van de Ven authored
Bug fix required for the .rodata work on x86-64: when change_page_attr() and friends need to break up a 2Mb page into 4Kb pages, it always set the NX bit on the PMD, which causes the cpu to consider the entire 2Mb region to be NX regardless of the actual PTE perms. This is fine in general, with one big exception: the 2Mb page that covers the last part of the kernel .text! The fix is to not invent a new permission for the new PMD entry, but to just inherit the existing one minus the PSE bit. Signed-off-by:
-
Arjan van de Ven authored
x86 specific parts to make the .rodata section read only Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
Arjan van de Ven authored
Generic prep-work for marking the .rodata section readonly: * Align the rodata section at 4Kb boundary * call the mark_rodata_ro() function when available Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
David Howells authored
Make i386's find_first_bit() use an unsigned integer as a counter to avoid getting warnings when -Wsign-compare is given. Signed-Off-By:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Zachary Amsden authored
Remove the "temporary debugging check" which has managed to live for quite some time, and is clearly unneeded. The mm can never be live at this point, so clearly checking the LDT in the mm->context is redundant as well. Signed-off-by:
Zachary Amsden <zach@vmware.com> Cc: "Seth, Rohit" <rohit.seth@intel.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Zachary Amsden authored
APM BIOS code has a protective wrapper that runs it only on CPU zero. Thus, no need to set APM BIOS segments in the GDT for other CPUs. Signed-off-by:
"Seth, Rohit" <rohit.seth@intel.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Zachary Amsden authored
Stop deleting NT bit from EFLAGS. See arch/i386/kernel/head.S line 223, which does something even better. Signed-off-by:
-
Zachary Amsden authored
PnP BIOS data, code, and 32-bit entry segments all have fixed limits as well; set them in the GDT rather than adding more code. It would be nice to add these fixups to the boot GDT rather than setting the GDT for each CPU; perhaps I can wiggle this in later, but getting it in before the subsys init looks tricky. Also, make some progress on deprecating the ugly Q_SET_SEL macros. Signed-off-by:
-
Zachary Amsden authored
The one remaining caller of set_limit, the PnP BIOS code, calls into the PnP BIOS, passing kernel parameters in and out. These parameteres may be passed from arbitrary kernel virtual memory, so they deserve strict protection to stop a bad BIOS from smashing beyond the object size. Unfortunately, the use of set_limit was badly botching this by setting the limit in terms of pages, when it really should have byte granularity. When doing this, I discovered my BIOS had the buggy code during the "get system device node" call: mov ax, es:[bx] Which is harmless, but has a trivial workaround. Signed-off-by:
-
Zachary Amsden authored
Old accessors to fetch LDT descriptors are unused and outdated and in the wrong header file. Signed-off-by:
-
Zachary Amsden authored
Since APM BIOS segment limits are now fixed, set them in head.S GDT and don't use the complicated _set_limit() macro expansion. Signed-off-by:
-
Zachary Amsden authored
APM BIOSes have many bugs regarding proper representation of the appropriate segment limits for calling the BIOS. By default, APM_RELAX_SEGMENTS is always turned on to support running the APM BIOS on these buggy machines. Keeping 64k limits poses very little danger to the kernel, because the pages where the APM BIOS is located will always be in low physical memory BIOS areas, which should already be marked reserved, and only buggy BIOSes would possibly overstep the segment bounds with writes to data anyway. Since forcing stricter limits breaks many machines and is not default behavior, it seems reasonable to deprecate the older code which may cause APM BIOS to fault. If you really have a badly enough broken APM BIOS that you have to turn off APM_RELAX_SEGMENTS, seems like the best recourse here would be to disable the APM BIOS and / or not compile it into your kernel to begin with, and / or add your system to the known bad list. The reason I want to deprecate this code is there is underlying brokenness with the set_limit macros, and getting rid of many of the call sites rather than rewriting them seems to be the simplest and most correct course of action. Signed-off-by:
-
Zachary Amsden authored
Move PnP BIOS segment definitions into segment.h; the segments are reserved here, so they might as well be defined here as well. Note I didn't do this for APM BIOS, as Macintosh and other systems use those values to emulate APM in some scary way I don't want to understand. Signed-off-by:
-
Zachary Amsden authored
So some 486 processors do have CR4 register. Allow them to present it in register dumps by using the old fault technique rather than testing processor family. Thanks to Maciej for noticing this. Signed-off-by:
-
Jan Beulich authored
Other than apparently commonly assumed, the bound instruction does not require the corresponding IDT entry to have DPL 3. Acked-by:
-
Jan Beulich authored
Move some code unrelated to any dealing with hardware bugs from i386's bugs.h to a more logical place. Signed-off-by:
-
Jan Beulich authored
Rather than blindly re-enabling interrupts in die(), save their state upon entry and then restore that state. If the kernel is in really bad condition and faults with interrupts disabled, re-enabling them in die() may cause even more trouble, implying more chances of data corruption. Signed-off-by:
-
Zachary Amsden authored
Make GDT page aligned and page padded to support running inside of a hypervisor. This prevents false sharing of the GDT page with other hot data, which is not allowed in Xen, and causes performance problems in VMware. Rather than go back to the old method of statically allocating the GDT (which wastes unneded space for non-present CPUs), the GDT for APs is allocated dynamically. Signed-off-by:
-
Domen Puncer authored
Remove nowhere referenced file ("grep riscos -r ." didn't find anything). Signed-off-by:Domen Puncer <domen@coderock.org> Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
David Howells authored
The attached patch improves the signal handling: (1) It makes do_signal() static as it isn't called from anywhere outside of the arch code. (2) It removes the regs argument to all the static functions within that file, using __frame instead (which is the same thing held in a global register). Signed-off-by: -
David Howells authored
The attached patch makes FRV signal handling work properly: (1) After do_notify_resume() has been called, the work flags must be checked again (there may be another signal to deliver or the process might require rescheduling for instance). (2) After the signal frame is set up on the userspace stack, ptrace() should be given an opportunity to single-step into the signal handler. (3) The error state from setting up a signal frame should be passed back up the call chain. (4) The segfault handler shouldn't be preemptively reset in the arch if we fail to deliver a SEGV signal: force_sig() will take care of that. Signed-off-by: -
David Howells authored
Make the futex code compilable and usable on NOMMU by making the attempt to handle page faults conditional on CONFIG_MMU. If this is not enabled, then we can assume that EFAULT returned from futex_atomic_op_inuser() is not recoverable, and that the address lies outside of valid memory. handle_mm_fault() is made to BUG if called on NOMMU without attempting to invoke the actual handler (__handle_mm_fault). Signed-off-by:
-
David Howells authored
The attached patch implements futex operations for the FRV architecture. The operations are applicable to both MMU and no-MMU modes; though the EFAULT handling will be a little bit of wasted space on the latter. Signed-off-by:
-
David Howells authored
The attached patch makes the SYSV IPC shared memory facilities use the new ramfs facilities on a no-MMU kernel. The following changes are made: (1) There are now shmem_mmap() and shmem_get_unmapped_area() functions to allow the IPC SHM facilities to commune with the tiny-shmem and shmem code. (2) ramfs files now need resizing using do_truncate() rather than by modifying the inode size directly (see shmem_file_setup()). This causes ramfs to attempt to bind a block of pages of sufficient size to the inode. (3) CONFIG_SYSVIPC is no longer contingent on CONFIG_MMU. Signed-off-by: -
David Howells authored
The attached patch makes ramfs support shared-writable mmaps by: (1) Attempting to perform a contiguous block allocation to the requested size when truncate attempts to increase the file from zero size, such as happens when: fd = shm_open("/file/on/ramfs", ...): ftruncate(fd, size_requested); addr = mmap(NULL, subsize, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED, fd, offset); (2) Permitting any shared-writable mapping over any contiguous set of extant pages. get_unmapped_area() will return the address into the actual ramfs pages. The mapping may start anywhere and be of any size, but may not go over the end of file. Multiple mappings may overlap in any way. (3) Not permitting a file to be shrunk if it would truncate any shared mappings (private mappings are copied). Thus this patch provides support for POSIX shared memory on NOMMU kernels, with certain limitations such as there being a large enough block of pages available to support the allocation and it only working on directly mappable filesystems. Signed-off-by: -
Ben Collins authored
Only output the messages about fan speed changes with a verbose=1 module param. Signed-off-by:
Fabio M. Di Nitto <fabbione@ubuntu.com> Signed-off-by:
Ben Collins <bcollins@ubuntu.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Peter Korsgaard authored
Commit 3e9e7c1d (ppc32: cleanup AMCC PPC40x eval boards to support U-Boot) broke the kernel for ML300 / EP405. It still compiles as there's a weak definition of the function in misc-embedded.c, but the kernel crashes as the bd_t fixup isn't performed. Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Cc: <stable@kernel.org> Signed-off-by:
-
Sylvain Munaut authored
Some custom cards might not need PCI, without this patch, compilation fails. Signed-off-by:
Roger Blofeld <blofeldus@yahoo.com> Signed-off-by:
Sylvain Munaut <tnt@246tNt.com> Signed-off-by:
-
Sylvain Munaut authored
We were counting on the bootloader to init some stuff, like get the bus out of reset and enable accesses. Signed-off-by:
-
Sylvain Munaut authored
This patch takes care of an errata of the MPC5200 by avoiding 32 bits access in type 1 configuration accesses. All others accesses are still 32 bits wide. It also adds some mb() since the simple out_be(...) are not sufficient in this case. Signed-off-by:
-
Sylvain Munaut authored
The mpc52xx_pci_fixup_resources is not only called at init but also when there is a pci hotplug like when a cardbus card is plugged in. So that function is needed after init too. Thanks to Asier Llano Palacios for reporting this. Signed-off-by:
-
Sylvain Munaut authored
AFAIK IRQ number 0 is a perfectly valid IRQ number. But it seems there are numerous places where it's considered to be invalid or "no irq" value. Since that value is problematic, the IRQ mapping is changed to not use it. Signed-off-by:
-
Sylvain Munaut authored
The current iomapping used MBAR_SIZE for the size argument of io_block_mapping, resulting in a call to setbat with a size argument of 64k which is invalid. This patch correct this and maps the whole 0xf0000000->0xffffffff range so that devices on the local bus are also included in the BAT mapping. Thanks to Bernhard Kuhn from Metrowerks for pointing this out. Signed-off-by:
-
Sylvain Munaut authored
Before this patch we were just using the "classic" /dev/ttySx devices. However when another on the system is loaded that uses those (like drivers for serial PCMCIA), that creates a conflict for the minors. Therefore, we now use /dev/ttyPSC[0:5] (note the 0-based numbering !) with some minors we've been assigned in the "Low Density Serial port major" Signed-off-by:
-
Sylvain Munaut authored
Signed-off-by:
Wolfgang Denk <wd@denx.de> Signed-off-by:
-
