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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
>>> 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@xxxxxxxxxxxxxxxxxx>
>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
