l4-hackers

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

2827 discussions

Re: Compiling Fiasco (PR#39)
by Michael Hohmuth 31 Aug '99

31 Aug '99

(I've put your bug report into our bugs database so that I won't forget about it.) David Waite <mass(a)ufl.edu> writes: > I have been having problems compiling Fiasco from the CVS drop I got about > four days ago. The OSKit seems to be having problems with both the 'depend' > files (they are actually getting some ELF binary tacked on to the end, > although I haven't investigated why yet). Also, the gcc v2.95 has a problem > with the assembly (reports invalid register use in the what looked to be > linux scsi controller drivers) This seems to be a new problem triggered by the use of Gcc 2.95. I currently cannot reproduce it (I'm still using older compiler versions). > I tried to upgrade to the newest OSKit I could find, but that didn't work > out either, because of some header files that were there before, and that > aren't now. (Is there some Fiasco files tacked on to the OSKit? I didn't > really think about that until now) We made a few bug fixes to the version of the OSKit we distribute, but we didn't add a lot of files. The main problem is that the OSKit's interface has changed a lot between releases -- all include files, for example, moved from <flux/foo.h> to <oskit/foo.h>, and all type names changed to names beginning with "oskit_" --, and some of the semantics also changed. Porting Fiasco to the new OSKit is easy enough (I once did this; the patch is somewhere in the l4-hackers archive), but because we in Dresden as a group haven't changed to the new OSKit yet, Fiasco hasn't, either. Possible solutions would be to fix the old OSKit to compile with Gcc 2.95, or maybe to implement some header files which emulate the old OSKit's interface on top of the new one. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

RE: Compiling Fiasco
by David Waite 28 Aug '99

28 Aug '99

I have been having problems compiling Fiasco from the CVS drop I got about four days ago. The OSKit seems to be having problems with both the 'depend' files (they are actually getting some ELF binary tacked on to the end, although I haven't investigated why yet). Also, the gcc v2.95 has a problem with the assembly (reports invalid register use in the what looked to be linux scsi controller drivers) I tried to upgrade to the newest OSKit I could find, but that didn't work out either, because of some header files that were there before, and that aren't now. (Is there some Fiasco files tacked on to the OSKit? I didn't really think about that until now) -David Waite

1 0

MIPS
by Gottfried F. Zojer 28 Aug '99

28 Aug '99

Hi, I m sending this posting to find out how many are using Fiasco/L4 on Mips-Processors. And I hope that there is coming in some response. Sincerely Gottfried F. Zojer

2 1

Re: NT like OS's
by Tom Linden 27 Aug '99

27 Aug '99

Are you sure you want to do this? What about all the dll's? I think it advisable to set down goals and functioanl specs before embarking on such an adventure. I also think that you should look at all the opportunities including L4-Linux from Dresden. <l3-hackers(a)os.inf.tu-dresden.de> I also have a mature, fault-tolerant operating system, originally written for IBM mainframe, which is quite portable. Hadn't planned on porting it to alpha, but it is a possibility, particularly since later alphas understand Big Endian. On Fri, 27 Aug 1999, Peter Lizon wrote: > Date: Fri, 27 Aug 1999 12:58:34 -0400 > From: Peter Lizon <peter(a)alphant.com> > To: AlphaNT Mail List <AlphaNT(a)AlphaNT.com> > Subject: Re: NT like OS's > > Yeah - this is what I was looking for, not OpenNT . . . Now can we port this > to Alpha please? Preferably by the end of the year ;) > > Peter Lizon > ----- Original Message ----- > From: Michael Rich <istan(a)alltel.net> > To: <alphant(a)alphant.com> > Sent: Friday, August 27, 1999 12:38 PM > Subject: NT like OS's > > > > I know its off the wall, but there is at least one project thats currently > > working towards an NT compatible system. Currently its only x86 > > unfortuantly, but its open source, so anyone could start work on a > different > > processor. > > > > http://www.reactos.com > > > > Michael Rich > > http://alphax86dev.cjb.net > > > > __________________________________________________ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ /_/ /_/ /_/ Tom Linden PL/I Support /_/ /_/ Kednos Corporation OpenVMS and /_/ /_/ tel 650 566 9484 Tru64 Unix /_/ /_/_____________________________________________/_/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0

Re: L4-Linux on 486
by Michael Hohmuth 27 Aug '99

27 Aug '99

I wrote: > edmundo(a)rano.demon.co.uk writes: > > > (1) The Fiasco assertion about stack space (thread.cc:316) has failed > > several times. > > I can reproduce this: Under heavy interrupt load, a thread's kernel > stack can overflow on slow machines. I'm still thinking about what > the best way is to correct the problem. I think I found a solution to this problem. I've checked it in. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: L4-Linux on 486
by Michael Hohmuth 26 Aug '99

26 Aug '99

edmundo(a)rano.demon.co.uk writes: > (1) The Fiasco assertion about stack space (thread.cc:316) has failed > several times. I can reproduce this: Under heavy interrupt load, a thread's kernel stack can overflow on slow machines. I'm still thinking about what the best way is to correct the problem. > (2) Frequently cc1 segfaults when compiling a large file. Annoyingly, > it hasn't done it since I built one with debugging symbols. Maybe this is a symptom of an undetected kernel-stack overflow: When the kernel accidentally touches user memory, this can lead to page-fault messages being sent to the thread's pager and the thread being killed. > (3) The following C code causes massive strafing[1] of the disc which > I can terminate only by rebooting as the process seems to ignore all > signals. > > { > unsigned char a[4096*1024]; > int i; > unsigned char c; > > for (c = 0; ; c++) { > for (i = 0; i < sizeof(a); i += 4096) > a[i] = c; > } > } > > On one occasion cc1 gave the same behaviour. > > Can anyone tell me if this behaviour is a bug? It might just be a > "limitation" of L4-Linux, in which I'm in trouble, because it's the > only nasty behaviour which I can reproduce in a simple way. > > I only have 8 MB of memory, by the way, so the code above is expected > to exercise the disc. I just don't expect it to be unkillable. A > program that mallocs lots of 4000-byte blocks doesn't become > unkillable in the same way. I'd say the unkillable process is a bug, but the disk thrashing is to be expected on a low-memory machine. I'll try reproducing this later -- I'll tackle the stack-overflow problem first. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: Porting Hurd to l4
by Michael Hohmuth 25 Aug '99

25 Aug '99

Matthew Vernon <matthew(a)debian.org> writes: > Is the l4 server interface descripted somewhere (as in, I need a > little more help getting started than just RTFsource :) )? I guess you mean the L4-kernel interface to be used by servers, don't you? This interface is documented in manpages at <URL:http://os.inf.tu-dresden.de/L4/l4man.html> (this is for Fiasco and L4/x86; the L4/MIPS website has manpages for the MIPS version). The L4 Reference Manual is the defining document for the L4 API (and x86 ABI); it's available at <URL:http://os.inf.tu-dresden.de/L4/l4refx86.ps.gz>. > I'm beginning to think the effort involved in porting the HURD > servers to Mach may be worthwhile in the long run. ^^^^ L4? If the Hurd wouldn't be too Mach-dependent, and would instead use a microkernel-independent object model (like "MOM", a framework Bryan Form from Utah was thinking about at one point), it should be possible to port it to L4. In fact, if you look closely, there is even some (unused and orphaned) early support for MOM in the Hurd source tree (in the libmom directory). Then, all you would need for a port to L4 would be an object framework (something like a server supporting a slim version of Mach ports) and a set of device drivers. Personally, I'd love to see a Hurd port to L4. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Porting Hurd to l4
by Matthew Vernon 24 Aug '99

24 Aug '99

Hi, Is the l4 server interface descripted somewhere (as in, I need a little more help getting started than just RTFsource :) )? I'm beginning to think the effort involved in porting the HURD servers to Mach may be worthwhile in the long run. ObHurd - what do any Hurd people here think? Matthew

