l4-hackers

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

2 participants
2880 discussions

Re: L4-Linux 0.5.1 failed to boot...
by Michael Hohmuth 12 Dec '98

12 Dec '98

OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> writes: > I tried new snapshot, 0.5.1, but I couldn't boot it. After L4-Linux > bootstrap, it couldn't detect my NE2000-compatible card and it > couldn't accept input from keyboard. The "login: " prompt appeared, > but I could do nothing, because console and network didn't work. My > CPU is AMD K6, but I don't think it is the source. My system is based > on Slackware-3.5.0, and is it possible that it may influece L4-Linux? Did this work before? One thing which won't work is loading original Linux kernel modules into L4Linux. From Linux' perspective, L4Linux is a different architecture, and modules have to be recompiled for L4Linux. Did you try loading the NE2000 driver as an original Linux kernel module? In this case, I recommend you compile the driver into your L4Linux kernel (or as an L4Linux module). Michael PS: Next week I'll be on vacation, and I won't answer my email. I'll try to catch up afterwards, so please keep sending in bug reports. They're appreciated a lot! -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

Re: some bugs
by Michael Hohmuth 11 Dec '98

11 Dec '98

Sed, thanks for your report! I'll to reproduce the problem when I return from my vacation in ten days. roux(a)ecoledoc.lip6.fr (Cedric ROUX) writes: [...] > When i run it under fiasco, it runs a little, then it blocks, so i press > ctrl+c, that nornmally should end up the program and give me back the > shell, but not, it just continues a little more, and stops again, and so on > until the end of the program. > Then i see a lot of "Aiee: scheduling in interrupt 00422ba (activ 10000)" > with sometimes a 0 in place of the 10000. This looks like a scheduling problem in Fiasco: An interrupt thread is still active while the Linux scheduling code is run. This should not happen because interrupt threads have a higher priority and never block. Interesting. [...] > Third, but it was before patch3, > i ran through my hd, making ls, cat, rm and so on, and at one time, > after a ls, and before the result being displayed, i receive this message > "page fault in signal handler". Maybe patch3 fixes that, huh ? Maybe yes, but I'm not sure. > And last, i normally have shift+page-up to see last lines, but it does > not works under fiasco (maybe kernel 2.0.21 doesn't handle it anyway). > Little problem, but problem. This doesn't work because hardware scrolling is disabled in L4Linux. We did this because L4Linux shares the console's video memory with Fiasco/L4 and potentially other L4 tasks. > I soon gonna be able to debug with a second machine, so my next reports > will be better. That's cool! Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

some bugs
by roux＠ecoledoc.lip6.fr 11 Dec '98

11 Dec '98

Hello FIASCO people, here are some more bugs (yes, it is possible :)). First of all, when you press shift+print-screen (or control+print-screen, don't remember what bugs), everything blocks with a message that i forgot to write or that i've lost (i am in exams, my brain becomes a little strange, i forget things). If one could tried it to see if it happens on others machines. Note: it was before i applied path3 and patch4, so maybe it solves the problem. It might be a sigfault in a cli section, but nothing is sure. Second, i could run koules with svgalib !! but, a program of mine don't work. If someone could try it to see if it's my machine or what ? available at : http://www.ecoledoc.lip6.fr/~roux/demo/lost.tar.gz and a binary is provided at : http://www.ecoledoc.lip6.fr/~roux/demo/lost If you could try it with a clean linux to see what should be the correct behavior, then try it with fiasco. It's just a poor animation with some sound (maybe sound is necessary for it to behave bad, don't know). When i run it under fiasco, it runs a little, then it blocks, so i press ctrl+c, that nornmally should end up the program and give me back the shell, but not, it just continues a little more, and stops again, and so on until the end of the program. Then i see a lot of "Aiee: scheduling in interrupt 00422ba (activ 10000)" with sometimes a 0 in place of the 10000. This works too with patch3, i don't have put patch4, but don't think it is relevent. And when i press Esc, it simply reboots. Third, but it was before patch3, i ran through my hd, making ls, cat, rm and so on, and at one time, after a ls, and before the result being displayed, i receive this message "page fault in signal handler". Maybe patch3 fixes that, huh ? And last, i normally have shift+page-up to see last lines, but it does not works under fiasco (maybe kernel 2.0.21 doesn't handle it anyway). Little problem, but problem. I soon gonna be able to debug with a second machine, so my next reports will be better. See you, Sed.

1 0

L4-Linux 0.5.1 failed to boot...
by OKUJI Yoshinori 11 Dec '98

11 Dec '98

Hello. I tried new snapshot, 0.5.1, but I couldn't boot it. After L4-Linux bootstrap, it couldn't detect my NE2000-compatible card and it couldn't accept input from keyboard. The "login: " prompt appeared, but I could do nothing, because console and network didn't work. My CPU is AMD K6, but I don't think it is the source. My system is based on Slackware-3.5.0, and is it possible that it may influece L4-Linux? Thanks, OKUJI ---------------------------------------------------------------------- ~o o~ OKUJI Yoshinori <okuji(a)kuicr.kyoto-u.ac.jp> s ) http://duff.kuicr.kyoto-u.ac.jp/~okuji (check "okuji.asc" !)

1 0

Re: l4-linux booted ! [patch3]
by Michael Hohmuth 10 Dec '98

10 Dec '98

Harald Fritzsche <Harald.Fritzsche(a)mpd.de> writes: > i have tried the patch also. Thanks for trying it! > It seems, that l4linux-2.0.21 is more stable than before. > Also the module package seems to work (dummy.o ne.o and related). That means > in my case that these modules are autoloaded (ping works). But i haven´t a > real network. > > Occasianally the system does not reached the login, unfortunatly i have no > copy of the given message (probably rcv fault, during /sbin/init). If you get a message, it would be interesting to know what it says exactly. > Other times the reboot command causes a seg fault (null pointer > derefenrence) after the message "Send all processes kill sig" (This is > reported earlier). I haven't ever seen this. Do you get a register/stack dump from L4Linux? In this case it should be possible to find the location of the page fault (with System.map and disassembly output ("objdump -ld vmlinux")). Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

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

Re: L4/Linux problem
by Michael Hohmuth 30 Nov '98

30 Nov '98

"Sun-Mi You" <smyou(a)postech.ac.kr> writes: > I've change Makefile and Linux was compiled sucessfully. > But, the problem still occurs at same point. > > Is there other suggestion? Hmm... Are you sure you re-built the emulib? If in doubt, please "make clean" and rebuild the whole kernel. Changing the Makefile and just doing a "make" in the top-level directory is not enough because the Makefiles are probably not included in the object dependencies. Sorry for being so overly accurate with this; I just want to make sure it's not that known problem. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: page size assertion
by Michael Hohmuth 30 Nov '98

30 Nov '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. > > Hi, after I changed the 113-line in ipc_map.cc to the following, it > worked, though I don't know whether it was correct or not. > > if (size > snd_size // want to send less that a superpage? > | > V > if (size >= snd_size // want to send less that a superpage? This is not the correct fix, I'm afraid. What you do here is to effectively prohibiting the passing of superpage (4-MByte) mappings. 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. I will try to verify this theory when I'm in the office later today. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: page size assertion
by Eiji Ota 30 Nov '98

30 Nov '98

> > > 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. Hi, after I changed the 113-line in ipc_map.cc to the following, it worked, though I don't know whether it was correct or not. if (size > snd_size // want to send less that a superpage? | V if (size >= snd_size // want to send less that a superpage? - Eiji

1 0

Re: L4/Linux problem
by Sun-Mi You 30 Nov '98

30 Nov '98

: :I think this is a problem one other user also experienced: The system :call IPC library (called ``emulation library'' for hysterical reasons) :in linux/arch/l4-i386/emulib/ has been linked to a wrong virtual :address because the magic in this directory's Makefile failed. One :possible reason is that you don't have a `cpp' in your $PATH. : :Does it help to replace "cpp" with "gcc -E" in this Makefile? : :Michael :-- I've change Makefile and Linux was compiled sucessfully. But, the problem still occurs at same point. Is there other suggestion?

1 0

ADV: LIVE Adult Paradise -- FREE !!
by Steve 29 Nov '98

29 Nov '98

------------------------------------------------------------- This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you by emailing mailto:sgarner@tophosting.com Please type "Remove" in the subject line. Your request to be remove will be processed within 24 hours. Please DO NOT reply to this email if you wish to be removed. ------------------------------------------------------------- FREE Adult Offer -- Five FREE Minutes -- All LIVE NEED A LITTLE SPICE IN YOUR LIFE? All Your Desires Are Satisfied -- The Best LIVE CyberNet Models Do As You Please! ALL LIVE -- ALL DAY -- ALL NIGHT Seductive Women: http://204.248.170.151/196/index.html HardBody Hunks: http://204.248.170.151/215/index.html ** LIVE 1-on-1 Shows! ** MALE or FEMALE! ** 5 FREE MINUTES of HOT ADULT LIVE ACTION! ** SATISFACTION GUARANTEED! All our shows are 100% LIVE and INTERACTIVE for your enjoyment! Ask And You Shall Receive SEDUTIVE WOMEN That Do It ALL! http://204.248.170.151/196/index.html -- OR -- HARDBODY HUNKS Give You What You Ask! http://204.248.170.151/215/index.html <a href="http://204.248.170.151/196/index.html">AOL Users Click Here!</a> See for yourself - We'll give you 5 FREE Steamy Minutes -- Satisfaction Guaranteed!

1 0

Re: page size assertion
by Eiji Ota 28 Nov '98

28 Nov '98

> > 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. > > > > Any ideas ? > > If you can attach a remote GDB via a serial line, you can generate a > backtrace. I'm not familiar with this analysis, anyway, I'll try this, however, I'm happy if you tell me how-to at this point if possible. > This might be a bug either in Fiasco or in an application (in which > case the code in v_insert() must be made more robust; that is, it must > return an error instead of panicking the kernel). > > What are you doing when the assertion fails? Booting? Starting X11? It was booting. I'll dig this out later as far as I can. - Eiji

1 0

Re: page size assertion
by Michael Hohmuth 28 Nov '98

28 Nov '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. > > Any ideas ? If you can attach a remote GDB via a serial line, you can generate a backtrace. This might be a bug either in Fiasco or in an application (in which case the code in v_insert() must be made more robust; that is, it must return an error instead of panicking the kernel). What are you doing when the assertion fails? Booting? Starting X11? Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

page size assertion
by Eiji Ota 27 Nov '98

27 Nov '98

Hi all, 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. Any ideas ? - Eiji Ota

1 0

Re: L4-Linux
by Michael Hohmuth 27 Nov '98

27 Nov '98

Harald Fritzsche <harald.fritzsche(a)mpd.de> writes: > i have applied Michaels patch and fortunatly the message > <KERNEL: no page fault handler ...> > does never occur. > > L4Linux boots now. > > Thanks so far and congratulation for such a system (Linux on Fiasco). Congratulations for getting it running, and thanks for going through all the hassles! > startx or something else (xdm,kdm,X,...) scrambles the screen and blocks the > keyboard. I assume that this is causes by the disabled serial interface and > related IRQ's (i have configured out serial interface)? It might as well be a bug in Fiasco. So far, we also haven't been very successful in getting up X11 (I think I've seen it running once or twice, but it must have been a lucky day). Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: L4/Linux problem
by Michael Hohmuth 27 Nov '98

27 Nov '98

"Sun-Mi You" <smyou(a)postech.ac.kr> writes: > Our L4/Linux was hanged at follow code. > > in 'linux/arch/l4-i386/chead.c ' > > /* create idt */ > { > extern long idt_table; > struct entry_t {unsigned short w0, w1,w2,w3;} ; > struct entry_t *entries = > (struct entry_t *)((unsigned long)emu_lib_text + > ((unsigned long)&idt_table - EMULIB_CODE_ADDRESS)); > unsigned short int tmp; > int i; > > => this point! > > for (i=0; i<20; i++, entries++) > { > tmp = entries->w1; > entries->w1 = entries->w3; > entries->w3 = tmp; > } > > What problem is this? > > ( I think it may be some memory problem. ) I think this is a problem one other user also experienced: The system call IPC library (called ``emulation library'' for hysterical reasons) in linux/arch/l4-i386/emulib/ has been linked to a wrong virtual address because the magic in this directory's Makefile failed. One possible reason is that you don't have a `cpp' in your $PATH. Does it help to replace "cpp" with "gcc -E" in this Makefile? Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

L4/Linux problem
by Sun-Mi You 25 Nov '98

25 Nov '98

Our L4/Linux was hanged at follow code. in 'linux/arch/l4-i386/chead.c ' /* create idt */ { extern long idt_table; struct entry_t {unsigned short w0, w1,w2,w3;} ; struct entry_t *entries = (struct entry_t *)((unsigned long)emu_lib_text + ((unsigned long)&idt_table - EMULIB_CODE_ADDRESS)); unsigned short int tmp; int i; => this point! for (i=0; i<20; i++, entries++) { tmp = entries->w1; entries->w1 = entries->w3; entries->w3 = tmp; } What problem is this? ( I think it may be some memory problem. ) Additionaly, our test platform is pentium/64Mb memory. Thanks in advance. :) ---------------------------------------------------------- Sun-Mi You (smyou(a)postech.ac.kr) System Software Laboratory Dept. of Computer Science and Engineering POSTECH, Pohang, KOREA Phone: +82-562-279-5668 http://sslab.postech.ac.kr/~woodstok ----------------------------------------------------------

1 0

Re: L4-Linux
by Michael Hohmuth 25 Nov '98

25 Nov '98

Harald Fritzsche <Harald.Fritzsche(a)mpd.de> writes: > I found (i hope so) the reason for the kbd: sig_sched: invalid > ext_preempter in > L4-Linux, reported earlier. > > In file : > linux/arch/l4-i386/lib/task.c > in function: > start_linux_server_thread() > is used the variable > l4_threadid_t foo_id > uninitialized. > I set foo_id to L4_INVALID_ID and the sig_sched disappears. But i don't > if this is intended from the authors. Your fix is correct. The problem occurred because I forgot to commit some patches before taking the snapshot. I've appended the patches (which include your fix) below. [ from a different message: ] > The function rs_init() hangs during boot (the boot stops for ever). Or a > function after this part of initialization. The last what i see is: > tty0* ... is a 16550A. > > If i disable the serial interface the boot goes on up to VFS mount and stops > than. This might be because the kernel debugger stub grabs irq 3 (the interrupt for COM2). Maybe Linux' serial driver waits for an interrupt that never arrives because L4Linux cannot attach to irq3. Configuring out the serial driver is the correct solution when using a remote Gdb attached via a serial line. If you don't have a remote Gdb, try booting with the "-nokdb" kernel option and see if the problem goes away. Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

2 1

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