Revision tags: v2.6.19-rc2, v2.6.19-rc1, v2.6.18, v2.6.18-rc7, v2.6.18-rc6 |
|
#
bcf5111a |
| 30-Aug-2006 |
Russell King <rmk@dyn-67.arm.linux.org.uk> |
[SERIAL] Remove wrong asm/serial.h inclusions asm/serial.h is supposed to contain the definitions for the architecture specific 8250 ports for the 8250 driver. It may also define BASE_B
[SERIAL] Remove wrong asm/serial.h inclusions asm/serial.h is supposed to contain the definitions for the architecture specific 8250 ports for the 8250 driver. It may also define BASE_BAUD, but this is the base baud for the architecture specific ports _only_. Therefore, nothing other than the 8250 driver should be including this header file. In order to move towards this goal, here is a patch which removes some of the more obvious incorrect includes of the file. Acked-by: Paul Fulghum <paulkf@microgate.com> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
#
ae3e0218 |
| 26-Sep-2006 |
Tony Luck <tony.luck@intel.com> |
Pull model-name into release branch
|
Revision tags: v2.6.18-rc5, v2.6.18-rc4, v2.6.18-rc3, v2.6.18-rc2 |
|
#
894673ee |
| 10-Jul-2006 |
Jon Smirl <jonsmir@gmail.com> |
[PATCH] tty: Remove include of screen_info.h from tty.h screen_info.h doesn't have anything to do with the tty layer and shouldn't be included by tty.h. This patches removes the include
[PATCH] tty: Remove include of screen_info.h from tty.h screen_info.h doesn't have anything to do with the tty layer and shouldn't be included by tty.h. This patches removes the include and modifies all users to directly include screen_info.h. struct screen_info is mainly used to communicate with the console drivers in drivers/video/console. Note that this patch touches every arch and I have no way of testing it. If there is a mistake the worst thing that will happen is a compile error. [akpm@osdl.org: fix arm build] [akpm@osdl.org: fix alpha build] Signed-off-by: Jon Smirl <jonsmir@gmail.com> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
Revision tags: v2.6.18-rc1 |
|
#
6ab3d562 |
| 30-Jun-2006 |
Jörn Engel <joern@wohnheim.fh-wedel.de> |
Remove obsolete #include <linux/config.h> Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
Revision tags: v2.6.17 |
|
#
5eb1d63f |
| 06-Jun-2006 |
Alex Williamson <alex.williamson@hp.com> |
[IA64] sanity check reserved region usage One more trivial, stand-alone patch from the Xen/ia64 review. Sanity check usage of the reserved region numbers. Signed-off-by: Alex W
[IA64] sanity check reserved region usage One more trivial, stand-alone patch from the Xen/ia64 review. Sanity check usage of the reserved region numbers. Signed-off-by: Alex Williamson <alex.williamson@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.17-rc6 |
|
#
76d08bb3 |
| 05-Jun-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Add "model name" to /proc/cpuinfo Linux ia64 port tried to decode the processor family number to something human-readable, but Intel brandnames don't change synchronously with
[IA64] Add "model name" to /proc/cpuinfo Linux ia64 port tried to decode the processor family number to something human-readable, but Intel brandnames don't change synchronously with updates to the family number. Adopt a more i386-like approach and just print the family number in decimal. Add a new field "model name" that uses PAL_BRAND_INFO to find the official name for the cpu, or on older systems, falls back to using the well-known codenames (Merced, McKinley, Madison). Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.17-rc5, v2.6.17-rc4, v2.6.17-rc3, v2.6.17-rc2, v2.6.17-rc1 |
|
#
b2c99e3c |
| 26-Mar-2006 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
[PATCH] EFI: keep physical table addresses in efi structure Almost all users of the table addresses from the EFI system table want physical addresses. So rather than doing the pa->va->p
[PATCH] EFI: keep physical table addresses in efi structure 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>
show more ...
|
#
3ed3bce8 |
| 26-Mar-2006 |
Matt Domsch <Matt_Domsch@dell.com> |
[PATCH] ia64: use i386 dmi_scan.c Enable DMI table parsing on ia64. Andi Kleen has a patch in his x86_64 tree which enables the use of i386 dmi_scan.c on x86_64. dmi_scan.c fun
[PATCH] ia64: use i386 dmi_scan.c Enable DMI table parsing on ia64. Andi Kleen has a patch in his x86_64 tree which enables the use of i386 dmi_scan.c on x86_64. dmi_scan.c functions are being used by the drivers/char/ipmi/ipmi_si_intf.c driver for autodetecting the ports or memory spaces where the IPMI controllers may be found. This patch adds equivalent changes for ia64 as to what is in the x86_64 tree. In addition, I reworked the DMI detection, such that on EFI-capable systems, it uses the efi.smbios pointer to find the table, rather than brute-force searching from 0xF0000. On non-EFI systems, it continues the brute-force search. My test system, an Intel S870BN4 'Tiger4', aka Dell PowerEdge 7250, with latest BIOS, does not list the IPMI controller in the ACPI namespace, nor does it have an ACPI SPMI table. Also note, currently shipping Dell x8xx EM64T servers don't have these either, so DMI is the only method for obtaining the address of the IPMI controller. Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Acked-by: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
7d14f145 |
| 25-Mar-2006 |
Linus Torvalds <torvalds@g5.osdl.org> |
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] New IA64 core
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] New IA64 core/thread detection patch [IA64] Increase max node count on SN platforms [IA64] Increase max node count on SN platforms [IA64] Increase max node count on SN platforms [IA64] Increase max node count on SN platforms [IA64] Tollhouse HP: IA64 arch changes [IA64] cleanup dig_irq_init [IA64] MCA recovery: kernel context recovery table IA64: Use early_parm to handle mvec_name and nomca [IA64] move patchlist and machvec into init section [IA64] add init declaration - nolwsys [IA64] add init declaration - gate page functions [IA64] add init declaration to memory initialization functions [IA64] add init declaration to cpu initialization functions [IA64] add __init declaration to mca functions [IA64] Ignore disabled Local SAPIC Affinity Structure in SRAT [IA64] sn_check_intr: use ia64_get_irr() [IA64] fix ia64 is_hugepage_only_range
show more ...
|
#
cdb04527 |
| 24-Mar-2006 |
Adrian Bunk <bunk@stusta.de> |
[PATCH] kill include/linux/platform.h, default_idle() cleanup include/linux/platform.h contained nothing that was actually used except the default_idle() prototype, and is therefore remo
[PATCH] kill include/linux/platform.h, default_idle() cleanup include/linux/platform.h contained nothing that was actually used except the default_idle() prototype, and is therefore removed by this patch. This patch does the following with the platform specific default_idle() functions on different architectures: - remove the unused function: - parisc - sparc64 - make the needlessly global function static: - arm - h8300 - m68k - m68knommu - s390 - v850 - x86_64 - add a prototype in asm/system.h: - cris - i386 - ia64 Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Patrick Mochel <mochel@digitalimplant.org> Acked-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
a5b00bb4 |
| 23-Mar-2006 |
Horms <horms@verge.net.au> |
IA64: Use early_parm to handle mvec_name and nomca I'm not sure of the worthiness of this idea, so please consider it an RFC. Its key merits are: * Reuse existing infrastructure
IA64: Use early_parm to handle mvec_name and nomca I'm not sure of the worthiness of this idea, so please consider it an RFC. Its key merits are: * Reuse existing infrastructure * Greatly tightens up the parsing of nomca * Greatly simplifies the parsing of machvec Addition cleanup (moving setup_mvec() to machvec.c) by Ken Chen. Signed-Off-By: Horms <horms@verge.net.au> Signed-Off-By: Tony Luck <tony.luck@intel.com>
show more ...
|
#
dae28066 |
| 22-Mar-2006 |
Chen, Kenneth W <kenneth.w.chen@intel.com> |
[IA64] add init declaration to memory initialization functions Add init declaration to variables/functions used for memory initialization. I don't think they would clash with memory
[IA64] add init declaration to memory initialization functions Add init declaration to variables/functions used for memory initialization. I don't think they would clash with memory hotplug. If they do, please yell. Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.16 |
|
#
244fd545 |
| 12-Mar-2006 |
Chen, Kenneth W <kenneth.w.chen@intel.com> |
[IA64] add init declaration to cpu initialization functions Add init declaration to cpu initialization functions. Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-b
[IA64] add init declaration to cpu initialization functions Add init declaration to cpu initialization functions. Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.16-rc6, v2.6.16-rc5, v2.6.16-rc4 |
|
#
a6b14fa6 |
| 14-Feb-2006 |
Ashok Raj <ashok.raj@intel.com> |
[IA64] Count disabled cpus as potential hot-pluggable CPUs Have a facility to account for potentially hot-pluggable CPUs. ACPI doesnt give a determinstic method to find hot-pluggable CPU
[IA64] Count disabled cpus as potential hot-pluggable CPUs Have a facility to account for potentially hot-pluggable CPUs. ACPI doesnt give a determinstic method to find hot-pluggable CPUs. Hence we use 2 methods to assist. - BIOS can mark potentially hot-pluggable CPUs as disabled in the MADT tables. - User can specify the number of hot-pluggable CPUs via parameter additional_cpus=X The option is enabled only if ACPI_CONFIG_HOTPLUG_CPU=y which enables the physical hotplug option. Without which user can still use logical onlining and offlining of CPUs by enabling CONFIG_HOTPLUG_CPU=y Adds more bits to cpu_possible_map for potentially hot-pluggable cpus. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.16-rc3 |
|
#
d6e56a2a |
| 07-Feb-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Fix CONFIG_PRINTK_TIME There were two problems with enabling the PRINTK_TIME config option: 1) The first calls to printk() occur before per-cpu data virtual address is pin
[IA64] Fix CONFIG_PRINTK_TIME There were two problems with enabling the PRINTK_TIME config option: 1) The first calls to printk() occur before per-cpu data virtual address is pinned into the TLB, so sched_clock() can fault. 2) sched_clock() is based on ar.itc, which may not be synchronized across cpus. Ken Chen started this patch, Tony Luck tinkered with it, and Jes Sorensen perfected it. Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.16-rc2, v2.6.16-rc1 |
|
#
6450578f |
| 12-Jan-2006 |
Al Viro <viro@ftp.linux.org.uk> |
[PATCH] ia64: task_pt_regs() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
198e2f18 |
| 12-Jan-2006 |
akpm@osdl.org <akpm@osdl.org> |
[PATCH] scheduler cache-hot-autodetect From: Ingo Molnar <mingo@elte.hu> This is the latest version of the scheduler cache-hot-auto-tune patch. The first problem was t
[PATCH] scheduler cache-hot-autodetect From: Ingo Molnar <mingo@elte.hu> This is the latest version of the scheduler cache-hot-auto-tune patch. The first problem was that detection time scaled with O(N^2), which is unacceptable on larger SMP and NUMA systems. To solve this: - I've added a 'domain distance' function, which is used to cache measurement results. Each distance is only measured once. This means that e.g. on NUMA distances of 0, 1 and 2 might be measured, on HT distances 0 and 1, and on SMP distance 0 is measured. The code walks the domain tree to determine the distance, so it automatically follows whatever hierarchy an architecture sets up. This cuts down on the boot time significantly and removes the O(N^2) limit. The only assumption is that migration costs can be expressed as a function of domain distance - this covers the overwhelming majority of existing systems, and is a good guess even for more assymetric systems. [ People hacking systems that have assymetries that break this assumption (e.g. different CPU speeds) should experiment a bit with the cpu_distance() function. Adding a ->migration_distance factor to the domain structure would be one possible solution - but lets first see the problem systems, if they exist at all. Lets not overdesign. ] Another problem was that only a single cache-size was used for measuring the cost of migration, and most architectures didnt set that variable up. Furthermore, a single cache-size does not fit NUMA hierarchies with L3 caches and does not fit HT setups, where different CPUs will often have different 'effective cache sizes'. To solve this problem: - Instead of relying on a single cache-size provided by the platform and sticking to it, the code now auto-detects the 'effective migration cost' between two measured CPUs, via iterating through a wide range of cachesizes. The code searches for the maximum migration cost, which occurs when the working set of the test-workload falls just below the 'effective cache size'. I.e. real-life optimized search is done for the maximum migration cost, between two real CPUs. This, amongst other things, has the positive effect hat if e.g. two CPUs share a L2/L3 cache, a different (and accurate) migration cost will be found than between two CPUs on the same system that dont share any caches. (The reliable measurement of migration costs is tricky - see the source for details.) Furthermore i've added various boot-time options to override/tune migration behavior. Firstly, there's a blanket override for autodetection: migration_cost=1000,2000,3000 will override the depth 0/1/2 values with 1msec/2msec/3msec values. Secondly, there's a global factor that can be used to increase (or decrease) the autodetected values: migration_factor=120 will increase the autodetected values by 20%. This option is useful to tune things in a workload-dependent way - e.g. if a workload is cache-insensitive then CPU utilization can be maximized by specifying migration_factor=0. I've tested the autodetection code quite extensively on x86, on 3 P3/Xeon/2MB, and the autodetected values look pretty good: Dual Celeron (128K L2 cache): --------------------- migration cost matrix (max_cache_size: 131072, cpu: 467 MHz): --------------------- [00] [01] [00]: - 1.7(1) [01]: 1.7(1) - --------------------- cacheflush times [2]: 0.0 (0) 1.7 (1784008) --------------------- Here the slow memory subsystem dominates system performance, and even though caches are small, the migration cost is 1.7 msecs. Dual HT P4 (512K L2 cache): --------------------- migration cost matrix (max_cache_size: 524288, cpu: 2379 MHz): --------------------- [00] [01] [02] [03] [00]: - 0.4(1) 0.0(0) 0.4(1) [01]: 0.4(1) - 0.4(1) 0.0(0) [02]: 0.0(0) 0.4(1) - 0.4(1) [03]: 0.4(1) 0.0(0) 0.4(1) - --------------------- cacheflush times [2]: 0.0 (33900) 0.4 (448514) --------------------- Here it can be seen that there is no migration cost between two HT siblings (CPU#0/2 and CPU#1/3 are separate physical CPUs). A fast memory system makes inter-physical-CPU migration pretty cheap: 0.4 msecs. 8-way P3/Xeon [2MB L2 cache]: --------------------- migration cost matrix (max_cache_size: 2097152, cpu: 700 MHz): --------------------- [00] [01] [02] [03] [04] [05] [06] [07] [00]: - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [01]: 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [02]: 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [03]: 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) [04]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) [05]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) [06]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) [07]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - --------------------- cacheflush times [2]: 0.0 (0) 19.2 (19281756) --------------------- This one has huge caches and a relatively slow memory subsystem - so the migration cost is 19 msecs. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Cc: <wilder@us.ibm.com> Signed-off-by: John Hawkes <hawkes@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
4dc7a0bb |
| 12-Jan-2006 |
Ingo Molnar <mingo@elte.hu> |
[PATCH] sched: add cacheflush() asm Add per-arch sched_cacheflush() which is a write-back cacheflush used by the migration-cost calibration code at bootup time. Signed-off-by: I
[PATCH] sched: add cacheflush() asm Add per-arch sched_cacheflush() which is a write-back cacheflush used by the migration-cost calibration code at bootup time. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
38c0b2c2 |
| 05-Jan-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Fix compile warnings in setup.c arch/ia64/kernel/setup.c: In function `show_cpuinfo': arch/ia64/kernel/setup.c:576: warning: long unsigned int format, different type arg (arg 12)
[IA64] Fix compile warnings in setup.c arch/ia64/kernel/setup.c: In function `show_cpuinfo': arch/ia64/kernel/setup.c:576: warning: long unsigned int format, different type arg (arg 12) arch/ia64/kernel/setup.c:576: warning: long unsigned int format, different type arg (arg 13) Introduced by 95235ca2c20ac0b31a8eb39e2d599bcc3e9c9a10 Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.15, v2.6.15-rc7, v2.6.15-rc6, v2.6.15-rc5 |
|
#
95235ca2 |
| 02-Dec-2005 |
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> |
[CPUFREQ] CPU frequency display in /proc/cpuinfo What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of changing frequency? Today the answer is: It depen
[CPUFREQ] CPU frequency display in /proc/cpuinfo What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of changing frequency? Today the answer is: It depends. On i386: SMP kernel - It is always the boot frequency UP kernel - Scales with the frequency change and shows that was last set. On x86_64: There is one single variable cpu_khz that gets written by all the CPUs. So, the frequency set by last CPU will be seen on /proc/cpuinfo of all the CPUs in the system. What you see also depends on whether you have constant_tsc capable CPU or not. On ia64: It is always boot time frequency of a particular CPU that gets displayed. The patch below changes this to: Show the last known frequency of the particular CPU, when cpufreq is present. If cpu doesnot support changing of frequency through cpufreq, then boot frequency will be shown. The patch affects i386, x86_64 and ia64 architectures. Signed-off-by: Venkatesh Pallipadi<venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
show more ...
|
#
7669a225 |
| 10-Nov-2005 |
Tony Luck <tony.luck@intel.com> |
Pull context-bitmap into release branch
|
Revision tags: v2.6.15-rc4, v2.6.15-rc3, v2.6.15-rc2, v2.6.15-rc1 |
|
#
e1531b42 |
| 07-Nov-2005 |
John W. Linville <linville@tuxdriver.com> |
[PATCH] ia64: re-implement dma_get_cache_alignment to avoid EXPORT_SYMBOL The current ia64 implementation of dma_get_cache_alignment does not work for modules because it relies on a symb
[PATCH] ia64: re-implement dma_get_cache_alignment to avoid EXPORT_SYMBOL The current ia64 implementation of dma_get_cache_alignment does not work for modules because it relies on a symbol which is not exported. Direct access to a global is a little ugly anyway, so this patch re-implements dma_get_cache_alignment in a manner similar to what is currently used for x86_64. Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
dcc17d1b |
| 31-Oct-2005 |
Peter Keilty <peter.keilty@hp.com> |
[IA64] Use bitmaps for efficient context allocation/free Corrects the very inefficent method of finding free context_ids in get_mmu_context(). Instead of walking the task_list of all pr
[IA64] Use bitmaps for efficient context allocation/free Corrects the very inefficent method of finding free context_ids in get_mmu_context(). Instead of walking the task_list of all processes, 2 bitmaps are used to efficently store and lookup state, inuse and needs flushing. The entire rid address space is now used before calling wrap_mmu_context and global tlb flushing. Special thanks to Ken and Rohit for their review and modifications in using a bit flushmap. Signed-off-by: Peter Keilty <peter.keilty@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
5a2b1722 |
| 28-Oct-2005 |
Tony Luck <tony.luck@intel.com> |
Pull proc-cpuinfo-siblings into release branch
|
#
5833f142 |
| 28-Oct-2005 |
Tony Luck <tony.luck@intel.com> |
Pull new-efi-memmap into release branch
|