4 3

L4-Linux on 486
by edmundo＠rano.demon.co.uk 23 Aug '99

23 Aug '99

Michael's patch from 1999-08-18 seems to have solved the IRQ problem I was suffering from previously. I can now do lots of heavy NFS with no problems at all. But I now have different problems, of course ... Unfortunately the latest symptoms are very vague and various. I've had spontaneous reboots, I've had the machine just stop, uninterruptible by GDB, I've had various assertions fail in Fiasco, I've had an assertion fail in Linux ("reply_and_wait error", l4_idle.S:564). Some of the failed assertions in Fiasco seem inexplicable except by something scribbling on memory as they involve bits of the scheduling code which seem simple enough not to fail only in rare circumstances. Most of the fatal events are not repeatable and have only happened to me once, but there are three things that I have seen several times: (1) The Fiasco assertion about stack space (thread.cc:316) has failed several times. (2) Frequently cc1 segfaults when compiling a large file. Annoyingly, it hasn't done it since I built one with debugging symbols. (3) The following C code causes massive strafing[1] of the disc which I can terminate only by rebooting as the process seems to ignore all signals. { unsigned char a[4096*1024]; int i; unsigned char c; for (c = 0; ; c++) { for (i = 0; i < sizeof(a); i += 4096) a[i] = c; } } On one occasion cc1 gave the same behaviour. Can anyone tell me if this behaviour is a bug? It might just be a "limitation" of L4-Linux, in which I'm in trouble, because it's the only nasty behaviour which I can reproduce in a simple way. I only have 8 MB of memory, by the way, so the code above is expected to exercise the disc. I just don't expect it to be unkillable. A program that mallocs lots of 4000-byte blocks doesn't become unkillable in the same way. Edmund [1] My trusty old 100 MB disc does sound a bit like a machine gun when there is a lot of swapping going on.

1 0

Re: L4-Linux worked on 486!
by Michael Hohmuth 18 Aug '99

18 Aug '99

Edmund, good news: I think I have found the problem! edmundo(a)rano.demon.co.uk writes: > I've investigated the ready queue after hitting "irq still active" by > doing "p (class thread_t*)0xc0000000" and "p $.ready_next" repeatedly. > In each case the threads corresponding to irqs 5 and 14 seemed to be > ready. In one case, so was the thread corresponding to irq 0. > > Just to confirm: irq 5 = 0xc014a800, irq 14 = 0xc014f000 > > I think I'm dealing with irq 5 when the error occurs because the value > 0x20 is in eax and ebx. Yep. > So presumably I should investigate the kernel stack for irq thread 14, > which was apparently preempted in some mysterious fashion by an > interrupt thread of lower priority. I see there's a kernel_sp in > thread_t. [...] I had a very similar situation, and from looking at the stack of the preempted higher-priority thread, it could tell that the higher-priority thread was voluntarily switching to the lower-priority thread by calling schedule(). However, schedule() should not have switched to the lower-priority thread if the higher-priority thread was runnable... Anyway, a close look at the scheduler revealed a race condition where a high-priority thread could become runnable after it has decided to switch to a lower-priority one. I think I have eliminated that race now. Please try the latest version of thread.cc from CVS (>= 1.51). Thanks again for testing! Michael (Taking a mental note not to throw away my good old 486 so soon because slow machines reveal much more races...) -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Jump to page:

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