l4-hackers July 1999

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

6 participants
12 discussions

L4-Linux worked on 486!
by suzukis＠file.phys.tohoku.ac.jp 05 Aug '99

05 Aug '99

Hi, Just I could boot L4-Linux and execute "ls" etc on 486, without rebooting. At present, it seems that Fiasco must be recent version, but the version of L4-Linux does not matter. Both of the previous snapshot (L4-Linux 2.0.21) and the anonymous CVS version (linux22 which I checked out July/26) are working. I remember, after the announcement of linux22 availability via CVS, I experienced several 486 rebooting caused by "ls". So I will continue to search the critical point. After several trying of remote debug, I think "kernel"-debugger is not so much powerful to detect how L4-Linux "server" breaks down. It's not easy for me to understand what happens in the server program from the system calls. Therefore, now I'm looking for a remote-debug-stub for server program on Fiasco. The document of the OSKit tells that the debug-stub in the OSKit is easy to re-use for user-spaced programs, I will try. But there's any working debug-stub? suzuki P.S. By the way, wait_for_keypress() (linux22/drivers/char/tty_io.c) of the latest linux22 works well? It is called when mounting the root filesystem on floppy, or on ramdisk loaded via floppy, like: printk(KERN_NOTICE "VFS: Insert root floppy and press ENTER\n"); wait_for_keypress(); (from linux/fs/super.c). In my testing, the latest linux22 is killed when it calls wait_for_keypress(). But the previous snapshot of L4-Linux (2.0.21) safely passes wait_for_keypress(). The message from the debugger (when linux22 is killed) is like this: grub> kernel=(fd0)/rmgr -nopentium -configfile -sigma0 [Multiboot-elf, <0x100000:0x20320:0x0>,<0x121320:0x418:0x26dac>,entry=0x100000] grub> module=(fd0)/main -nokdb -nojdb [Multiboot-module @ 0x149000, 0x24200 bytes] grub> module=(fd0)/sigma0 [Multiboot-module @ 0x16e000, 0xcb26 bytes] grub> module=(fd0)/rmgr.cfg [Multiboot-module @ 0x17b000, 0x56d bytes] grub> module=(fd0)/glinux.gz init=/bin/sh root=/dev/fd1 [Multiboot-module @ 0x17c000, 0xe428 bytes] RMGR: loading task (fd0)/glinux.gz init=/bin/sh root=/dev/fd1 from 0x17c000-0x260238 to [ 0x3ff000-0x4b2170 0x4b4000-0x4fe034 ] RMGR: starting task (fd0)/glinux.gz init=/bin/sh root=/dev/fd1 from 0x17c000-0x260238 at entry 0x3ff000 via trampoline page code 0x26114c [...snip...] VFS: Insert root floppy and press ENTER Dump of trap_state at 0xc0141fb4: EAX 00000000 EBX 00000001 ECX 004e1646 EDX 00000001 ESI 00000000 EDI 00000000 EBP 00000000 ESP 00d05f5c EIP 00000003 EFLAGS 00013a92 CS 0023 SS 002b DS 002b FS 002b GS 002b trapno 6, error 00000000, from user mode

3 7

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

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 July 1999