init process freezed after run_init_process

init process freezed after run_init_process

[rjy]

Hi,

My computer freezed after the kernel start. It started
with normal console messages and stopped with these messages:
------------------------------
... (just as the normal ones.)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Bridge firewalling registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 136k freed
------------------------------
The kernel started successfully: it echos on keyboard pressing.
But the init process just REFUSE to work. GOD !

This is my grub config:
-----------------------------
root (hd0,0)
kernel /bzImage.via.386 root=/dev/ram0 rw ramdisk=49152
initrd /initrd.gz
-----------------------------

My CPU is VIA Samuel 2. Memory 128M. Chipset VIA VT82C686.
I configed my kernel with CyrixIII CPU family type,
and with RAM, INITRD and ext2/3 also on.

This kernel can work properly without initrd and ramdisk.
This kernel can work properly on intel CPU and chipset
even with initrd and ramdisk. :( Have I missed something?

I have KGDBed the starting process and run_init_process
returned OK: initrd decompressed properly and open_exec
returned non-zero.

Any instructions, references, or insight much appreciated.

Thanks

Re: init process freezed after run_init_process

[rjy]

Thanks for kindly reply, :)

Jan Engelhardt wrote:
>>This is my grub config:
>>-----------------------------
>>root (hd0,0)
>>kernel /bzImage.via.386 root=/dev/ram0 rw ramdisk=49152
>>initrd /initrd.gz
>>-----------------------------
> 
> 
> Does it work if you add "  ramdisk=65536 init=/linuxrc " ?

No. I got the same problem without linuxrc.
As I mount ram0 as root, linuxrc is not necessary. Right?

> 
> 
>>returned OK: initrd decompressed properly and open_exec
>>returned non-zero.
> 
> 
> If you use k[g]db, you should be able to find out where the kernel actually 
> hangs.

After some digging, I found that the starting process of the VIA platform
and the intel platform is exactly the same:

1) checking if image is initramfs...it isn't (no cpio magic); looks like 
an initrd
    Freeing initrd memory: 9553k freed
2) loading drivers ...
3) RAMDISK: Compressed image found at block 0
    kjournald starting.  Commit interval 5 seconds
    EXT3 FS on ram0, internal journal
    EXT3-fs: mounted filesystem with ordered data mode.
    VFS: Mounted root (ext3 filesystem).
    Freeing unused kernel memory: 128k freed

If I put the same hard disk into a intel platform without any change, it
can start properly, loading the same initrd as rootfs.

And also, if I remote the initrd config in VIA platform and mount my 
hard disk as rootfs, it also works properly.

I missed some driver for VIA platform?  Why it can work without initrd?
My initrd has an invalid format? Why it can work on intel platform?
I am really confused...

After the starting process, the /sbin/init is loaded: I found that in
a breakpoint of do_schedule. It keeps scheduling init and pdflush.
I am still finding the way to debug the init process...

> 
> 
> 
> Jan Engelhardt

Re: init process freezed after run_init_process

[Jan Engelhardt]

> Thanks for kindly reply, :)
>
> No. I got the same problem without linuxrc.
> As I mount ram0 as root, linuxrc is not necessary. Right?

Apply these rules:
1.) If you do provide an initrd= thing, the initrd is being looked for 
/linuxrc.
2.) If the root is the same as the ramdisk, then the initrd is _not_ run 
_implicitly_, and thus /sbin/init is executed, _instead of_ /linuxrc.

> I missed some driver for VIA platform?  Why it can work without initrd?

Only VIA IDE chipset maybe, but you don't usually need that for just-initrd.
You'd need that for the harddisks...

> After the starting process, the /sbin/init is loaded: I found that in
> a breakpoint of do_schedule. It keeps scheduling init and pdflush.
> I am still finding the way to debug the init process...

Make your own initrd and put a bash into it. Then start that, e.g. (for our 
linux live cd), initrd=initrd.sqfs root=/dev/ram0 init=/bin/bash


Jan Engelhardt
-- 
No TOFU for me, please.

Re: init process freezed after run_init_process

[rjy]

> Apply these rules:
> 1.) If you do provide an initrd= thing, the initrd is being looked for 
> /linuxrc.

I have add /linuxrc, /init and /bin/init, all link to /sbin/init.
It just refuses to work ... :(

> Only VIA IDE chipset maybe, but you don't usually need that for just-initrd.
> You'd need that for the harddisks...

My harddisk works fine without initrd.

> 
> Make your own initrd and put a bash into it. Then start that, e.g. (for our 
> linux live cd), initrd=initrd.sqfs root=/dev/ram0 init=/bin/bash

I have tried these kernel parameters:
	init=/bin/bash
	init=/linuxrc
	init=/init
	init=/sbin/init
None works.

Also, after some google, I found that the format of initrd has changed.
I also tried a new initrd with cpio format. The kernel recognized it:
	Boot Logs:
	1) checking if image is initramfs... it is
	   Freeing initrd memory: 17583k freed
	2) loading drivers
	3) Freeing unused kernel memory: 128k freed

