the problems of l4linux
adam at os.inf.tu-dresden.de
Sat Sep 22 00:19:35 CEST 2007
On Thu Sep 20, 2007 at 17:59:41 +0000, chenggh wrote:
> > > __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.
If google finds many pages with something this doesn't mean all those
pages show the truth just because they are so many.
Using -fno-stack-protector is fine as long as _all_ code is compiled
with this option. When linking against code that is built _with_
the stack-protection feature enabled that compile time option won't help
you. This happens e.g. when linking against libraries supplied by gcc.
On Ubuntu those libraries are built with the stack protection feature
enabled. To fix this you either rebuild gcc-libs with stack protection
or provide those symbols. The latter seems far more convenient.
> > > 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.
When using ttyLv0 as a console you also need to start a getty there,
similar to an ttyS0 entry. Otherwise no login prompt will appear there.
My inittab looks a bit different but I don't see some obvious reasons
why yours isn't popping up a login-prompt on tty1, at least on the first
Just booting to single user mode works?
> # 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)
> # System initialization (runs when system boots).
> # Script to run when going single user (runlevel 1).
> # Script to run when going multi user.
> # What to do at the "Three Finger Salute".
> ca::ctrlaltdel:/sbin/shutdown -t5 -r now
> # Runlevel 0 halts the system.
> # Runlevel 6 reboots the system.
> # 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.
> # End of /etc/inittab
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers