- l4-hackers - example.com Site

Re: Error compiling linux22
by Jean Wolter 08 Oct '99

08 Oct '99

Christian Stueble <stueble(a)amaunet.cs.uni-dortmund.de> writes: > > Hello, > > I tried to compile linux22 (8.10.99) and get the following error message: > > --------------- > gcc -D__KERNEL__ -I/usr/home/stueble/DA/Data/sb/linux22/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -I/usr/home/stueble/DA/Data/sb/linux22/../l4/include -I/home/drops/include -DLINUX_ON_L4 -g -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o svc.o svc.c > gcc: Internal compiler error: program cc1 got fatal signal 11 [...] > Is this a compiler specific problem? This sounds either like a hardware problem (a kernel make is a good test for the memory subsystem) or a compiler problem. Does it happen every time you try to compile this particular file? Or do you get random segmentation faults (signal 11)? Jean -- Mr. Johnson has learned the first rule of not being seen. However, he has chosen a very obvious piece of covah! Kablooey!

1 0

Error compiling linux22
by Christian Stueble 08 Oct '99

08 Oct '99

Hello, I tried to compile linux22 (8.10.99) and get the following error message: --------------- gcc -D__KERNEL__ -I/usr/home/stueble/DA/Data/sb/linux22/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -I/usr/home/stueble/DA/Data/sb/linux22/../l4/include -I/home/drops/include -DLINUX_ON_L4 -g -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o svc.o svc.c gcc: Internal compiler error: program cc1 got fatal signal 11 make[3]: *** [svc.o] Error 1 make[3]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs/lockd' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs/lockd' make[1]: *** [_subdir_lockd] Error 2 make[1]: Leaving directory `/usr/home/stueble/DA/Data/sb/linux22/fs' make: *** [_dir_fs] Error 2 stueble@rum:/usr/home/stueble/DA/Data/sb/linux22 > cpp: output pipe has been closed {standard input}: Assembler messages: {standard input}:1398: Warning: end of file not at end of a line; newline inserted {standard input}:1745: Warning: .stabs: Missing comma ---------------- System: gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) GNU ld version 2.9.1 (with BFD 2.9.1.0.15) Pentium 133, SuSE 6.0 Is this a compiler specific problem? -Chris- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Re: Compiling Fiasco (PR#39)
by Michael Hohmuth 09 Sep '99

09 Sep '99

I wrote earlier: > 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). > [...] > 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. BTW, according to the OSKit website, the new OSKit currently cannot be compiled with Gcc 2.95 or Egcs 1.x either, but must be compiled with Gcc 2.7.3, so upgrading now wouldn't fix this particular problem. Michael -- hohmuth(a)innocent.com, hohmuth(a)sax.de http://www.sax.de/~hohmuth/

1 0

Re: GRUB network boot
by vhandel＠chem.vu.nl 02 Sep '99

02 Sep '99

>Are there instructions anywhere for how to do a network boot with >GRUB? I think there is code for it in Dresden's version of GRUB, but >not in GNU's GRUB, yet. I've just spent a few days integrating Dresden's netboot stuff into my heavily hacked version of GRUB, so I do have an idea how this works ;). The network device is called (nd). So your GRUB config could contain an entry like this: title= Netboot Linux root= (nd) kernel= /boot/vmlinuz [nfsroot options] or something similar :) Network boot works through TFTP/BOOTP. A linux HOWTO that helped me on the way is the Diskless mini-howto. You need to setup the bootp daemon on your server using a bootp configuration table, usually in /etc/bootptab. Read the diskless mini-howto and do man bootp to figure out how this works (do I need to post an example ?). Then, edit /etc/inetd.conf and uncomment the lines that look something like this: tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd bootps dgram udp wait root /usr/sbin/in.bootpd in.bootpd Pitfall: don't forget to give tftpd the directory in which your netboot files are as a parameter. You will still need to supply the complete path of that dir in GRUB (the howto's are a bit misleading, they talk about changing the root dir and stuff like that) but otherwise you would have to supply a relative path, which GRUB does not support. Now you should be ready to netboot ! PS, I have heard from people that sometimes the linux bootp daemon doesn't work. In that case you can try running the dhcp daemon with bootp support. PPS, I think there's another pitfall -- I haven't been keeping track of the development of Dresden's GRUB, but if it's similar to the version that I have at home them it's based on an old version of GRUB, which *does not compile correctly with the new gas* !!!!!! If you recompile it on an up-to-date system, GRUB'll crash on boot. So beware. This same problem occurs with the GRUB dist from uruk.org... GNU GRUB fixes this. >This one is even more off-topic, but I'll just mention it quickly: I >tried last night to install GRUB on an 8.4 GB disc. I know you always >used to have to make sure that stage2 is in the first 540 MB of the >disc, but I naively assumed that, since this was modern hardware and >the latest version of GRUB, and the BIOS was set to LBA mode, I would >be all right. But it didn't work (something like "Disc geometry >error"). Do the old restrictions still apply, then? Was it GNU GRUB ? The last time I tried GNU GRUB (a month ago or so) LBA mode didn't work for me... while I have a mere 520MB disk, for which the BIOS DOES support LBA !!!!! On some partitions I got all kinds of weird geo errors, on others I got corrupted partition information and stuff like that. I was going to try to debug it but never actually got around to it... Ramon

2 1

Re: Chief number in TID's
by Michael Hohmuth 02 Sep '99

02 Sep '99

Marcus, I think there is a misunderstanding here -- Adam's question was why is the number of the chief task a part of the thread-id data structure (l4_threadid_t). As it would be beneficial to move from 64-bit thread ids to 32-bit thread ids on 32-bit architectures like x86 and StrongARM, Adam is looking for ways to reduce the size of the thread-id data structure, and one way to do so would be to throw out the chief number. Personally, I don't think there is a real reason to keep the chief number in the thread id except for backward compatibility and for ease of porting L4 apps to a changed ABI. L4 has inherited this data structure from L3, and I would be interested in why the chief number ended up in the thread id in the first place. Jochen? Michael -- hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de http://home.pages.de/~hohmuth/

1 0

GRUB network boot
by Edmund GRIMLEY EVANS 02 Sep '99

02 Sep '99

Are there instructions anywhere for how to do a network boot with GRUB? I think there is code for it in Dresden's version of GRUB, but not in GNU's GRUB, yet. This one is even more off-topic, but I'll just mention it quickly: I tried last night to install GRUB on an 8.4 GB disc. I know you always used to have to make sure that stage2 is in the first 540 MB of the disc, but I naively assumed that, since this was modern hardware and the latest version of GRUB, and the BIOS was set to LBA mode, I would be all right. But it didn't work (something like "Disc geometry error"). Do the old restrictions still apply, then? Edmund

1 0

Chief number in TID's
by Adam 'WeirdArms' Wiggins 02 Sep '99

02 Sep '99

Does anyone have a 'good' reason for the chief number to be an a TID for the use of users (nothing to do with kernel internals and implimentation). Removing the chief from the TID allows 32bit TID's with a 'reasonable' number of tasks and threads per task. :) Cheers Adam

2 1

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