l4-hackers

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

2 participants
2880 discussions

Re: L4-Linux worked on 486!
by Jean Wolter 03 Aug '99

03 Aug '99

edmundo(a)rano.demon.co.uk writes: > > > >It dies after saying "irq still active". > > >(To get that message I'm using the patch that Michael Hohmuth > > > posted to the list on July 25.) > > > I think I may have found a bug in the SANITY code in > > > linux22/arch/l4-i386/kernel/irq.c, by the way. See below. > > > > I remember, I've ever seen same message & following crash, > > thanks for the patch. > > Unfortunately I still don't understand why the irq is "still active". The problem is the following: Normally the pic only forwards one interrupt to the CPU and signals the next one after the current interrupt has been acknowledged. L4 uses a special PIC mode ("special fully nested mode" or something similar), that allows the pic to signal more than one interrupt to the CPU. It uses priorities to decide whether a newly arrived interrupt should be forwarded to the CPU. So it is possible that more than one interrupt is delivered to the CPU before the interrupt handler was able to acknowledge its own interrupt. If we use "unspecific end of interrupt" to acknowledge the interrupt we acknowledge the one with the highest priority. > > Here's the corresponding bit of code in irq.c. (The lines which aren't > indented as much as they should be came from Michael's debugging > patch.) > > > mask = 1 << (irq & 7); > if (irq < 8) > { > outb(inb(0x21) | mask, 0x21); /* block the irq */ > outb(0x20, 0x20); /* acknowledge the irq */ We use unspecific end of interrupt to acknowledge the irq. > > outb(0x0B, 0x20); > if (inb(0x20) & mask) > enter_kdebug("irq still active"); Now we read the "in service register" of the pic and find out that our interrupt is still active. Due to fiasco being preemptive and a wrong priority assignment to our interrupt threads it happened that a thread with a higher L4 priority which handled an irq with a lower pic priority accidently acknowledged the wrong interrupt. > If you look at the bottom of kernel/fiasco/src/irq.h you'll find an > unused function irq_ack() which does roughly the same thing, because > acknowleding the IRQ is something that ought to be done by L4/Fiasco, > but is at present done by Linux. > > So why do we get "irq still active" during heavy use of the network > card? Is there a PIC expert in the house? I hope the explanation above was clear enough :) > > Is it possible that the problem is caused by the interrupt not being > acknowledged quickly enough? If so, maybe I should move the ack from > Linux into Fiasco ... There was a long discussion about that and it looks like irq acknowledge will move to the micro kernel. Jean -- I get up each morning, gather my wits. Pick up the paper, read the obits. if I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. Peete Seeger

2 1

Re: any documents for remote debug newbies?
by Michael Hohmuth 23 Jul '99

23 Jul '99

suzukis(a)file.phys.tohoku.ac.jp writes: > I was reading the manpage of L4 (telling "-comspeed" as the option > for rmgr) and not of Fiasco (telling it as for main). I was wondering > why rmgr does not understand options like "-comspeed", "-comport". I think the Rmgr manual tells you to apply the "-comspeed" option to the L4 kernel binary (grubboot.img, or, in our case, main) -- at least, that's what it should tell you. It probably need to be made less confusing. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: recent GAS and l4/kernel/fiasco/src/entry.S
by Michael Hohmuth 23 Jul '99

23 Jul '99

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > From: suzukis(a)file.phys.tohoku.ac.jp > > If I change the register name from "%dl" to "%edx" in the entry.S > > (leaving the opcode "bt" as it is), the recent GAS could assemble it. > > Anybody found such behaviour? My GAS is broken? > > The code "bt $2, %dl" is invalid. The bit test call only accepts > 16bits and 32bits registers, so that should be "btw $2, %dx" or "btl > %2, %edx". Thanks; I've fixed this in the CVS version now. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: any documents for remote debug newbies?
by Michael Hohmuth 22 Jul '99

22 Jul '99

suzukis(a)file.phys.tohoku.ac.jp writes: > As Edmund reported previously, also I found that L4-Linux (2.0.21) > could boot but not work well on my 486 PC (of course, I added > -nopentium option for rmgr). However, same kit (fiasco/rmgr/sigma0 > /glinux) works well on Pentium PC. I fixed some fatal 486-related bugs last night (alas, I didn't have an 486 to test with earlier). L4Linux 2.2 can now boot multi-user on Fiasco on my 486. This version currently is only available from remote CVS. I hope to get to making some new snapshots soon, as L4Linux 2.2 now is quite stable on Fiasco. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

3 2

Re: any documents for remote debug newbies?
by suzukis＠file.phys.tohoku.ac.jp 21 Jul '99

21 Jul '99

Michael points out: >>Just I've tried by adding "-comspeed 9600" option to rmgr, also > ^^^^ >"-comspeed 9600" is not an Rmgr option but an option for the Fiasco >kernel, like this: (slightly edited from my menu.lst) I see! Adding the option to the Fiasco kernel, GDB successfully connects to the target PC. Sooner I will check the revised Fiasco. I was reading the manpage of L4 (telling "-comspeed" as the option for rmgr) and not of Fiasco (telling it as for main). I was wondering why rmgr does not understand options like "-comspeed", "-comport".

1 0

any documents for remote debug newbies?
by suzukis＠file.phys.tohoku.ac.jp 20 Jul '99

20 Jul '99

Hello. As Edmund reported previously, also I found that L4-Linux (2.0.21) could boot but not work well on my 486 PC (of course, I added -nopentium option for rmgr). However, same kit (fiasco/rmgr/sigma0 /glinux) works well on Pentium PC. I'm trying remote debugging, but yet I couldn't connect gdb and fiasco-system. I removed "-nokdb" option for main (fiasco kernel) module, thus fiasco-system on target 486 PC enters remote debugging mode, and waits for gdb instructions via serial cable, like this. ------------------------------------------------------- on target PC console ------------------------------------------------------- RMGR: loading (fd0)/sigma0 RMGR: detected new-style DD-L4 RMGR: starting (fd0)/main proto=0x10136c Welcome to Fiasco! DD-L4/x86 microkernel (c) 1998 TU Dresden - May 17 1999 KDB: init ------------------------------------------------------- Then I started gdb on host PC (Debian 2.1 on Pentium PC - gdb is from binary package). Though it seems that some packets sent & received via serial cable, but gdb could not complete the connection. gdb says, ------------------------------------------------------- on host PC ------------------------------------------------------- % cat .gdbinit file kernel.image set remotedebug 1 set remotebaud 115200 #set remotebaud 9600 target remote /dev/ttyS0 % gdb kernel.image GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-pc-linux-gnu"... Sending packet: $Hc-1#09...putpkt: Junk: WJW B% Sending packet: $Hc-1#09...putpkt: Junk: W B% Sending packet: $Hc-1#09...putpkt: Junk: W B% Sending packet: $Hc-1#09...putpkt: Junk: W B% Timed out. Timed out. Timed out. Ignoring packet error, continuing... Sending packet: $qOffsets#4b...putpkt: Junk: W B% Sending packet: $qOffsets#4b...putpkt: Junk: W B% Sending packet: $qOffsets#4b...putpkt: Junk: W B]% Sending packet: $qOffsets#4b...putpkt: Junk: % Timed out. Timed out. Timed out. Couldn't establish connection to remote target Malformed response to offset query, timeout -------------------------------------------------------------------- Slowing the remotebaud to 9600, the result is just same. When I boot small Linux system on the target 486 PC, the baudrait returned by setserial command is 115200. ASCII messages redirected to /dev/ttyS1 on the target PC are well transfered to /dev/ttyS0 on the host PC, so I suppose there's no physical troubles (e.g. staled cable or port), and I ought to have forgotten some points to configure. I'm not enough-skilled to find my wrong points. There's any useful documents to excersize remote debugging? I want some sample program... the document in GDB is difficult for me, because I must add several functions to generic (and incomplete) i386-stub.c, before excersize remote debugging. suzuki

2 2

Re: Booting fiasco kernel on cyrix
by Michael Hohmuth 20 Jul '99

20 Jul '99

Kazuto MIYOSHI <kaz(a)earth.email.ne.jp> writes: > I've been trying to boot fiasco kernel on my CYRIX MII machine > (I had believed that CYRIC has binary compatibility with Pentium.) > > Booting from floppy image downloaded, it says > > space.cc:193 failed assertion(size==PAGE_SIZE)... > > and I found out that 'size' is actually SUPERPAGE_SIZE. > > I suspect that there is a little bit differnce between CYRIX and > Pentium, with the ability to treat 4MB pages, and I tried to disable > superpage facility by changing cpu.feature_flags like this: > cpu.feature_flags &= ~(CPUF_PAGE_GLOBAL_EXT|CPUF_4MB_PAGES); > This modification successfully generates "HELLO" message on console, > but after printing it, the same assertion still fails. I'd be interested in a backtrace. Do you have a second machine available which you could use for remote debugging? (Implementing a back-trace facility for Jean's built-in low-level debugger (jdb) is also an option, but I'm not sure I can get to this during this week. Any takers?) > Does not fiasco run on CYRIX cpu at all (why?), or does anyone have > good idea to avoid this problem? Fiasco is supposed to run on the Cyrix CPU, but without a test machine it's difficult to say what exactly the problem is. I found and fixed a few 486-related bugs today, but I'm not sure they're related to your problems. You might want to try the latest version anyway (but currently it's available only via remote CVS). Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Booting fiasco kernel on cyrix
by Kazuto MIYOSHI 11 Jul '99

11 Jul '99

Hello. I've been trying to boot fiasco kernel on my CYRIX MII machine (I had believed that CYRIC has binary compatibility with Pentium.) Booting from floppy image downloaded, it says space.cc:193 failed assertion(size==PAGE_SIZE)... and I found out that 'size' is actually SUPERPAGE_SIZE. I suspect that there is a little bit differnce between CYRIX and Pentium, with the ability to treat 4MB pages, and I tried to disable superpage facility by changing cpu.feature_flags like this: // cpu info; need to do this before setting up page tables because // we need to know whether we can use 4MB pages. cpuid(&cpu); #if 1 cpu.feature_flags &= ~(CPUF_PAGE_GLOBAL_EXT|CPUF_4MB_PAGES); #endif // the first thing to set up is the page-level allocator so that we // can allocate page tables from it kmem::init(mbi_pa); This modification successfully generates "HELLO" message on console, but after printing it, the same assertion still fails. Does not fiasco run on CYRIX cpu at all (why?), or does anyone have good idea to avoid this problem? my environment: fiasco-l4-990428.tar.gz fiasco-l4-990428.patch-01 grub-l4-981207.tar.gz oskit-l4-990428.tar.gz grub-ext2fs-floppy

1 0

Re: none
by Michael Hohmuth 08 Jul '99

08 Jul '99

benben xiao <xiaoxiaoben(a)hotmail.com> writes: > I recently see the Fiasco resoure.I have a problem that I found > main.cc > 55 kernel_thread_t *kernel=new(&config::kernel_id); > call main.cc 80 kernel_thread_t::operator new(size_t,threadid_t id);. > I don't know how to transmit the parameter of type size_t. You don't -- the compiler generates it implicitly. There is a difference between the "new" operator and the "operator new" function. For more information please consult a good book on C++. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

Re: L4-Linux with l4-gmd
by Michael Hohmuth 08 Jul '99

08 Jul '99

edmundo(a)rano.demon.co.uk writes: > Since I'm unable to run L4-Linux with Fiasco on my 486 - I can boot > with init=/bin/sh but it reboots as soon as I do anything that > involves a fork - I thought I'd try L4-Linux with the old, non-free > L4. So I downloaded l4-gmd/486/obj/l4.exe [...] This ancient version doesn't work with L4Linux -- it's too buggy. :-( > But how do I make grubboot.img out of l4.exe, if this is what I'm > supposed to do? (The man page for rmgr says the modules should be ELF > files.) If you want to try it anyway: Copy l4.exe to l4/l4/kernel/l4-gmd/src, cd to l4/l4/kernel/l4-gmd and type "make". If all goes well, this should build a grubboot.img binary. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Jump to page:

2025

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