Not getting login prompt after CPU entered into cpu_idle() state
Hi All, We have ported the kernel from 2.6.10 version to 2.6.32 kernel version for our Phytec LPC-3180 board. We have done good work and able to complete the kernel part i.e. completed the start_kernel function and CPU entered into IDLE state from cpu_idle() function which is defined in rest_init() function in main.c file. However, rest_init() function also creates TWO threads. One thread is for running the kernel_init() function where it calls the init_post() function. In this, after a few other calls, there is a call to init the init-process i.e. run_init_process("/sbin/init"). After this, we are not seeing neither any errors nor login prompt in hyper terminal. We end up without getting any login prompt. Any idea would be greatly help us in getting the login prompt / for debugging the sources further for identifying the exact reason / location to find out the error. Here are the final debug statements which we are seeing in the hyper terminal. <6>VFP support v0.3: implementor 41 architecture 1 part 10 variant 9 rev 1 <5>RAMDISK: gzip image found at block 0 VFS: Mounted root (ext2 filesystem) on device 1:0. <6>Freeing init memory: 80K .....@ <init/main.c> <init_post> <900> .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <271> ret = 0 : /sbin/init .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <274> .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <271> ret = 0 : /sbin/modprobe .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <274> .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <271> ret = 0 : /sbin/modprobe .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <274> .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <271> ret = 0 : /sbin/modprobe .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <274> .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <271> ret = 0 : /sbin/modprobe .....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <274> If we load 2.6.10 kernel image, we are getting login prompt in the hyper terminal on the same Phytec board. NOTE: We are using the same file system on 2.6.32 kernel which was running fine on 2.6.10 kernel. We will provide if any one need additional information / complete log. Thanks in advance. Regards, Srinidhi.
Hi... On Thu, Jul 5, 2012 at 12:12 PM, Srinidhi M <srinidhi.m26@gmail.com> wrote:
.....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <271> ret = 0 : /sbin/init
FYI I absolutely has no hands on experience on this kind of hack, so this is purely speculation. I am thinking, ret=0 when calling /sbin/init? AFAIK, a successful open() operation should return something bigger than 0 as the file descriptor. Also, init should call /sbin/login or something similar. maybe something is wrong when reading /etc/fstab or anything similar for your kernel? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Fri, Jul 06, 2012 at 12:56:45AM +0700, Mulyadi Santosa wrote:
Hi...
On Thu, Jul 5, 2012 at 12:12 PM, Srinidhi M <srinidhi.m26@gmail.com> wrote:
.....@ <arch/arm/kernel/sys_arm.c> <kernel_execve> <271> ret = 0 : /sbin/init
FYI I absolutely has no hands on experience on this kind of hack, so this is purely speculation.
I am thinking, ret=0 when calling /sbin/init? AFAIK, a successful open() operation should return something bigger than 0 as the file descriptor.
Only if 0 is already in use. But isn't that exec and not open? Thanks, Jonathan
On Fri, Jul 6, 2012 at 1:02 AM, Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
On Fri, Jul 06, 2012 at 12:56:45AM +0700, Mulyadi Santosa wrote: Only if 0 is already in use.
But isn't that exec and not open?
hm, right, it's exec....so it should be just launch the init with return value as programmed ( 0?) -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Here are the final debug statements which we are seeing in the hyper terminal.
Can you post the full logs WITHOUT your debug prints. What is the toolchain you are using?
If we load 2.6.10 kernel image, we are getting login prompt in the hyper terminal on the same Phytec board.
You can isolate the problem by writing a small utility(blinky) which would blink some LED on the board and then pass (init = /sbin/blinky) it in your kernel command line.
On Fri, Jul 6, 2012 at 1:10 AM, sk.syed2 <sk.syed2@gmail.com> wrote:
Here are the final debug statements which we are seeing in the hyper terminal.
Can you post the full logs WITHOUT your debug prints. What is the toolchain you are using?
Please find the attached FULL log file without our own messages.
If we load 2.6.10 kernel image, we are getting login prompt in the hyper terminal on the same Phytec board.
You can isolate the problem by writing a small utility(blinky) which would blink some LED on the board and then pass (init = /sbin/blinky) it in your kernel command line.
We are assuming that the kernel is completely booted, in 2.6.32 kernel, without any issues as it entered into cpu_idle state. We are guessing that there is an error in the file system sources (i.e. sbin/init). Unfortunately, we do not have the sources for the available file system and we have downloaded the file system from the following Phytec link. http://www.phytec.com/products/linux/bsp-LPC3180.html Please provide some insight to find out the reason for not getting login prompt. Thanks and Regards, Srinidhi M.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Fri, Jul 6, 2012 at 10:39 AM, Srinidhi M <srinidhi.m26@gmail.com> wrote:
On Fri, Jul 6, 2012 at 1:10 AM, sk.syed2 <sk.syed2@gmail.com> wrote:
Here are the final debug statements which we are seeing in the hyper terminal.
Can you post the full logs WITHOUT your debug prints. What is the toolchain you are using?
Please find the attached FULL log file without our own messages.
If the init process cannot be started, the kernel should at least panic. Try passing init=/foo to the kernel boot to force the panic. If that does not lead to the panic, then yuo can be sure that it is a kernel problem. Greetings, Philipp
We are assuming that the kernel is completely booted, in 2.6.32 kernel, without any issues as it entered into cpu_idle state. We are guessing that there is an error in the file system sources (i.e. sbin/init). Unfortunately, we do not have the sources for the available file system and we have downloaded the file system from the following Phytec link.
It seems to me that the kernel and filesystem are not built with the same toolchain version. This could be a problem. You can use buildroot http://buildroot.uclibc.org/download.html to generate a new filesystem. -syed
On Sat, Jul 7, 2012 at 4:53 AM, sk.syed2 <sk.syed2@gmail.com> wrote:
We are assuming that the kernel is completely booted, in 2.6.32 kernel, without any issues as it entered into cpu_idle state. We are guessing that there is an error in the file system sources (i.e. sbin/init). Unfortunately, we do not have the sources for the available file system and we have downloaded the file system from the following Phytec link.
It seems to me that the kernel and filesystem are not built with the same toolchain version. This could be a problem. You can use buildroot http://buildroot.uclibc.org/download.html to generate a new filesystem.
Thanks for your information. Yes. As you said we used the file system that was build by Phytec for 2.6.10 kernel version. However, we do not have the file system sources with us. So, we have built busybox with the same tool chain version that we used to build the 2.6.32 kernel image. Even though, we are seeing the same error messages i.e. we are seeing 5 to 6 "/sbin/modprobe" calls after calling the "/sbin/init". After that, we did not see any messages at all. We are getting the SAME log messages that we got earlier when we use this busybox file system which was build with same tool chain. Please let us know, if we are doing anything wrong here, still. Thanks and Regards, Srinidhi M.
-syed
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Mon, Jul 9, 2012 at 3:36 PM, Srinidhi M <srinidhi.m26@gmail.com> wrote:
So, we have built busybox with the same tool chain version that we used to build the 2.6.32 kernel image. Even though, we are seeing the same error messages i.e. we are seeing 5 to 6 "/sbin/modprobe" calls after calling the "/sbin/init". After that, we did not see any messages at all. We are getting the SAME log messages that we got earlier when we use this busybox file system which was build with same tool chain.
My next guess would be that some tty device nodes changed and your init configuration at /etc/inittab points to wrong console devices. At least that was the case when I had a similar error. Init starts and puts the login prompt on the wrong console device so you don't see it. Greetings, Philipp
participants (5)
-
Jonathan Neuschäfer -
Mulyadi Santosa -
Philipp Ittershagen -
sk.syed2 -
Srinidhi M