From: David Daney <ddaney@caviumnetworks.com>
To: naveen yadav <yad.naveen@gmail.com>
Cc: adnan iqbal <adnan.iqbal@seecs.edu.pk>,
linux-mips@linux-mips.org, kernelnewbies@nl.linux.org
Subject: Re: page size change on MIPS
Date: Fri, 28 Jan 2011 10:48:58 -0800 [thread overview]
Message-ID: <4D430F9A.7040905@caviumnetworks.com> (raw)
In-Reply-To: <AANLkTin-D8KW2uDYkSbEsCuS2rPSetw23CLxkAqw7OYd@mail.gmail.com>
On 01/28/2011 01:18 AM, naveen yadav wrote:
> Hi all
>
> I try changing the kernel_execve() function as suggested, but it fails,
> I am using code sourcery toolchain 4.4.1 but it still fails. I am
> using 2.6.30.9 kernel and this function is part of it.
>
>
Quit trying to change kernel_execve(). It is perfect as it is.
The problem is elsewhere.
>
> Kind regards
>
Thank you.
>
> On Thu, Jan 27, 2011 at 11:14 PM, David Daney<ddaney@caviumnetworks.com> wrote:
>> On 01/27/2011 07:18 AM, adnan iqbal wrote:
>>>
>>> Please try this. One line of code is added ( move %1, $7).
>>>
>>>
>>> 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"
>>> " move %1, $7 \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;
>>> }
>>>
>>
>> I don't know where you got that code. But really you should do what glibc
>> does. glibc gets it correct.
>>
>> At a minimum you are missing "hi" and "lo" clobbers.
Ignore that ^^^^^ advice.
>>
>> If the code works with 16K pages, and not 64K pages, then this snippet is
>> not the problem. Likely your problem is the layout of the PHDRs in the
>> executable is not compatible with the page size.
>>
Instead look at this issue.
>> David Daney
>>
>>
>>>
>>> On Thu, Jan 27, 2011 at 7:55 PM, naveen yadav<yad.naveen@gmail.com>
>>> wrote:
>>>
>>>> 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@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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
next prev parent reply other threads:[~2011-01-28 18:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-24 15:02 page size change on MIPS naveen yadav
2011-01-24 18:56 ` David Daney
2011-01-24 19:13 ` Kevin D. Kissell
2011-01-27 14:55 ` naveen yadav
2011-01-27 15:18 ` adnan iqbal
2011-01-27 17:44 ` David Daney
2011-01-28 9:18 ` naveen yadav
2011-01-28 18:48 ` David Daney [this message]
2011-01-30 15:02 ` Himanshu Aggarwal
2011-01-31 13:08 ` Ralf Baechle
2011-02-04 3:24 ` naveen yadav
2011-02-04 4:16 ` naveen yadav
2011-02-04 17:25 ` David Daney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D430F9A.7040905@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=adnan.iqbal@seecs.edu.pk \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-mips@linux-mips.org \
--cc=yad.naveen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox