[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
VMSPLIT.patch problems?
From: |
Troy Davis |
Subject: |
VMSPLIT.patch problems? |
Date: |
Mon, 03 Apr 2006 11:19:29 -0700 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
Hello-
I am using the VMSPLIT.patch (see below) to split the memory space
into 2G/2G versus the normal 3G/1G. I am currently trying to boot using
an initrd image in a diskless configuration (non-network) using Grub 0.96:
root (hd0,0)
uppermem 720896
kernel /boot/bzImage-2.6.15.4.PIV.vmsplit.smp.flash.rt root=/dev/ram0
mem=704M rw
initrd /boot/initrd.gz
The machine has 1G of memory, of which the top portion is set aside
at boot for framegrabber DMA. A flash device contains the kernel image
along with the initrd.gz image (/dev/hda1 ext2fs). The problem I am
having is the kernel does not appear to be recognizing the initrd image
(kernel is getting to the end of boot stating unable to find init). I
have tried root=/dev/ram, also with and without a linuxrc script in the
initrd's root, with and without init= (pointed to /sbin/init,
/linuxrc). My question is: is the VMSPLIT.patch below mucking up the
location being passed to the kernel by grub for the initrd image?
Best Regards,
Troy
diff -u --recursive --new-file --exclude='.*'
linux-2.6.15/arch/i386/Kconfig linux/arch/i386/Kconfig
--- linux-2.6.15/arch/i386/Kconfig 2006-01-02 22:21:10.000000000 -0500
+++ linux/arch/i386/Kconfig 2006-01-10 12:02:40.000000000 -0500
@@ -448,6 +448,43 @@
endchoice
+choice
+ depends on EXPERIMENTAL && !X86_PAE
+ prompt "Memory split"
+ default VMSPLIT_3G
+ help
+ Select the desired split between kernel and user memory.
+
+ If the address range available to the kernel is less than the
+ physical memory installed, the remaining memory will be available
+ as "high memory". Accessing high memory is a little more costly
+ than low memory, as it needs to be mapped into the kernel first.
+ Note that increasing the kernel address space limits the range
+ available to user programs, making the address space there
+ tighter. Selecting anything other than the default 3G/1G split
+ will also likely make your kernel incompatible with binary-only
+ kernel modules.
+
+ If you are not absolutely sure what you are doing, leave this
+ option alone!
+
+ config VMSPLIT_3G
+ bool "3G/1G user/kernel split"
+ config VMSPLIT_3G_OPT
+ bool "3G/1G user/kernel split (for full 1G low memory)"
+ config VMSPLIT_2G
+ bool "2G/2G user/kernel split"
+ config VMSPLIT_1G
+ bool "1G/3G user/kernel split"
+endchoice
+
+config PAGE_OFFSET
+ hex
+ default 0xB0000000 if VMSPLIT_3G_OPT
+ default 0x78000000 if VMSPLIT_2G
+ default 0x40000000 if VMSPLIT_1G
+ default 0xC0000000
+
config HIGHMEM
bool
depends on HIGHMEM64G || HIGHMEM4G
diff -u --recursive --new-file --exclude='.*'
linux-2.6.15/include/asm-i386/page.h linux/include/asm-i386/page.h
--- linux-2.6.15/include/asm-i386/page.h 2006-01-02
22:21:10.000000000 -0500
+++ linux/include/asm-i386/page.h 2006-01-10 12:04:56.000000000 -0500
@@ -110,10 +110,10 @@
#endif /* __ASSEMBLY__ */
#ifdef __ASSEMBLY__
-#define __PAGE_OFFSET (0xC0000000)
+#define __PAGE_OFFSET CONFIG_PAGE_OFFSET
#define __PHYSICAL_START CONFIG_PHYSICAL_START
#else
-#define __PAGE_OFFSET (0xC0000000UL)
+#define __PAGE_OFFSET ((unsigned long)CONFIG_PAGE_OFFSET)
#define __PHYSICAL_START ((unsigned long)CONFIG_PHYSICAL_START)
#endif
#define __KERNEL_START (__PAGE_OFFSET + __PHYSICAL_START)
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- VMSPLIT.patch problems?,
Troy Davis <=