- 07 1月, 2006 2 次提交
-
-
由 Zachary Amsden 提交于
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: NZachary Amsden <zach@vmware.com> Acked-by: N"Seth, Rohit" <rohit.seth@intel.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Zachary Amsden 提交于
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: NZachary Amsden <zach@vmware.com> Cc: "Seth, Rohit" <rohit.seth@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 9月, 2005 1 次提交
-
-
由 Sam Ravnborg 提交于
Building asm-offsets.h has been moved to a seperate Kbuild file located in the top-level directory. This allow us to share the functionality across the architectures. The old rules in architecture specific Makefiles will die in subsequent patches. Furhtermore the usual kbuild dependency tracking is now used when deciding to rebuild asm-offsets.s. So we no longer risk to fail a rebuild caused by asm-offsets.c dependencies being touched. With this common rule-set we now force the same name across all architectures. Following patches will fix the rest. Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
- 05 9月, 2005 1 次提交
-
-
由 Vivek Goyal 提交于
o With introduction of kexec as boot-loader, the assumption that parameter segment will always be loaded at lower address than kernel and will be addressable by early bootup page tables is no longer valid. In kexec on panic case parameter segment might well be loaded beyond kernel image and might not be addressable by early boot page tables. o This case might hit in the scenario where user has reserved a chunk of memory for second kernel, for example 16MB to 64MB, and has also built second kernel for physical memory location 16MB. In this case kexec has no choice but to load the parameter segment at a higher address than new kernel image at safe location where new kernel does not stomp it. o Though problem should automatically go away once relocatable kernel for i386 is in place and kexec can determine the location of new kernel at run time and load parameter segment at lower address than kernel image. But till then this patch can go in (assuming it does not break something else). o This patch moves up the boot parameter saving code. Now boot parameters are copied out in protected mode before page tables are initialized. This will ensure that parameter segment is always addressable irrespective of its physical location. Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 26 6月, 2005 1 次提交
-
-
由 Shaohua Li 提交于
I'm doing the cpu hotplug stress test and found a variable ('ready') is overflow after several hundreds rounds of cpu hotplug. Here is a fix. Signed-off-by: Shaohua Li<shaohua.li@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 01 5月, 2005 1 次提交
-
-
由 Matt Mackall 提交于
Arrange for all kernel printks to be no-ops. Only available if CONFIG_EMBEDDED. This patch saves about 375k on my laptop config and nearly 100k on minimal configs. Signed-off-by: NMatt Mackall <mpm@selenic.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-