l4-hackers December 1998

l4-hackers@os.inf.tu-dresden.de

11 participants
18 discussions

Re: page size assertion
by Eiji Ota 09 Dec '98

09 Dec '98

Michael-san, > Please try the patch appended below. > > I still would like to know which program triggers this problem as I > have not been able to reproduce it. Even after applying it, the same trouble happened. As my trial, I commented out that assertion in space.cc and the system seemed to work at that time.... However, I missed the important point, which I didn't know until that time. I used i486 PC-note(old, old note PC) and I set -nopentium to rmgr, it worked... i486 doesn't support a large page, does it ? oh, I'm sorry that you worry about a funny thing and I appreciate your advice because I thought you forgot this. Regards, Eiji Ota PS. Another funny thing. After removing the assertion, it worked even on i486. It might happen to work at that time...

1 0

New Fiasco snapshot
by Michael Hohmuth 07 Dec '98

07 Dec '98

I have released a new Fiasco snapshot (0.5.1, dated 981207) which has integrated all patches which have been posted to this mailing list. New snapshots of the support stuff also have been uploaded, including a new grub-ext2fs-floppy.gz (which doesn't any longer contain a confusing menu.lst file, and which is capable of loading gzip'd files and uncompressing them on the fly). I have changed the directory naming scheme in the tar files: They now all unpack into a directory called "l4", and not any longer "l4-<date>". This should make it easier to update only a part of the whole distribution in the future. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: l4-linux booted !
by Michael Hohmuth 06 Dec '98

06 Dec '98

roux(a)ecoledoc.lip6.fr (Cedric ROUX) writes: > Then, another time, the boot process blocks with this time the message : > ipc.cc:169 : failed assertion `! in_sender_list()' Attached below are some Fiasco patches which should help. This problem was a symptom of a familiar problem: Code which disables interrupts to protect a critical region trapped into a page fault which subsequently enabled interrupts again. We now protect against this problem by pre-installing all pages required for the operation in a safe way before the actual critical region starts. Ugly synchronization problems like this have been one of the main reasons to try to get rid of disabling interrupts altogether. However, the occasional "cli" instruction is still lurking in the code, waiting to be replaced with better mechanisms (like non-blocking synchronization). The patch also includes a fix which enhances compatibility with Jochen's L4 so that L4Linux can handle segmentation faults better. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: page size assertion
by Michael Hohmuth 04 Dec '98

04 Dec '98

> Eiji Ota <age(a)yk.fujitsu.co.jp> writes: > > > > > > I'm interested in this fantastic work(of course, L4). When I tried to > > > > > feel it, I faced an assertion failed by assert(size == PAGE_SIZE) in > > > > > space.cc(178 line). > > > > > > > > > > The wrong page size seemed to be passed by fpage_map in ipc_map.cc as > > > > > a SUPERPAGE_SIZE, but I don't find the root cause for this trouble. I wrote: > I think I have a theory on what the problem in Fiasco is (more on that > below). However, it would still be useful to know what the system is > trying to do when the error occurs; this would help me to reproduce > and track down the problem. > > My theory is that we fail to test rigorously enough that a receiver > really has enough space in its virtual address space to take a > superpage mapping. I think we currently test that just 4K are > unmapped in the receiver (that is, no mapping exists for the target > virtual address); that's not enough. Please try the patch appended below. I still would like to know which program triggers this problem as I have not been able to reproduce it. Regards, Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

l4-linux booted !
by roux＠ecoledoc.lip6.fr 03 Dec '98

03 Dec '98

Hello FIASCO people, well, strange things happened. I used the same grub floppy than the one used for my first experiments (that both crashed), and it booted ! really strange... I tried to run X, it didn't work (my screen power off, surely because of bad values for the horizontal and vertical frequencies, but i am not sure. I'll keep on trying (especially basic modes, like standard vga, and so on). Then, in a next boot, i tried 'reboot' command and i receive a KDB: unexpected system call and all is blocked (i am still in single machine mode, the cables i need to be able to debug with my second machine are not here yet, and for Michael: no, my machines are not connected anywhere, so remote debug won't be possible). In another test, i tried 'shutdown -h 0', which worked. Didn't try 'reboot' again, will do it this afternoon. Then, another time, the boot process blocks with this time the message : ipc.cc:169 : failed assertion `! in_sender_list()' Another strange thing is that it too often check the hd, with a message i never had before : /dev/hda2 has gone too long without being checked, check forced. Really really strange. Now, little questions : with the rmgr configfile (that i finnaly understood, at first the "glinux" task was not used because rmgr matched it against the configfile, so i had to add a line "task", for it to match the good module), there is a field 'irq'. Isn't it possible to allow only l4-linux to use the mouse-irq, so we can have mouse ? For my future work, i absoulty need X to work and the mouse would be appreciated (but i can deal without it). Once again, by configuring things correctly in the rmgr configfile, wouldn't it be possible to run X ? seems that people (especially Michael) succeded in running X, how did you do !? sanx, Sed. PS : this is a repost, the first message doesn't seem to have arrived, does it ? (i'm sure all those lost mails are preparing something ugly...). Is your mail server running under fiasco ? :) Hope this one will come to destination... sanx to Michael for his kernel config.

1 0

Re: This is an absolute FIASCO !
by Michael Hohmuth 01 Dec '98

01 Dec '98

I wrote: > roux(a)ecoledoc.lip6.fr (Cedric ROUX) writes: > > > I have a second machine, so i could have tried the debugger, but > > some pieces are missing and i don't have a null-modem, but i'll > > try to solve that. > > It would be great if you could generate a backtrace or even a state > analysis for the thread whose stack space runs out. PS: I can also debug this via the Internet if your debug host is connected to it (and you would give me an account on it). Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: This is an absolute FIASCO !
by Michael Hohmuth 01 Dec '98

01 Dec '98

Hi Sed! roux(a)ecoledoc.lip6.fr (Cedric ROUX) writes: > linux boots, everything seems alright, then it loads the deamons, then > the keymap, then the login should be there, but it reboots. > That was the first try. > I tried it just after this boot. And i now have this : > It boots, then at a time (don't remember exactly when), it shows that : > thread.cc:304: failed assertion 't->kernel_sp==0 || reinterpret_cast<vm_offset_t>(t->kernel_op) > reinterpret_cast<vm_offset_t>(t)+sizeof(thread_t)+0x20' > then it's over, asking me to reboot or run the debugger. > > So my questions are : > - what does it mean ? This is a panic because a kernel invariant wasn't met. In this case, the kernel's thread switching code detected a stack overrun in the target thread. This may also have been the reason for the crash/reboot you've seen. Are you trying to run the X Window System at this point? If so, this is a know problem. You should boot into a runlevel which doesn't run X11 to try out Fiasco. > - is it a problem in my compiling of l4-linux ? (i disabled serial support) I don't think that your L4Linux server is at fault. > I have a second machine, so i could have tried the debugger, but some pieces > are missing and i don't have a null-modem, but i'll try to solve that. It would be great if you could generate a backtrace or even a state analysis for the thread whose stack space runs out. > Hope this is not an already known bug. No, it's not (unless you're running X11). > (if someone could send me his kernel configuration, you run make xconfig and > you save it and you send it to me, of course if it works !) My .config file is appended below. > (don't know if it had to be done, but it checked my hd, and during > this process i had a lot of 'wake_idle_if_needed : ipc failed') This message should be removed: It's just informational. (The reason it doesn't bug me as much as you is that I have redirected it to a second monitor (Hercules, using the "-hercules") option.) > PS : i have the idea to do a distributed memory managment for my > studies, do you think it's possible with fiasco ? Yes, I think it's possible, and I think this would be an interesting application for Fiasco. > and when you run under l4-linux, can you make process that directly > talk to fiasco ? Yes, that's both possible and easy to do. However, we would need to come up with some documentation, and it would help if long IPC messages were available (I'm in the process of implementing them right now) so that our local name server could be utilized. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