After the kernel start, I add breakpoints at cpu_idle and do_schedule.
cpu_idle never reached, only do_schedule did. Is that strange?

Re: init process freezed after run_init_process

[Jan Engelhardt]

>> Make your own initrd and put a bash into it. Then start that, e.g. (for
>> our linux live cd), initrd=initrd.sqfs root=/dev/ram0 init=/bin/bash
>
> I have tried these kernel parameters:
> init=/bin/bash
> init=/linuxrc
> init=/init
> init=/sbin/init
> None works.

What's the error message?

> Also, after some google, I found that the format of initrd has changed.
> I also tried a new initrd with cpio format. The kernel recognized it:

cpio initrd's (aka initramfs) are new - the "old style" initrd where you
`mksquasfs mydir initrd.sqfs` (see above) continues to work, though.

> After the kernel start, I add breakpoints at cpu_idle and do_schedule.
> cpu_idle never reached, only do_schedule did. Is that strange?

Until pid 1 is started, the cpu should never be idle.


Jan Engelhardt
-- 
No TOFU for me, please.

Re: init process freezed after run_init_process

[rjy]

Jan Engelhardt wrote:
>>>Make your own initrd and put a bash into it. Then start that, e.g. (for
>>>our linux live cd), initrd=initrd.sqfs root=/dev/ram0 init=/bin/bash
>>
>>I have tried these kernel parameters:
>>init=/bin/bash
>>init=/linuxrc
>>init=/init
>>init=/sbin/init
>>None works.
> 
> 
> What's the error message?

No error message at all. System seems freezed after spit out this message:
	Freeing unused kernel memory: 136k freed
The console echos the keyboard inputs.

It seems that the init started successfully: I attached the output
of "info threads" and "backtrace" after the system freezing.

I am digging the source these days and try to find out if the init
process has really been started. I found some difference between
the normal init process and the freezed init process:
----------------------------------------------------------------
		| Normal init		| Freezed init
----------------------------------------------------------------
mm->total_vm	| 0x145			| 0x1e
mm->map_count	| 9			| 5
----------------------------------------------------------------

Maybe, init is not loaded completely? Or just loaded an invalid one?
I am trying to dump the text segment at user space 0x08040000 of the
init process. But I have not found the way to find the related kernel 
space address. Any clue? Thanks! :)

> 
> 
>>Also, after some google, I found that the format of initrd has changed.
>>I also tried a new initrd with cpio format. The kernel recognized it:
> 
> 
> cpio initrd's (aka initramfs) are new - the "old style" initrd where you
> `mksquasfs mydir initrd.sqfs` (see above) continues to work, though.
> 
> 
>>After the kernel start, I add breakpoints at cpu_idle and do_schedule.
>>cpu_idle never reached, only do_schedule did. Is that strange?
> 
> 
> Until pid 1 is started, the cpu should never be idle.
> 
> 
> Jan Engelhardt

It seems that the init process is started:
(gdb) info threads
   11 Thread 123 (kseriod)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
   10 Thread 9 (aio/0)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
   9 Thread 8 (kswapd0)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
   8 Thread 7 (pdflush)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
   7 Thread 6 (pdflush)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
   6 Thread 5 (khelper)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
   5 Thread 4 (kblockd/0)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
   4 Thread 3 (events/0)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
   3 Thread 2 (ksoftirqd/0)  0xc032d485 in do_schedule () at 
/kernel/via/kgdb/kernel/sched.c:923
* 2 Thread 1 (init)  breakpoint () at /kernel/via/kgdb/kernel/kgdb.c:1212
   1 Thread 32768 (Shadow task 0 for pid 0)  0xc032d485 in do_schedule 
() at /kernel/via/kgdb/kernel/sched.c:923

(gdb) bt
#0  breakpoint () at /kernel/via/kgdb/kernel/kgdb.c:1212
#1  0xc774fec4 in ?? ()
#2  0xc010893b in do_IRQ (regs=
       {ebx = -948641792, ecx = -948577792, edx = -944260388, esi = 0, 
edi = -948641792, ebp = -948633844, eax = -944260388, xds = 123, xes = 
123, orig_eax = -252, eip = -1072517263, xcs = 96, eflags = 646, esp = 
-948633660, xss = -948576428})
     at /kernel/via/kgdb/arch/i386/kernel/irq.c:574
#3  0xc0106888 in common_interrupt ()
#4  0xc01063f6 in do_signal (regs=0xc774e000, oldset=0x0) at 
/kernel/via/kgdb/arch/i386/kernel/signal.c:581
#5  0xc01064d9 in do_notify_resume (regs=0xc774ffc4, oldset=0x0, 
thread_info_flags=1)
     at /kernel/via/kgdb/arch/i386/kernel/signal.c:629