aboutsummaryrefslogtreecommitdiffstats
path: root/arch/ia64/kernel/efi.c
Commit message (Collapse)AuthorAge
* always reserve elfcore header memory in crash kernelSimon Horman2008-10-20
| | | | | | | | | | | elfcore header memory needs to be reserved in a crash kernel. This means that the relevant code should be protected by CONFIG_CRASH_DUMP rather than CONFIG_PROC_VMCORE. Signed-off-by: Simon Horman <horms@verge.net.au> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [IA64] kexec fails on systems with blocks of uncached memoryJay Lan2008-09-22
| | | | | | | | | | | | | | | | | | Currently a memory segment in memory map with attribute of EFI_MEMORY_UC is denoted as "System RAM" in /proc/iomem, while memory of attribute (EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same. The kexec utility then includes uncached memory as part of vmcore. The kdump kernel MCA'ed when it tries to save the vmcore to a disk. A normal "cached" access may cause MCAs. This patch would label memory with attribute of EFI_MEMORY_UC only as "Uncached RAM" so that kexec would know not to include it in the vmcore. I will submit a separate kexec-tools patch to the kexec list. Signed-off-by: Jay Lan <jlan@sgi.com> Acked-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] Kernel parameter for max number of concurrent global TLB purgesFenghua Yu2008-04-04
| | | | | | | | | The patch defines kernel parameter "nptcg=". The parameter overrides max number of concurrent global TLB purges which is reported from either PAL_VM_SUMMARY or SAL PALO. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] Multiple outstanding ptc.g instruction supportFenghua Yu2008-04-04
| | | | | | | | | | | | | | | | | | | | According to SDM2.2, Itanium supports multiple outstanding ptc.g instructions. But current kernel function ia64_global_tlb_purge() uses a spinlock to serialize ptc.g instructions issued by multiple processors. This serialization might have scalability issue on a big SMP machine where many processors could purge TLB in parallel. The patch fixes this problem by issuing multiple ptc.g instructions in ia64_global_tlb_purge(). It also adds support for the "PALO" table to get a platform view of the max number of outstanding ptc.g instructions (which may be different from the processor view found from PAL_VM_SUMMARY). PALO specification can be found at: http://www.dig64.org/home/DIG64_PALO_R1_0.pdf spinaphore implementation by Matthew Wilcox. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] update efi region debugging to use MB, GB and TB as well as KBSimon Horman2008-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When EFI_DEBUG is defined to a non-zero value in arch/ia64/kernel/efi.c, the efi memory regions are displayed. This patch enhances the display code in a few ways: 1. Use TB, GB and MB as well as KB as units. Although this introduces rounding errors (KB doesn't as size is always a multiple of 4Kb), it does make things a lot more readable. Also as the range is also shown, it is possible to note the exact size if it is important. In my experience, the size field is mostly useful for getting a general idea of the size of a region. On the rx2620 that I use, there actually is an 8TB region (though not backed by physical memory, and 8TB really is a lot more readable than 8589934592KB. 2. pad the size field with leading spaces to further improve readability ... ... ( 8MB) ... ( 928MB) ... ( 3MB) ... vs ... ... (8MB) ... (928MB) ... (3MB) ... 3. Pad the attr field out to 64bits using leading zeros, to further improve readability. ... mem05: type= 2, attr=0x0000000000000008, range=[0x0000000004000000-0x000000000481f000) ( 8MB) mem06: type= 7, attr=0x0000000000000008, range=[0x000000000481f000-0x000000003e876000) ( 928MB) mem07: type= 5, attr=0x8000000000000008, range=[0x000000003e876000-0x000000003eb8e000) ( 3MB) mem08: type= 4, attr=0x0000000000000008, range=[0x000000003eb8e000-0x000000003ee7a000) ( 2MB) ... ... mem05: type= 2, attr=0x8, range=[0x0000000004000000-0x000000000481f000) ( 8MB) mem06: type= 7, attr=0x8, range=[0x000000000481f000-0x000000003e876000) ( 928MB) mem07: type= 5, attr=0x8000000000000008, range=[0x000000003e876000-0x000000003eb8e000) ( 3MB) mem08: type= 4, attr=0x8, range=[0x000000003eb8e000-0x000000003ee7a000) ( 2MB) ... 4. Use %d instead of %u for the index field, as i is a signed int. N.B: This code is not compiled unless EFI_DEBUG is non 0. Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] remove remaining __FUNCTION__ occurrencesHarvey Harrison2008-03-06
| | | | | | | | | | | __FUNCTION__ is gcc-specific, use __func__ Long lines have been kept where they exist, some small spacing changes have been done. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] ia64_set_psr should use srlz.iXiantao Zhang2008-02-04
| | | | | | | | | The only in kernel use of ia64_set_psr() needs to follow it with a srlz.i (since it is changing state for PSR.ic). So it is pointless to issue srlz.d inside this function. Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] efi.c Add /* never reached */ annotationAron Griffis2008-02-04
| | | | | | | | As written, this loop could be for (;;) instead of do while (md). The tests inside the loop always result in a return so the loop never terminates normally. Signed-off-by: Aron Griffis <aron@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] efi.c Spelling/punctuation fixesAron Griffis2008-02-04
| | | | | | | | | Incorporates the suggestions from Peter Chubb the last time I submitted this. This called for using the same verb tense in the couple of preceding comments as well. Signed-off-by: Aron Griffis <aron@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] Make efi.c mostly fit in 80 columnsAron Griffis2008-02-04
| | | | | | | | | | This patch is purely whitespace changes to make the code fit in 80 columns, plus fix some inconsistent indentation. The efi_guidcmp() tests remain wider than 80-columns since that seems to be the most clear. Signed-off-by: Aron Griffis <aron@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] make full use of macro efi_md_sizeLi Zefan2007-12-07
| | | | | | | | | | Macro efi_md_size is defined in efi.c, and here we apply it throughout efi.c. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Acked-by: Simon Horman <horms@verge.net.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* Add IORESOUCE_BUSY flag for System RAMYasunori Goto2007-11-14
| | | | | | | | | | | | | | | | | | | | | i386 and x86-64 registers System RAM as IORESOURCE_MEM | IORESOURCE_BUSY. But ia64 registers it as IORESOURCE_MEM only. In addition, memory hotplug code registers new memory as IORESOURCE_MEM too. This difference causes a failure of memory unplug of x86-64. This patch fixes it. This patch adds IORESOURCE_BUSY to avoid potential overlap mapping by PCI device. Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com> Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com> Cc: Luck, Tony" <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [IA64] Wrong args to memset in efi_gettimeofday()Li Zefan2007-11-06
| | | | | | | | | | Not sizeof(ptr) ... we meant to say sizeof(*ptr). Also moved the memset to the error path (the normal path overwrites every field in the structure anyway) -Tony Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] vmcore_find_descriptor_size should be in __initSimon Horman2007-10-29
| | | | | | | | | vmcore_find_descriptor_size() is only called by reserve_elfcorehdr(), which is in __init, so it seems to me that vmcore_find_descriptor_size() should be there too. Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
* kexec: add BSS to resource treeBernhard Walle2007-10-22
| | | | | | | | | | | | | | | | | | | | | | | | Add the BSS to the resource tree just as kernel text and kernel data are in the resource tree. The main reason behind this is to avoid crashkernel reservation in that area. While it's not strictly necessary to have the BSS in the resource tree (the actual collision detection is done in the reserve_bootmem() function before), the usage of the BSS resource should be presented to the user in /proc/iomem just as Kernel data and Kernel code. Note: The patch currently is only implemented for x86 and ia64 (because efi_initialize_iomem_resources() has the same signature on i386 and ia64). [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Bernhard Walle <bwalle@suse.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: <linux-arch@vger.kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Use extended crashkernel command line on ia64Bernhard Walle2007-10-19
| | | | | | | | | | | | | | | | | | | | | This patch adapts IA64 to use the generic parse_crashkernel() function instead of its own parsing for the crashkernel command line. Because the total amount of System RAM must be known when calling this function, efi_memmap_init() is modified to return its accumulated total_memory variable. Also, the crashkernel handling is moved in an own function in arch/ia64/kernel/setup.c to make the code more readable. [kamalesh@linux.vnet.ibm.com: build fix] Signed-off-by: Bernhard Walle <bwalle@suse.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* handle kernelcore=: genericMel Gorman2007-07-17
| | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the kernelcore= parameter for x86. Once all patches are applied, a new command-line parameter exist and a new sysctl. This patch adds the necessary documentation. From: Yasunori Goto <y-goto@jp.fujitsu.com> When "kernelcore" boot option is specified, kernel can't boot up on ia64 because of an infinite loop. In addition, the parsing code can be handled in an architecture-independent manner. This patch uses common code to handle the kernelcore= parameter. It is only available to architectures that support arch-independent zone-sizing (i.e. define CONFIG_ARCH_POPULATES_NODE_MAP). Other architectures will ignore the boot parameter. [bunk@stusta.de: make cmdline_parse_kernelcore() static] Signed-off-by: Mel Gorman <mel@csn.ul.ie> Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com> Acked-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* EFI: warn only for pre-1.00 system tablesBjorn Helgaas2007-05-08
| | | | | | | | | | | | We used to warn unless the EFI system table major revision was exactly 1. But EFI 2.00 firmware is starting to appear, and the 2.00 changes don't affect anything in Linux. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Andi Kleen <ak@suse.de> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [IA64] fail mmaps that span areas with incompatible attributesBjorn Helgaas2007-03-30
| | | | | | | | | | | | | | | | | | Example memory map (from HP sx1000 with VGA enabled): 0x00000 - 0x9FFFF supports only WB (cacheable) access 0xA0000 - 0xBFFFF supports only UC (uncacheable) access 0xC0000 - 0xFFFFF supports only WB (cacheable) access Some versions of X map the entire 0x00000-0xFFFFF area at once. With the example above, this mmap must fail because there's no memory attribute that's safe for the entire area. Prior to this patch, we performed the mmap with a UC mapping. When X accessed the WB memory at 0xC0000, it caused an MCA. The crash can happen when mapping 0xC0000 from either /dev/mem or a /sys/.../legacy_mem file. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] put kdump_find_rsvd_region in __initHorms2007-03-08
| | | | | | | | | kdump_find_rsvd_region() is only called by reserve_memory() which is in __init, so it seems that kdump_find_rsvd_region() should also be in there. Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] Pick highest possible saved_max_pfn for crash_dumpTony Luck2007-03-07
| | | | | | | | | | | Berhhard Walle noted that on his HP rx8640 he ended up with saved_max_pfn smaller than the highest address of system ram in /proc/iomem and proposed a patch to base the address on the unrounded and unfiltered EFI memory map address. Simon Horman and Magnus Damm suggested that the whole test be moved earlier in the function. This is the combination of both of these patches. Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] kexec: Use EFI_LOADER_DATA for ELF core headerMagnus Damm2007-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The address where the ELF core header is stored is passed to the secondary kernel as a kernel command line option. The memory area for this header is also marked as a separate EFI memory descriptor on ia64. The separate EFI memory descriptor is at the moment of the type EFI_UNUSABLE_MEMORY. With such a type the secondary kernel skips over the entire memory granule (config option, 16M or 64M) when detecting memory. If we are lucky we will just lose some memory, but if we happen to have data in the same granule (such as an initramfs image), then this data will never get mapped and the kernel bombs out when trying to access it. So this is an attempt to fix this by changing the EFI memory descriptor type into EFI_LOADER_DATA. This type is the same type used for the kernel data and for initramfs. In the secondary kernel we then handle the ELF core header data the same way as we handle the initramfs image. This patch contains the kernel changes to make this happen. Pretty straightforward, we reserve the area in reserve_memory(). The address for the area comes from the kernel command line and the size comes from the specialized EFI parsing function vmcore_find_descriptor_size(). The kexec-tools-testing code for this can be found here: http://lists.osdl.org/pipermail/fastboot/2007-February/005983.html Signed-off-by: Magnus Damm <magnus@valinux.co.jp> Cc: Simon Horman <horms@verge.net.au> Cc: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] point saved_max_pfn to the max_pfn of the entire systemHorms2007-03-06
| | | | | | | | | | | | | | | | Make saved_max_pfn point to max_pfn of entire system. Without this patch is so that vmcore is zero length on ia64. This is because saved_max_pfn was wrongly being set to the max_pfn of the crash kernel's address space, rather than the max_pfg on the physical memory of the machine - the whole purpose of vmcore is to access physical memory that is not part of the crash kernel's addresss space. Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Sort-Of-Acked-By: Jay Lan <jlan@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [PATCH] Dynamic kernel command-line: fixupsAlon Bar-Lev2007-02-12
| | | | | | | | | | | | | Remove in-source externs, linux/init.h is included in all cases. This is a fixups for "Dynamic kernel command-line" patch. It also includes some uml __init fixups so that we can __initdata also its command_line. Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] Dynamic kernel command-line: ia64Alon Bar-Lev2007-02-12
| | | | | | | | | | | 1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata. [akpm@osdl.org: move some declarations to the right place] Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [IA64] add newline to PAL-code warning messageHorms2007-02-05
| | | | | Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] resolve name clash by renaming is_available_memory()Christoph Lameter2006-12-07
| | | | | | | | | There is a name clash with ia64 arch code in Andrew's tree. Rename is_avialable_memory() to is_memory_available() to avoid the clash. Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] IA64 Kexec/kdumpZou Nan hai2006-12-07
| | | | | | | | | | | | | | | Changes and updates. 1. Remove fake rendz path and related code according to discuss with Khalid Aziz. 2. fc.i offset fix in relocate_kernel.S. 3. iospic shutdown code eoi and mask race fix from Fujitsu. 4. Warm boot hook in machine_kexec to SN SAL code from Jack Steiner. 5. Send slave to SAL slave loop patch from Jay Lan. 6. Kdump on non-recoverable MCA event patch from Jay Lan 7. Use CTL_UNNUMBERED in kdump_on_init sysctl. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] sparse cleanupsKeith Owens2006-08-02
| | | | | | | | | Fix some sparse warnings on ia64. Large constants that should be long instead of int. Use NULL instead of 0. Add some missing __iomem casts. Replace a non-C99 structure assignment. Signed-off-by: Keith Owens <kaos@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [PATCH] make valid_mmap_phys_addr_range() take a pfnLennert Buytenhek2006-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Newer ARMs have a 40 bit physical address space, but mapping physical memory above 4G needs a special page table format which we (currently?) do not use for userspace mappings, so what happens instead is that mapping an address >= 4G will happily discard the upper bits and wrap. There is a valid_mmap_phys_addr_range() arch hook where we could check for >= 4G addresses and deny the mapping, but this hook takes an unsigned long address: static inline int valid_mmap_phys_addr_range(unsigned long addr, size_t size); And drivers/char/mem.c:mmap_mem() calls it like this: static int mmap_mem(struct file * file, struct vm_area_struct * vma) { size_t size = vma->vm_end - vma->vm_start; if (!valid_mmap_phys_addr_range(vma->vm_pgoff << PAGE_SHIFT, size)) So that's not much help either. This patch makes the hook take a pfn instead of a phys address. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Remove obsolete #include <linux/config.h>Jörn Engel2006-06-30
| | | | | Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* [IA64] rework memory attribute aliasingBjorn Helgaas2006-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | This closes a couple holes in our attribute aliasing avoidance scheme: - The current kernel fails mmaps of some /dev/mem MMIO regions because they don't appear in the EFI memory map. This keeps X from working on the Intel Tiger box. - The current kernel allows UC mmap of the 0-1MB region of /sys/.../legacy_mem even when the chipset doesn't support UC access. This causes an MCA when starting X on HP rx7620 and rx8620 boxes in the default configuration. There's more detail in the Documentation/ia64/aliasing.txt file this adds, but the general idea is that if a region might be covered by a granule-sized kernel identity mapping, any access via /dev/mem or mmap must use the same attribute as the identity mapping. Otherwise, we fall back to using an attribute that is supported according to the EFI memory map, or to using UC if the EFI memory map doesn't mention the region. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [PATCH] EFI: keep physical table addresses in efi structureBjorn Helgaas2006-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | Almost all users of the table addresses from the EFI system table want physical addresses. So rather than doing the pa->va->pa conversion, just keep physical addresses in struct efi. This fixes a DMI bug: the efi structure contained the physical SMBIOS address on x86 but the virtual address on ia64, so dmi_scan_machine() used ioremap() on a virtual address on ia64. This is essentially the same as an earlier patch by Matt Tolentino: http://marc.theaimsgroup.com/?l=linux-kernel&m=112130292316281&w=2 except that this changes all table addresses, not just ACPI addresses. Matt's original patch was backed out because it caused MCAs on HP sx1000 systems. That problem is resolved by the ioremap() attribute checking added for ia64. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com> Cc: "Brown, Len" <len.brown@intel.com> Cc: Andi Kleen <ak@muc.de> Acked-by: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] EFI, /dev/mem: simplify efi_mem_attribute_range()Bjorn Helgaas2006-03-26
| | | | | | | | | | | | | | | | | | Pass the size, not a pointer to the size, to efi_mem_attribute_range(). This function validates memory regions for the /dev/mem read/write/mmap paths. The pointer allows arches to reduce the size of the range, but I think that's unnecessary complexity. Simplifying it will let me use efi_mem_attribute_range() to improve the ia64 ioremap() implementation. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com> Cc: "Brown, Len" <len.brown@intel.com> Cc: Andi Kleen <ak@muc.de> Acked-by: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [IA64] Fix wrong use of memparse in efi.cZou Nan hai2006-02-07
| | | | | | | | | | | The check of (end != cp) after memparse in efi.c looks wrong to me. The result is that we can't use mem= and max_addr= kernel parameter at the same time. The following patch removed the check just like other arches do. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] Fix a possible buffer overflow in efi.cZou Nan hai2006-02-07
| | | | | | | Make sure to save space for the trailing '\0'. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [PATCH] /dev/mem: validate mmap requestsBjorn Helgaas2006-01-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a hook so architectures can validate /dev/mem mmap requests. This is analogous to validation we already perform in the read/write paths. The identity mapping scheme used on ia64 requires that each 16MB or 64MB granule be accessed with exactly one attribute (write-back or uncacheable). This avoids "attribute aliasing", which can cause a machine check. Sample problem scenario: - Machine supports VGA, so it has uncacheable (UC) MMIO at 640K-768K - efi_memmap_init() discards any write-back (WB) memory in the first granule - Application (e.g., "hwinfo") mmaps /dev/mem, offset 0 - hwinfo receives UC mapping (the default, since memmap says "no WB here") - Machine check abort (on chipsets that don't support UC access to WB memory, e.g., sx1000) In the scenario above, the only choices are - Use WB for hwinfo mmap. Can't do this because it causes attribute aliasing with the UC mapping for the VGA MMIO space. - Use UC for hwinfo mmap. Can't do this because the chipset may not support UC for that region. - Disallow the hwinfo mmap with -EINVAL. That's what this patch does. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [IA64] Replace kcalloc(1, with kzalloc.Panagiotis Issaris2005-11-10
| | | | | | | Conversion from kcalloc(1, to kzalloc. Signed-off-by: Panagiotis Issaris <takis@issaris.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] include EFI memory information in /proc/iomemKhalid Aziz2005-09-19
| | | | | | | | | User mode kexec tools expect to find information about physical memory in /proc/iomem (as they do on x86) to validate the addresses that the new kernel will use. Signed-off-by: Khalid Aziz <khalid.aziz@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] simplified efi memory map parsingTony Luck2005-09-08
| | | | | | | | | | | | New version leaves the original memory map unmodified. Also saves any granule trimmings for use by the uncached memory allocator. Inspired by Khalid Aziz (various traces of his patch still remain). Fixes to uncached_build_memmap() and sn2 testing by Martin Hicks. Signed-off-by: Tony Luck <tony.luck@intel.com>
* [PATCH] ia64 uncached allocJes Sorensen2005-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the ia64 uncached page allocator and the generic allocator (genalloc). The uncached allocator was formerly part of the SN2 mspec driver but there are several other users of it so it has been split off from the driver. The generic allocator can be used by device driver to manage special memory etc. The generic allocator is based on the allocator from the sym53c8xx_2 driver. Various users on ia64 needs uncached memory. The SGI SN architecture requires it for inter-partition communication between partitions within a large NUMA cluster. The specific user for this is the XPC code. Another application is large MPI style applications which use it for synchronization, on SN this can be done using special 'fetchop' operations but it also benefits non SN hardware which may use regular uncached memory for this purpose. Performance of doing this through uncached vs cached memory is pretty substantial. This is handled by the mspec driver which I will push out in a seperate patch. Rather than creating a specific allocator for just uncached memory I came up with genalloc which is a generic purpose allocator that can be used by device drivers and other subsystems as they please. For instance to handle onboard device memory. It was derived from the sym53c7xx_2 driver's allocator which is also an example of a potential user (I am refraining from modifying sym2 right now as it seems to have been under fairly heavy development recently). On ia64 memory has various properties within a granule, ie. it isn't safe to access memory as uncached within the same granule as currently has memory accessed in cached mode. The regular system therefore doesn't utilize memory in the lower granules which is mixed in with device PAL code etc. The uncached driver walks the EFI memmap and pulls out the spill uncached pages and sticks them into the uncached pool. Only after these chunks have been utilized, will it start converting regular cached memory into uncached memory. Hence the reason for the EFI related code additions. Signed-off-by: Jes Sorensen <jes@wildopensource.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!