page size change on MIPS

[naveen yadav]

Hi David,

thanks for your response.

I check and found that kernel is booting with 16KB page size with
ramdisk booting. But when I change to 64KB it give me

: applet not found
                  Kernel panic - not syncing: Attempted to kill init!
so I check and found that it is not able to execute well the system
call in kernel_execve function.
I am using codesourcercy toolchain(4.3.1). So is there a way to debug
this problem or how to debug below function.

int kernel_execve(const char *filename, char *const argv[], char *const envp[])
{
	register unsigned long __a0 asm("$4") = (unsigned long) filename;
	register unsigned long __a1 asm("$5") = (unsigned long) argv;
	register unsigned long __a2 asm("$6") = (unsigned long) envp;
	register unsigned long __a3 asm("$7");
	unsigned long __v0;
	__asm__ volatile ("					\n"
	"	.set	noreorder				\n"
	"	li	$2, %5		# __NR_execve		\n"
	"	syscall						\n"
	"	move	%0, $2					\n"
	"	.set	reorder					\n"
	: "=&r" (__v0), "=r" (__a3)
	: "r" (__a0), "r" (__a1), "r" (__a2), "i" (__NR_execve)
	: "$2", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24",
	  "memory");
	

	if (__a3 == 0)			
		return __v0;
	return -__v0;
}


On Tue, Jan 25, 2011 at 12:26 AM, David Daney <ddaney at caviumnetworks.com> wrote:
> On 01/24/2011 07:02 AM, naveen yadav wrote:
>>
>> Hi All,
>>
>>
>> we are using mips32r2  so I want to know which all pages size it can
>> support?
>> When I modify arch/mips/Kconfig.  it boot sucessfully on 16KB page
>> size. but hang/not boot crash when change page size to 8KB,32KB and 64
>> KB.
>
> I don't think 8KB and 32KB work on most mips32r2 processors.  You would have
> to check the processor manual to be sure.
>
>
>>
>> We are using 2.6.30 kernel.
>>
>> At Page Size 8KB and 32KB  it hang in unpack_to_rootfs() function of
>> init/initramfs.c
>>
>> 64KB it hangs when execute init  Kernel panic - not syncing: Attempted
>> to kill init!
>
> I regularly run 4K, 16K, and 64K page sizes with a Debian rootfs.  If you
> run with a broken uClibc toolchain that doesn't support larger pages, it
> will of course fail.  In this case the problem is with your toolchain, not
> the kernel.
>
> David Daney
>
>
>>
>> config PAGE_SIZE_4KB
>>         bool "4kB"
>>         help
>>          This option select the standard 4kB Linux page size.  On some
>>          R3000-family processors this is the only available page size.
>>  Using
>>          4kB page size will minimize memory consumption and is therefore
>>          recommended for low memory systems.
>>
>> config PAGE_SIZE_8KB
>>         bool "8kB"
>>        depends on (EXPERIMENTAL&&  CPU_R8000) || CPU_CAVIUM_OCTEON
>>         help
>>           Using 8kB page size will result in higher performance kernel at
>>           the price of higher memory consumption.  This option is
>> available
>>           only on R8000 and cnMIPS processors.  Note that you will need a
>>           suitable Linux distribution to support this.
>>
>> config PAGE_SIZE_16KB
>>         bool "16kB"
>>        depends on !CPU_R3000&&  !CPU_TX39XX
>>         help
>>           Using 16kB page size will result in higher performance kernel at
>>           the price of higher memory consumption.  This option is
>> available on
>>           all non-R3000 family processors.  Note that you will need a
>> suitable
>>           Linux distribution to support this.
>>
>> config PAGE_SIZE_32KB
>>         bool "32kB"
>>         help
>>           Using 32kB page size will result in higher performance kernel at
>>           the price of higher memory consumption.  This option is
>> available
>>           only on cnMIPS cores.  Note that you will need a suitable Linux
>>           distribution to support this.
>>
>> config PAGE_SIZE_64KB
>>         bool "64kB"
>>        depends on EXPERIMENTAL&&  !CPU_R3000&&  !CPU_TX39XX
>>         help
>>           Using 64kB page size will result in higher performance kernel at
>>           the price of higher memory consumption.  This option is
>> available on
>>           all non-R3000 family processor.  Not that at the time of this
>>           writing this option is still high experimental.
>>
>>
>
>