Hello! Thanks for the reply and sorry that I have to write from a different account but my link to the host in germany seems to be down since two days now.
On Wed Mar 26, 2003 at 07:38:33 +0100, Fabian Sturm wrote:
When I then boot into it I see some messages of the RMGR but then the system is frozen.
Maybe someone knows what I should try next to track this down?
Which version of GRUB are you using? Is it "our" version from CVS?
Hmm I just took the newest from apha.gnu.org 0.93. I read that you have an own but I thought that is only needed if you have overlapping modules.
How did you configure Fiasco? Could you supply your configuration (globalconfig.out)!?
Sure. I followed the manual and did a make menuconfig in the build directory. I now also tried with the assertions compiled in but none gets triggered so far. Thansk a lot, Fabian # # Automatically generated, don't edit # # Generated on: californium # At: Wed, 26 Mar 2003 02:30:06 +0000 # Linux version 2.4.20 (root@californium) (gcc version 2.95.4 20011002 (Debian p rerelease)) #13 Thu Dec 5 19:48:30 EST 2002 # # Main menu # # # Compiler # CONFIG_USE_GCC=y CONFIG_USE_GCC_3_X=n # # Target Architectures # # # Target platform # CONFIG_IA32=y CONFIG_IA64=n CONFIG_ARM=n CONFIG_UX=n # # Kernel ABI Version # CONFIG_ABI_V2=y CONFIG_ABI_X0=n # # Target processor # CONFIG_IA32_586=y CONFIG_IA32_686=n CONFIG_IA32_K6=n CONFIG_IA32_K6_2=n CONFIG_IA32_K6_3=n CONFIG_ASSEMBLER_IPC_SHORTCUT=y CONFIG_SCHED_RTC=y CONFIG_SLOW_RTC=n CONFIG_DECEIT_BIT_DISABLES_SWITCH=n CONFIG_DISABLE_AUTO_SWITCH=n CONFIG_APIC_MASK=n CONFIG_POWERSAVE_GETCHAR=y CONFIG_X2_LIKE_SYS_CALLS=n CONFIG_SYNC_TSC=n CONFIG_SMALL_SPACES=n # # Kernel Debugging # CONFIG_INLINE=y CONFIG_NDEBUG=y CONFIG_PROFILE=n CONFIG_NO_FRAME_PTR=n CONFIG_KDB=y CONFIG_JDB=y CONFIG_JDB_LOGGING=n CONFIG_MAINTAINER_MODE=n # # Derived symbols # CONFIG_ABI="v2" CONFIG_IA32_TARGET="Intel Pentium" CONFIG_XARCH="ia32" CONFIG_SCHED_PIT=n # # That's all, folks!
On Wed, 2003-03-26 at 23:04, Fabian Sturm wrote:
Hmm I just took the newest from apha.gnu.org 0.93. I read that you have an own but I thought that is only needed if you have overlapping modules.
I think that is ok.
Sure. I followed the manual and did a make menuconfig in the build directory.
your config looks quite good. But how far do you get, did you see the Fiasco splash screen (shows up in nice green letters): Welcome to Fiasco(ia32)! DD-L4(v2)/x86 microkernel (C) 1998-2003 TU Dresden BUILD: Mar 26 2003 - gcc: 3.2.2 optimized for Intel Pentium 4 (you may have another build date and compiler and even optimization!) Or hangs your machine right before starting the Fiasco kernel (only RMGR output shows up)? -- Alexander Warg <alex.warg@gmx.net>
Sorry for the last question I should yous read the thread more carefully, the information I requested was already there. If the last line you see is the "Using the RTC on IRQ 8 (1khz) for scheduling" thing, the problem may come from sertial port stuff, do you have any serial port in your machine? If not try the -noserial option for the Fiasco kernel. This option prevents the kernel from starting the serial console. -- Alexander Warg <alex.warg@gmx.net>
Hello!
If the last line you see is the "Using the RTC on IRQ 8 (1khz) for scheduling" thing, the problem may come from sertial port stuff, do you have any serial port in your machine? If not try the -noserial option for the Fiasco kernel. This option prevents the kernel from starting the serial console.
Its true that I don't have any serial port, but even with this function it doesn't boot any further. I now tried to debug more of my problem with puts. Unfortunately I didn't have much results. I definitely now can say that I reach the last line of void Timer::init() in ia32/timer-rtc.c. (If I don't have sideeffects of puts and it is not buffered) What is initialized next I can only guess. It seems to be some kind of linker magic with the minilib/construction.c which calls all the functions which are declared with STATIC_INITIALIZER_P? I have put a puts in uart_console_init() before the line with the if strstr -noserial. But this already doesn't seem to be called. Or it is just not compiled in? I have also a puts in kdb.cpp in the void kdb::init() function. But it is never reached. Here I have some problems, why is the macro called with STATIC_INITIALIZE_P(kdb, KDB_INIT_PRIO); but only a kdb::init exists. And in uart_console.cpp it is STATIC_INITIALIZER_P(uart_console_init ,UART_INIT_PRIO); and a function uartconsole_init() exists. Hmm I am little bit confused now and would appreciate some advice for debbuging. Thanks a lot, Fabian
On Sat, 2003-03-29 at 07:52, Fabian Sturm wrote:
Its true that I don't have any serial port, but even with this function it doesn't boot any further.
I now tried to debug more of my problem with puts. Unfortunately I didn't have much results. I definitely now can say that I reach the last line of void Timer::init() in ia32/timer-rtc.c. (If I don't have sideeffects of puts and it is not buffered)
There should be no side effects on puts, and the output is completely unbuffered. I'm not sure which constructors are called after the Timer, but I'll look for it tomorrow.
What is initialized next I can only guess. It seems to be some kind of linker magic with the minilib/construction.c which calls all the functions which are declared with STATIC_INITIALIZER_P?
The "magic" in construction.c does simply run all C++ and C constructors, that is not our invention but C standard. The STATIC_INITIALIZE[R][_P] macros declare certain functions as such constructors. The ...INITIALIZER (you see the R) macros are for declaring a special function as constructor and the variants without the R are for static initialization of classes that must have a static init method per convention. The last thing is the _P at the end, these macros take a second argument specifing the priority of the constructor (needed if the order of construction is relevant).
I have put a puts in uart_console_init() before the line with the if strstr -noserial. But this already doesn't seem to be called. Or it is just not compiled in?
I saw you have enabled KDB (GDB debugging stub) in your config, and in that case the uart_console_init() function is indeed not called because the GDB stub is responsible for handling the UART, if you have no UART you should say 'no' to the GDB debugger stub (KDB) option, because it tries to enable the UART on bootup. (It should not with -noserial, but it is safer to say 'no' for your setup.)
I have also a puts in kdb.cpp in the void kdb::init() function. But it is never reached.
I'll look for the concrete bootup sequence tomorrow and try to give some further advice.
Here I have some problems, why is the macro called with STATIC_INITIALIZE_P(kdb, KDB_INIT_PRIO); but only a kdb::init exists.
see above.
And in uart_console.cpp it is STATIC_INITIALIZER_P(uart_console_init ,UART_INIT_PRIO); and a function uartconsole_init() exists.
see above.
Hmm I am little bit confused now and would appreciate some advice for debbuging.
I hope there I could clear some confusions. -- Alexander Warg <alex.warg@gmx.net>
Hello! On Sun, Mar 30, 2003 at 05:14:10PM +0200, Alexander Warg wrote:
I'm not sure which constructors are called after the Timer, but I'll look for it tomorrow.
It still would be interesting to see if the order of the constructors is different than what is defined in static_init? Probably not. What I mainly missed was the point that not all classes were initialized because they were excluded with the configure options. Mainly the UART_INIT_PRIO and KDB_INIT_PRIO are interchanged (if I got it right). So your guess was definitv right! It was the non existing serial port which gets configured by the built in kdb. In kdb.c is a line with: if(strstr(cmdline, " -nokdb") || strstr(cmdline, " -noserial") but this comes only after: Uart *com = Kernel_uart::uart(); So the -noserial has not the effect I would need. Maybe it would make sense to interchange the two lines? Or split the check up into if(strstr(cmdline, " -noserial")) { disconnect(); return; } Uart *com = Kernel_uart::uart(); if(strstr(cmdline, " -nokdb")) { disconnect(); return; } if kdb can work without a serial port. If I follow the uart call I can track it down to this part of code in drivers/uart-16550.cpp: Proc::Status o = Proc::cli_save(); ier( 0 ); /* disable all rs-232 interrupts */ mcr( 0x0b ); /* out2, rts, and dtr enabled */ fcr( 1 ); /* enable fifo */ fcr( 0x07 ); /* clear rcv xmit fifo */ fcr( 1 ); /* enable fifo */ lcr( 0 ); /* clear line control register */ /* clearall interrupts */ /*read*/ msr(); /* IRQID 0*/ /*read*/ iir(); /* IRQID 1*/ /*read*/ trb(); /* IRQID 2*/ /*read*/ lsr(); /* IRQID 3*/ while(lsr() & 1/*DATA READY*/) /*read*/ trb(); Proc::sti_restore(o); It hangs somewhere in here, due to non existing port. So if I disable kdb everything works fine and I end up in the jdb prompt, and if continued with g I get the hello world output!
What is initialized next I can only guess. It seems to be some kind of linker magic with the minilib/construction.c which calls all the functions which are declared with STATIC_INITIALIZER_P?
The "magic" in construction.c does simply run all C++ and C
Sorry my fault. The problem why I called it magic was because I didn't saw the additional "R". With that it makes sense, because it ends up in two different macros.
STATIC_INITIALIZE_P(kdb, KDB_INIT_PRIO); STATIC_INITIALIZER_P(uart_console_init ,UART_INIT_PRIO);
Thanks a lot, Fabian
Hi, On Mon, 2003-03-31 at 01:02, Fabian Sturm wrote:
It still would be interesting to see if the order of the constructors is different than what is defined in static_init? Probably not.
The order should never differ from the definitions in static_init. And only link-time configurable features should use STATIC_INITIALIZE... or INIT_PRIORITY... all fixed constructors should either use the C++ language or startup.cpp for initialization.
What I mainly missed was the point that not all classes were initialized because they were excluded with the configure options. Mainly the UART_INIT_PRIO and KDB_INIT_PRIO are interchanged (if I got it right).
Not completely, if KDB is used the module that fires up the UART is simply not linked to the final kernel, instead the KDB module is compiled and linked to the kernel and has to fire up the UART on it's own. So, you simply disable some features by not linking them and thus not starting their constructors. This does not change something with the order of construction. I think there should be something like the 'Documentation' directory in Linux, where things like static_init, etc. are explained.
So your guess was definitv right! It was the non existing serial port which gets configured by the built in kdb.
In kdb.c is a line with:
if(strstr(cmdline, " -nokdb") || strstr(cmdline, " -noserial")
This is a BUG, we never explored, because we only have machines with serial ports and use a serial console for debugging most of the time. The reason for -noserial was to disable serial ports to not have the slowdown introduced by the serial traffic. Oh and last but not least, it maybe I have introduced the BUG during the rewrite of the serial driver! Sorry!
if kdb can work without a serial port.
It can't it is for connecting GDB via a serial stub, but our stub is a bit outdated so an old GDB is needed.
It hangs somewhere in here, due to non existing port. So if I disable kdb everything works fine and I end up in the jdb prompt, and if continued with g I get the hello world output!
We should add serial port probing I think. I hope you don't get confused or crazy while you're using Fiasco. Thanks a lot for your report. -- Alexander Warg <alex.warg@gmx.net>
Hello On Mon, Mar 31, 2003 at 03:00:43PM +0200, Alexander Warg wrote:
Hi,
This is a BUG, we never explored, because we only have machines with serial ports and use a serial console for debugging most of the time. The reason for -noserial was to disable serial ports to not have the slowdown introduced by the serial traffic.
hmm I'm a bit confused about your fix. I didn't actually run it but from how I read this it still initializes the serial console even if -noserial is given? Uart *com = 0; if(strstr(cmdline, " -nokdb") || strstr(cmdline, " -noserial")) { com = Kernel_uart::uart(); disconnect(); return; } shouldn't uart() be only called in the case -noserial is not given? So you must move the com line down a little bit more.
I hope you don't get confused or crazy while you're using Fiasco.
Definitely not! I like it, but I am a little bit weak when it comes to c++ object initialization... Unfortunately I will probably have to bother this list with more questions soon since I'm doing a college project about fiasco/drops. Thanks, Fabian
On Tue, 1 Apr 2003 02:21:49 +0200 Fabian Sturm (FS) wrote: FS> hmm I'm a bit confused about your fix. I didn't actually run it FS> but from how I read this it still initializes the serial FS> console even if -noserial is given? That's how I read it, too. FS> shouldn't uart() be only called in the case -noserial is not given? FS> So you must move the com line down a little bit more. Yep, patch below. -Udo. Index: kdb.cpp =================================================================== RCS file: /home/cvs/l4/kernel/fiasco/src/kern/kdb.cpp,v retrieving revision 1.23 diff -u -1 -b -p -r1.23 kdb.cpp --- kdb.cpp 31 Mar 2003 13:17:41 -0000 1.23 +++ kdb.cpp 1 Apr 2003 00:35:50 -0000 @@ -147,7 +147,4 @@ void kdb::init() - Uart *com = 0; - if(strstr(cmdline, " -nokdb") || strstr(cmdline, " -noserial")) { - com = Kernel_uart::uart(); disconnect(); @@ -156,3 +153,3 @@ void kdb::init() - + Uart *com = Kernel_uart::uart();
participants (4)
-
Alexander Warg -
Fabian Sturm -
Fabian Sturm -
Udo A. Steinberg