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

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

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