Problems with l4linux

[Valery V. Sedletski]

On Thu, 20 Nov 2008 19:50:07 +0100, Adam Lackorzynski wrote:

>
>Those low-level things like GART are not unproblematic, best avoid them
>if they seem to make problems (or proper analyse what's going on, much
>harder...).
>

Yes, I'm trying to avoid them by now. On my desktop computer (AMD64) I
disabled GART & Co. And on my notebook I disabled iTCO_vendor_support.ko
and iTCO_wdt.ko (something watchdog-related) -- they were causing errors with 
call traces which hang the console.

And the most interesting thing -- I found that when adding --isa=0x00800000 to 
the dm_phys commandline, the panic message disappears and Linux boots OK
without errors at all! -- This does something with ISA DMA memory, as I read.
It is strange that on AMD64 Linux boots OK without it, but it is needed on the
notebook. So, maybe, this panic message is not a problem at all -- this is only
configuration problem? Does this make the problem clear or is bootable ISO 
still needed (I'll trying to make it soon, yet encountered some problems with it --
and I can't reproduce the problem on desktop computer -- must figure out, on what
type of hardware it appear. With qemu, all boots OK, so it seems not to be useful, as
its emulated hardware does not cause problems, with no regard of --isa=... option)
And still no additional messages either on linux console or on log server, only "Kernel 
Panic, not syncing, out of memory and no killable processes". And also "panic, waiting 
forever.." on log server. I can make screenshot though, but no useful info here. Maybe,
I can recompile with additional debug messages enabled? I added "earlyprintk=1" and
"console=ttyLv0" but still no additional messages.

>> On my notebook I have ATI Radeon X300 Mobility PCI-express card, so,
>> loading AGP drivers have no sense. As with desktop machine, I supposed
>> that on notebook kernel panic occurs when loading some driver (maybe,
>> video related -- I am not sure, if it makes a sense to load them in
>> l4linux), but when I renamed all suspectable drivers, there were no
>> errors with call traces, but the single kernel panic message remains,
>> without other messages which could tell what causes it.
>
>Tried earlyprintk=1 on the Linux  kernel command line?
>

Thanks, I added it.

>> As I said, the notebook has no comports (I only have PCMCIA serial
>> card and USB-to-serial converter); but desktop has them -- when I
>> attached a nullmodem cable to the desktop (and connected from the
>> notebook with terminal program using usbserial converter), I got debug
>> messages from log server, but found nothing suspected (I could post
>> logs there, but there are no call traces or other error messages in
>> them -- maybe, there is a way to say linux to redirect error messages
>> and call traces to log server?)
>
>There is. In the L4Linux configuration, in the Stub-drivers sub-menu,
>enable 'Serial driver' and then use console=ttyLv0 on the kernel command
>line. This should do the trick.
>

Now I got an empty linux console which begin output messages only starting 
with init process messages. Log server output ends with messages from interrupt 
service threads attaching to interrupts. But an error appears that linux cannot open
/dev/console. I specified console=ttyLv0 but it still tries to open /dev/console. And, 
maybe, /dev/ttyLv0 must be created, but I don't know its major and minor numbers.

>> Maybe, there is something to redirect
>> log server messages through network or similar way, not via commport?
>> Or, maybe, it's possible to redirect linux messages to log server and
>> then from the same machine, to get/view these logs using l4env
>> servers, not linux itself (linux is dead but l4env remains alive and
>> maybe, I can get some post-mortem info, like logs or task memory dump
>> or etc? Or get and save a trace buffer or similar?) (Just an idea --
>> what if include simple http server in l4env and serve log server
>> messages, so, they can be viewed from any web browser? Maybe,
>> something like this already exist?)
>
>There's the dmon application which is a DOpE application and a
>log-server, i.e. it display log-messages in a window.
>The other ideas are nice but do not exist.
>

Thanks. I also found a logcon application in l4con examples which is a l4con-aware
log server. So, viewing log server messages is also possible in l4con environment --
I tried this, it works. Also, 1) with events server I was able to restart l4linux without rebooting
-- just do Ctrl-Alt-Del in linux and then "l" option in run application to start it again. 2) by specifying
"allow_cli" I was able to reboot computer in "run" application by pressing a tilde ("~") button. But
3) specifying "allow_cli" in run loader script was not sufficient to kill tasks with "run". When I try 
killing a hung L4Linux, a message appears in log that task F (run) is not allowed to kill tasks. 
Maybe, some additional option (to the "allow_cli" one) is needed?

According the http server -- when I read the log server docs, I found that there is "--net" option that
allow to access log server output via telnet! -- So, it appears that my idea is already implemented ;-)
But this feature supports only four ethernet cards, unfortunately. I have rtl 8169 Gigabit ethernet and
also have NE2000 compatible PCMCIA card on the laptop, but as I understood, PCMCIA is not 
supported (though, there is NE2000 support in log server) and 8169 is also don't supported. ;(

>
>I'd like to see the panic message, with the backtrace etc. to be better
>able to judge what's going on. A classical screen-shot would also be ok.
>Have you considered trying QEmu to play around? This makes all those
>issues go away because you get the serial output into your terminal
>etc...
>

As I said, no success with qemu as Linux boots OK with it. The backtrace is possible with calling 
strace when booting with init=/bin/sh and starting UDEV manually under strace. But here redirecting
output to log server is needed, but "console=ttyLv0" still don't work. I can make screenshots then.

WBR, 
valery

PS: I forgot to mention -- returning to the problem with GPRS modem card -- this modem is not unique in that
it don't work because of not getting high I/O memory area. -- I tried also two dialup PCMCIA modems (detected
as ordinary PCMCIA modem/serial card) and one Cardbus serial card -- the same problem -- can't reserve high
I/O memory region. So, this problem is not unique to my GPRS card, but it can be reproduced with any standard 
PCMCIA serial/modem card. (Just to know that this problem is common to all PCMCIA serial devices).