Problems with l4linux
Valery V. Sedletski
_valerius at mail.ru
Fri Nov 14 08:59:19 CET 2008
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
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 etc.)
>> -- 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. 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.
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?) 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?)
>> 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
>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?
valerius @ EFnet IRC #os2russian, #osFree
More information about the l4-hackers