Problems with l4linux
adam at os.inf.tu-dresden.de
Thu Nov 20 19:50:07 CET 2008
On Fri Nov 14, 2008 at 19:59:19 +1200, Valery V. Sedletski wrote:
> On Wed, 12 Nov 2008 23:13:33 +0100, Adam Lackorzynski wrote:
> >On Tue Nov 11, 2008 at 01:20:20 +1200, Valery V. Sedletski wrote:
> >> On Wed, 5 Nov 2008 22:25:19 +0100, Adam Lackorzynski wrote:
> >> >
> >> >> > The above message would mean that the X server is talking to the
> >> >> > L4Linux-server which is a no-go except the special X driver is used.
> >> >> >
> >> >>
> >> >> I enabled X server stub in L4Linux configuration (a checkbox "Support for X
> >> >> Window System driver" is enabled). And nitovlwm server is started. What could
> >> >> I miss then?
> >> >
> >> >This setup is not the easiest one and not easy to setup, it also
> >> >requires quite an effort for me to get this running. I recommend using
> >> >the X 'fbdev' driver which basically just works out of the box. It isn't
> >> >as CPU friendly as it could be but the handling is easy. Using a special
> >> >X driver is better in several ways but requires some care.
> >> Yes, I know that this setup is not easy. For overlay_wm driver to work
> >> it is necessary to apply patches to X Server sources, as I read.
> >It's a driver.
> >> But I thought it must work with linux server with ordinary l4con/dope
> >> frambuffer driver. So, it won't, ok.
> >It's really supposed to work with the 'fbdev' X driver. At least it does
> >for me.
> I meant that special driver inside X Server is needed. (for seamless
> integration of X with Nitpicker desktop). I just thought that X
> version in drops-x.rd ramdisk will work with any L4Linux setup, but it
> appears that not (not yet understand why, maybe X stub in different
> L4Linux versions talks other way with seamless X Server driver and
> need to be recompiled each time? -- backward incompatible protocols
Unfortunately cannot tell what might be wrong without looking deeply
> >> -- When I checked on real machine
> >> (not with ramdisk), l4linux started and XServer starts OK.
> >> But again the new problem -- with udev. First time for some reason
> >> udev didn't started and /sys filesystem did not mounted (it was some
> >> problem with initial ramdisk). When I mounted /sys manually, created
> >> all device nodes manually and started udevd from the command line,
> >> almost all worked -- bluetooth, usb, etc. But when I made initrd
> >> properly, I got an error "Kernel panic: not syncing, Out of memory and
> >> no killable processes" when starting udev. I can't copy/paste the boot
> >> log as nothing were saved in logs. How can I report this problem? I
> >> can't also redirect output to file as system is not syncing (I booted
> >> with init=/bin/sh successfully and then panic message appears if
> >> launch /sbin/start_udev from the command line).
> >It would be helpful if you could construct an image that shows the
> >problem and which I could have to look at. Otherwise it's hard to me to
> >tell what's going on in your setup.
> I'll try making bootable iso image. But maybe, my problem is not easy to
> reproduce on different machine -- I tried to install the same Linux distribution
> on my desktop machine and copied there the same compiled L4Linux kernel.
> Now L4Linux boots successfully without panic, but displays errors with call
> trace (non- fatal -- no panic but console hangs). The errors appear during the
> loading agpgart and amd64-agp modules. (This machine is AMD Athlon 64 with
> VIA chipset and 1 Gig RAM and Matrox G400 card in AGP slot). When I renamed
> these drivers (I yet not found where in Linux they are switched off -- the 2.6
> version kernel is new for me, and I need a time to understand udev configs) it loads OK
> without problems at all.
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
> 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?
> 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.
> 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.
> >> I tried to upgrade udev to the latest version (I have ver. 1.14 and
> >> the newest one is 1.30) but no effect. Also I searched for this error
> >> message in google and found a few references to mailing lists where
> >> Fedora and Slackware users mentioned similar problem -- it was not
> >> with udev itself but with latest kernels -- with 2.6.24 this were OK,
> >> but with 2.6.25 and later were these problems. So, I decided to try
> >> downgrading l4linux kernel. I tried many revisions from SVN from
> >> 2.6.27 down to 2.6.22 with no success -- Linux was either panicing or
> >> handing when starting udev.
> >I think downgrading Linux is not the way fixing this. Knowing the real
> >reason would be very helpful. Did you try strace e.g.?
> Strace? What is it? Is this a Linux or Fiasco feature? (ok, silly question, I'll
> try googling)
> >Can you build me a little example which shows the problem? I think that
> >would be quite helpful.
> I'll make a bootable ISO image and upload it somewhere. Is rapidshare or
> similar servers OK?
Something where wget works is ok.
On Fri Nov 14, 2008 at 22:36:31 +1200, Valery V. Sedletski wrote:
> On Fri, 14 Nov 2008 19:59:19 +1200 (MSK), Valery V. Sedletski wrote:
> >On Wed, 12 Nov 2008 23:13:33 +0100, Adam Lackorzynski wrote:
> >>I think downgrading Linux is not the way fixing this. Knowing the real
> >>reason would be very helpful. Did you try strace e.g.?
> >Strace? What is it? Is this a Linux or Fiasco feature? (ok, silly question, I'll
> >try googling)
> I tried booting with init=/bin/sh and executing "strace /sbin/start_udev" after
> manually mounting /sys and /proc. (udevd exits when /sys is not mounted).
> It prints a syscall trace, but it get running quickly, and at the end of process
> I get a Kernel panic message with call trace messages which are filling all
> screen and I can't see strace output as I can't scroll screen buffer back by
> Shift-PgUp because linux is dead, Also I tried to redirect strace messages to
> file but filesystems are mounted readonly and can't write files to disk. Also
> when panic occurs, linux doesn't sync files with cache. So, I'm in a spot. :(
> What else can I do?
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
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers