the problems of l4linux

[chenggh]

> > __stack_chk_fail". This bug has been reported many times and has
> > committed to the Ubuntu Bug List.  But bug is as before.
>
> That's no bug, it's a stack protection feature they use. I didn't really
> care because I do not use Ubuntu myself but I think we have to work
> around this.
	Yes, basically it is not a bug but I should have used fno-stack-protector to 
fix the problem.  But later I found although I use fno-stack-protector the 
problem is still. I google the key word __stack_chk_fail and there are lots 
of people with same problem as me. So I think it is a bug of glic problem.
> > 	The first question:
> > 	the l4 boot log is like this:
> > l4lx    | l4lx_thread_create: Created thread 10.16 (IRQ5)
> > l4lx    | l4lx_irq_dev_startup_hw: Starting IRQ thread for IRQ 4.
> > l4lx    | l4lx_thread_create: Created thread 10.17 (IRQ4)
> > l4lx    | l4lx_irq_dev_startup_hw: Starting IRQ thread for IRQ 3.
> > l4lx    | l4lx_irq_dev_startup_hw: Starting IRQ thread for IRQ 2.
> > l4lx    | acquire_irq: Error attaching to IRQ 2
> > l4lx    | l4lx_thread_create: Created thread 10.19 (IRQ2)
> > l4lx    | l4lx_irq_dev_startup_hw: Starting IRQ thread for IRQ 1.
> > l4lx    | acquire_irq: Error attaching to IRQ 1
> > 	It seems that when attaching IRQ1, IRQ2, IRQ9, IRQ12 there are some
> > errors like "acquire_irq: Error attaching to IRQ x". But later attaching
> > IRQ is ok. What is the matter? IRQ1 and IRQ12 are related with keyboard
> > and monse, IRQ2 is related with cascade, IRQ9 is about acpi. I have
> > removed these drivers from linux. why is it also like this?
> Think about who is supposed to have these IRQs. Keyboard and Mouse are
> already taken by the windowing/console system, so Linux can obviously
> not get them. So it is really ok that attaching those IRQs fail, it's
> supposed to be like this.
	Thanks. I think I should read the l4linux code and later if I encouter the 
similar question I could understand. :)
> > 	The second problem is:
> > 	The Linux booting  stops at /ect/random-seed to initialize /dev/urandom
> > and there is no login interface. I have checked the normal linux booting
> > and after the using /ect/random-seed to initialize /dev/urandom the linux
> > will finish booting kernel, enter the linux user space "INIT: Entering
> > init X". So I think it is still the problem of l4linux kernel not the
> > special linux distribution. Is it right?
>
> Same question: Is your Slackware starting a login on tty1? What happens
> with normal Linux? You may want to disable your X for the test and check
> your /etc/inittab.
	Not ,the problem is also. I disable X and try to boot l4linux on ttyLv0. The 
Linux also stops here "/ect/random-seed to initialize /dev/urandom". There is 
an attachment which is my inittab.
	Thanks.
							Cheng Guanghui
-------------- next part --------------
#
# inittab	This file describes how the INIT process should set up
#		the system in a certain run-level.
#
# Version:	@(#)inittab		2.04	17/05/93	MvS
#                                       2.10    02/10/95        PV
#                                       3.00    02/06/1999      PV
#                                       4.00    04/10/2002      PV
#
# Author:	Miquel van Smoorenburg, <miquels at drinkel.nl.mugnet.org>
# Modified by:	Patrick J. Volkerding, <volkerdi at slackware.com>
#

# These are the default runlevels in Slackware:
#   0 = halt
#   1 = single user mode
#   2 = unused (but configured the same as runlevel 3)
#   3 = multiuser mode (default Slackware runlevel)
#   4 = X11 with KDM/GDM/XDM (session managers)
#   5 = unused (but configured the same as runlevel 3)
#   6 = reboot

# Default runlevel. (Do not set to 0 or 6)
id:3:initdefault:

# System initialization (runs when system boots).
si:S:sysinit:/etc/rc.d/rc.S

# Script to run when going single user (runlevel 1).
su:1S:wait:/etc/rc.d/rc.K

# Script to run when going multi user.
rc:2345:wait:/etc/rc.d/rc.M

# What to do at the "Three Finger Salute".
ca::ctrlaltdel:/sbin/shutdown -t5 -r now

# Runlevel 0 halts the system.
l0:0:wait:/etc/rc.d/rc.0

# Runlevel 6 reboots the system.
l6:6:wait:/etc/rc.d/rc.6

# What to do when power fails.
pf::powerfail:/sbin/genpowerfail start

# If power is back, cancel the running shutdown.
pg::powerokwait:/sbin/genpowerfail stop

# These are the standard console login getties in multiuser mode:
c1:1235:respawn:/sbin/agetty 38400 tty1 linux
c2:1235:respawn:/sbin/agetty 38400 tty2 linux
c3:1235:respawn:/sbin/agetty 38400 tty3 linux
c4:1235:respawn:/sbin/agetty 38400 tty4 linux
c5:1235:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

# Local serial lines:
#s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
#s2:12345:respawn:/sbin/agetty -L ttyS1 9600 vt100

# Dialup lines:
#d1:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS0 vt100
#d2:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS1 vt100

# Runlevel 4 used to be for an X window only system, until we discovered
# that it throws init into a loop that keeps your load avg at least 1 all 
# the time. Thus, there is now one getty opened on tty6. Hopefully no one
# will notice. ;^)
# It might not be bad to have one text console anyway, in case something 
# happens to X.
x1:4:respawn:/etc/rc.d/rc.4

# End of /etc/inittab