Kernel panic - not syncing: Attempted to kill init! I am without any clue...
Hi!
I am upgrading a system based on a AT91RM9200 running Linux 2.4.x to Kernel 2.6.27.10 using buildroot enviroment ( Kernel, uClibc, busybox). While I had the hardware and board specific things implemented into the kernel quite fast, the system boot up now costed me about 4 weeks... The system boots from NFS or NOR Flash without problems until here: Code:
at91_rtc at91_rtc: setting system clock to 1998-01-01 00:00:11 UTC (883612811) I compared lot of things with ELDK as a concurrent build enviroment and found out, that if I mount the example romfs-image from ELDK via NFS it works down to busybox and shell. But it doesn't with buildroot. I also wrote a statically linked hello_world program and called it via kernel command line init=/bin/hello and it worked. I did the compile run with the buildroot tools, so these seem to work. As they also where used to build my kernel, I didn't expect anything else. So, now I am pretty stuck, as the kernel, busybox or whoever is the reason for the dying init, doesn't tell me anything why it's doing that. Can someone please tell me, how to enable debugging, or any other sort of things to find out the reason, why init dies? If there's someone who knows a bit more, what Du you need from my configs, logs or sources, I'll post it right away. But I am really stuck now, so any help is really appreciated, really :) Best regards and thanks in advance, Ulrich |
Quote:
Here is a link to a thread where the OP solved a similar problem by using an earlier kernel. |
Ok, yes, I saw this thread an read it twice. But the thing is, that I really like to get one of the latest kernels going with my system. You know, I am pretty new to kernel programming. I did programming with a lot of systems from 8 Bit to DVD Cores, but none of them was with a real runtime system. So I learn. While it was quite easy to write a board.c for my system and get it running with the kernel, I don't much about Linux programming, I think. I am more on the hardware side.
But neverthless I would like to learn. So may be you can take my by the hand and guide me a bit through it? I am shure it will help a lot of readers as I didn't find anything like that in all those discussion I am crawling through the last weeks. If you like, lets start here: I've edited init.c of buildroot and inserted some printk("INIT, I'm here...\n"); Unfortunately init.c doesn't know much of printk. If I'd like to include a header file for it I searched 'toolchain_build_arm/linux/include' where I guessed the header files of the kernel should be. But grepping for printk gives thousands of hits in hundrets of .h files. looking in kernel.h (buildroot/build_arm/staging_dir/usr/include/linux/kernel.h) shows only a small file not containing any printk definition. No printk... And I set buildroot compilation to abort on any error... Regards, Ulrich |
Quote:
Code:
397 static inline void free_area(unsigned long addr, unsigned long end, char *s) |
Ah, ok, I added the printk to the init.c of busybox, not the kernel.
I expected the busybox init function to die, not that one of the kernel... But checking for kernel.h in the buildroot system shows up, that the function is defined in 'project_build_arm/cmc_pu2/linux-2.6.27.10/include/linux/kernel.h' But that is not the directory where the files for busybox are referencing to. These are somwhere else inside the buildroot subtrees. So I messed something up there and busybox is build agains other headers? Or is buildroot doing something else? I am puzzled... But thanks for helping me. Regards, Ulrich |
Quote:
|
OK, something learned :)
But how to debug the reason of the crash then? I mean, I can put a lot of funny comments in the kernel's init.c but what could help me out of my problem. I thought the init of the busybox died, so the kernel should work. I thought you'd like me to put some debug in that busybox init and see, if it comes up and where it goes down. As the system runs into busybox and saying hello to me with a working shell if I use exactly the same kernel, but I mount the default rootfs from the LEDK system instead of the one generated by busybox, I expect the kernel to be fine so far, but either busybox or uclibc from buildroot is crappy. So how to debug that? Is there additional library debug possible, or memory debug, or can I put any other xprintx into the busybox to track down, the problem. Or should I throw buildroot into the yard and try ELDK? What is your idea to that, or with what toolchain did you have success on your systems? Regards, Ulrich |
Quote:
Code:
Freeing init memory: 128K Quote:
If kgdb is supported for your target, you can enable it and use GDB over serial or Ethernet to step through your kernel code. It is difficult to get kgdb setup the first time you use it, but it saves a lot of time tracking down these kind of problems. |
Quote:
Quote:
Best regards and a happy new year! Ulrich |
Quote:
|
maybe
please select your root filesystem while building your kernel. and compress your image with right format.. |
All times are GMT -5. The time now is 11:45 AM. |