This is an absolute FIASCO !
by roux＠ecoledoc.lip6.fr 01 Dec '98

01 Dec '98

Hi FIASCO people, i was lost in the net, then i saw a little light up on my head... it was FIASCO ! so i decided to take a look at it (well, in fact, a friend of mine told me about it, but a little romance sounds nice, eh ?). So, first, the hello server works. Then, i tried the linux one. And nothing to do. I applied the two patches available. Here is what's going on : linux boots, everything seems alright, then it loads the deamons, then the keymap, then the login should be there, but it reboots. (don't know if it had to be done, but it checked my hd, and during this process i had a lot of 'wake_idle_if_needed : ipc failed') That was the first try. I tried it just after this boot. And i now have this : It boots, then at a time (don't remember exactly when), it shows that : thread.cc:304: failed assertion 't->kernel_sp==0 || reinterpret_cast<vm_offset_t>(t->kernel_op) > reinterpret_cast<vm_offset_t>(t)+sizeof(thread_t)+0x20' then it's over, asking me to reboot or run the debugger. So my questions are : - what does it mean ? - is it a problem in my compiling of l4-linux ? (i disabled serial support) (if someone could send me his kernel configuration, you run make xconfig and you save it and you send it to me, of course if it works !) I have a pentium 200 mmx 64MHz, a hd ide of 4Go with hda2 for linux and hda3 for swap (70Mo), there is a cd-rom (hdb). I have no scsi, if it can help. I have a second machine, so i could have tried the debugger, but some pieces are missing and i don't have a null-modem, but i'll try to solve that. Hope this is not an already known bug. I'll keep on trying, it was late yesterday, had no time to make more than two tests. PS : i have the idea to do a distributed memory managment for my studies, do you think it's possible with fiasco ? and when you run under l4-linux, can you make process that directly talk to fiasco ? Thank you, Sed.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers December 1998