Hi all,
I am having a problem with the new name_server from the l4vfs package.
I load it the name_server module with grub:
kernel (nd)/fiasco/rmgr -sigma0 task modname "L4Linux task" modaddr 0x02000000 module (nd)/fiasco/fiasco -nowait -nokdb -nofancy -serial -comspeed 115200 -comport 1 module (nd)/fiasco/sigma0 module (nd)/fiasco/names module (nd)/fiasco/log module (nd)/fiasco/dm_phys module (nd)/fiasco/l4io --noirq module (nd)/fiasco/tftp -i -s 192.168.1.4 module (nd)/fiasco/simple_ts module (nd)/fiasco/l4exec module (nd)/fiasco/l4dope --l4io module (nd)/fiasco/name_server module (nd)/fiasco/loader (nd)/fiasco/dope-l4linux.cfg vbeset 0x117
and it produces the following debug output:
name_ser| main(): 2 ... (0)/ file1 (56.1) test3 (5)/ c (8)/ b (7)/ a (6)/ test2 (4)/ test1 (3)/ server (2)/ linux (1)/ name_ser| main(): 3 ...
Q1: Where did the name_server get these names?
I wanted to test the name_server module so I ran "name_server_test" which always crashes with output:
tftp | Loading (nd)/fiasco/name_server_test [549kB] loader | "(nd)/fiasco/name_server_test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ exec | name_server_test: Loading exec | name_server_test: Has no dynamic info exec | name_server_test: Saved 20647 bytes of symbols exec | name_server_test: library "libloader.s.so" not found loader | name_server_test: Starting sigma0-style application exec | name_server_test: Packed 14374 bytes of symbols exec | name_server_test: Packed 69740 bytes of lines loader | name_server_test,#14: Entry at 00009c74 => 00980000 loader | name_server_test,#14: Started run | . n_s_test| main(): Results follow below (should be as predicted (123) == '123'). n_s_test| main(): Volume stuff: ******************* n_s_test| main(): Name server thread id (8.2) 'D.02' name_ser| l4vfs_basic_name_server_thread_for_volume_component(): Before: l4vfs_ name_ser: basic_name_server_thread_for_volume_component() name_ser| l4vfs_basic_name_server_thread_for_volume_component(): After: l4vfs_b name_ser: asic_name_server_thread_for_volume_component() n_s_test| main(): Volume server for NS volume (8.2) 'D.02' name_ser| l4vfs_basic_name_server_thread_for_volume_component(): Before: l4vfs_ name_ser: basic_name_server_thread_for_volume_component() name_ser| l4vfs_basic_name_server_thread_for_volume_component(): After: l4vfs_b name_ser: asic_name_server_thread_for_volume_component() n_s_test| main(): Volume server for other volume (0.0) '7FF.7F' name_ser| l4vfs_name_space_provider_register_volume_component(): register_volum name_ser: e: 5.0 name_ser| L4RM: [PF] read at 0x012ffd14, eip 012003f9, src D.02 name_ser| [D.0] l4rm/lib/src/pagefault.c:75:__unknown_pf(): name_ser| unhandled page fault
I seem to get a lot of Double PF when loading my own or test programs.
Any suggestions welcome! Thanks Leon
Hello,
On Tue, Sep 07, 2004 at 08:17:32AM +0200, Leon wrote:
Hi all,
I am having a problem with the new name_server from the l4vfs package.
I load it the name_server module with grub:
kernel (nd)/fiasco/rmgr -sigma0 task modname "L4Linux task" modaddr 0x02000000 module (nd)/fiasco/fiasco -nowait -nokdb -nofancy -serial -comspeed 115200 -comport 1 module (nd)/fiasco/sigma0 module (nd)/fiasco/names module (nd)/fiasco/log module (nd)/fiasco/dm_phys module (nd)/fiasco/l4io --noirq module (nd)/fiasco/tftp -i -s 192.168.1.4 module (nd)/fiasco/simple_ts module (nd)/fiasco/l4exec module (nd)/fiasco/l4dope --l4io module (nd)/fiasco/name_server module (nd)/fiasco/loader (nd)/fiasco/dope-l4linux.cfg vbeset 0x117
and it produces the following debug output:
name_ser| main(): 2 ... (0)/ file1 (56.1) test3 (5)/ c (8)/ b (7)/ a (6)/ test2 (4)/ test1 (3)/ server (2)/ linux (1)/ name_ser| main(): 3 ...
That looks okay for me.
Q1: Where did the name_server get these names?
It is the default debugging configuration. Never mind the names.
I wanted to test the name_server module so I ran "name_server_test" which always crashes with output:
tftp | Loading (nd)/fiasco/name_server_test [549kB] loader | "(nd)/fiasco/name_server_test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ exec | name_server_test: Loading exec | name_server_test: Has no dynamic info exec | name_server_test: Saved 20647 bytes of symbols exec | name_server_test: library "libloader.s.so" not found loader | name_server_test: Starting sigma0-style application exec | name_server_test: Packed 14374 bytes of symbols exec | name_server_test: Packed 69740 bytes of lines loader | name_server_test,#14: Entry at 00009c74 => 00980000 loader | name_server_test,#14: Started run | . n_s_test| main(): Results follow below (should be as predicted (123) == '123'). n_s_test| main(): Volume stuff: ******************* n_s_test| main(): Name server thread id (8.2) 'D.02' name_ser| l4vfs_basic_name_server_thread_for_volume_component(): Before: l4vfs_ name_ser: basic_name_server_thread_for_volume_component() name_ser| l4vfs_basic_name_server_thread_for_volume_component(): After: l4vfs_b name_ser: asic_name_server_thread_for_volume_component() n_s_test| main(): Volume server for NS volume (8.2) 'D.02' name_ser| l4vfs_basic_name_server_thread_for_volume_component(): Before: l4vfs_ name_ser: basic_name_server_thread_for_volume_component() name_ser| l4vfs_basic_name_server_thread_for_volume_component(): After: l4vfs_b name_ser: asic_name_server_thread_for_volume_component() n_s_test| main(): Volume server for other volume (0.0) '7FF.7F' name_ser| l4vfs_name_space_provider_register_volume_component(): register_volum name_ser: e: 5.0 name_ser| L4RM: [PF] read at 0x012ffd14, eip 012003f9, src D.02 name_ser| [D.0] l4rm/lib/src/pagefault.c:75:__unknown_pf(): name_ser| unhandled page fault
I seem to get a lot of Double PF when loading my own or test programs.
That's strange. My CVS version runs without any problems. Which version are you working with? L4Env release? Remote CVS (date)?
Regards
Christian,
That's strange. My CVS version runs without any problems. Which version are you working with? L4Env release? Remote CVS (date)?
I made a complete new CVS checkout on 2004-09-08 and compiled L4 against the new l4linux-2.4. L4Linux loads again!
...BUT...
Program "name_server_test" still fails with Page Fault. This time the output looks a bit different:
tftp | Loading (nd)/fiasco/name_server_test [551kB] loader | "(nd)/fiasco/name_server_test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ exec | name_server_test: Loading exec | name_server_test: Has no dynamic info exec | name_server_test: Saved 20647 bytes of symbols exec | name_server_test: library "libloader.s.so" not found loader | name_server_test: Starting sigma0-style application exec | name_server_test: Packed 14374 bytes of symbols exec | name_server_test: Packed 69740 bytes of lines loader | name_server_test,#20: Entry at 00009c74 => 00980000 loader | name_server_test,#20: Started run | . n_s_test| main(): Results follow below (should be as predicted (123) == '123'). n_s_test| main(): Volume stuff: ******************* n_s_test| main(): Name server thread id (8.2) 'D.02' n_s_test| main(): Volume server for NS volume (8.2) 'D.02' n_s_test| main(): Volume server for other volume (0.0) '7FF.7F' name_ser| L4RM: [PF] read at 0x012ffd14, eip 012003f9, src D.02 name_ser| [D.0] l4rm/lib/src/pagefault.c:75:__unknown_pf(): name_ser| unhandled page fault
Q1: Any suggestions on this error? Q2: Should I still be using the "names"-module or has "name_server" replaced it?
Cheers Leon
Hi all,
I've noticed that I often get a Double PF error if I load the same (or a different program) directly after each other. I've been trying different programs to see if I can get a pattern but without any luck. In this debug output I ran the program "simple_ts_test" directly after each other and .....Double PF error. This has happened to dm_phys_test, thread_test, and others.
Q1: Is this just my setup or a possible bug?
I've also noticed that the apps starting directly after each other gets the same task-ID. This is new (my 04-08-01 CVS build always incremented the number). Maybe this is related to the error?
Q2: From the debug output - why does it not find library "libloader.s.so"?
Cheers Leon
<snip> ts_test | --> App 48: Hello World! ts_test | Task 48.00 stack at 00113000..00113fff is up ts_test | kill ts_test | create ts_test | --> App 49: Hello World! ts_test | Task 49.00 stack at 00114000..00114fff is up ts_test | l4ts_allocate_task(): failed (server=A.00, ret=-12, exc 0) ts_test | Expected error allocating task: -12 ts_test | 50 tasks created ts_test | Task 49.00 killed ts_test | Task 49.00 freed ts_test | Task 49.00 with diff. version number re-allocated ts_test | --> App 50: Hello World! ts_test | Task 49.00 re-created simple_t| l4_ts_exit_component(): Exit 17.02 run | l run | tftp | Loading (nd)/fiasco/simple_ts_test [597kB] loader | "(nd)/fiasco/simple_ts_test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ exec | simple_ts_test: Loading exec | simple_ts_test: Saved 20339 bytes of symbols exec | simple_ts_test: library "libloader.s.so" not found loader | simple_ts_test: Starting sigma0-style application exec | simple_ts_test: Packed 14191 bytes of symbols exec | simple_ts_test: Packed 55086 bytes of lines loader | simple_ts_test,#17: Entry at 00009c78 => 00a00000 loader | simple_ts_test,#17: Started run | . loader | simple_ts_test,#17: Double PF (r) at 0000afe4 eip 00a0f6e5 (17.00)
On Wednesday 08 September 2004 18:02, Leon wrote:
I've noticed that I often get a Double PF error if I load the same (or a different program) directly after each other. I've been trying different programs to see if I can get a pattern but without any luck. In this debug output I ran the program "simple_ts_test" directly after each other and .....Double PF error. This has happened to dm_phys_test, thread_test, and others.
Very strange. We've fixed an L4env bug today which could be related to your problem. Please wait until tomorrow until the remote-CVS is in sync and try again. At least I can not reproduce your bug with dm_phys_test with our current CVS.
Q1: Is this just my setup or a possible bug?
I've also noticed that the apps starting directly after each other gets the same task-ID. This is new (my 04-08-01 CVS build always incremented the number). Maybe this is related to the error?
No, there is no relation.
Q2: From the debug output - why does it not find library "libloader.s.so"?
It's not a bug, only a message. The loader differs between binaries that are linked against the libloader.s.so and binaries that are not.
Frank
Frank,
Q2: From the debug output - why does it not find library "libloader.s.so"?
It's not a bug, only a message. The loader differs between binaries that are linked against the libloader.s.so and binaries that are not.
So, does the message simply state that the binary being loaded is not linked against the lib? If so, the message is a very ambiguous since it could also mean, for a binary that is actually linked to the lib, that it could not load the lib from the file provider.
Cheers Leon
Hi all,
Just a note...ever since I've started to work with L4 I've received a compile error when compiling the example "input_test" in the pkg/overlay_wm/examples directory. Since I do not require the example I just "rm -rf"-ed the directory and continued with the compile.
As I said: just a note.
Cheers Leon
Sorry, I fogot to add the debug output:
==> Linking testovlinput /usr/bin/ld: cannot find -lthread_linux collect2: ld returned 1 exit status make[6]: *** [testovlinput] Error 1 make[6]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/overlay_wm/examples/input_test/l4lx/OBJ-x86_586-l4v2' make[5]: *** [OBJ-x86_586-l4v2] Error 2 make[5]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/overlay_wm/examples/input_test/l4lx' make[4]: *** [l4lx] Error 2 make[4]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/overlay_wm/examples/input_test' make[3]: *** [input_test] Error 2 make[3]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/overlay_wm/examples' make[2]: *** [examples] Error 2 make[2]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/overlay_wm' make[1]: *** [overlay_wm.bin] Error 2 make[1]: Leaving directory `/root/Fiasco_L4Env/l4/pkg' make: *** [pkg] Error 2
On Thu, 09 Sep 2004 09:17:35 +0200, Leon ljbrits@fastmail.fm wrote:
Hi all,
Just a note...ever since I've started to work with L4 I've received a compile error when compiling the example "input_test" in the pkg/overlay_wm/examples directory. Since I do not require the example I just "rm -rf"-ed the directory and continued with the compile.
As I said: just a note.
Cheers Leon
Hi Leon,
==> Linking testovlinput /usr/bin/ld: cannot find -lthread_linux collect2: ld returned 1 exit status
Thanks for reporting. The example requires the package thread_linux, which was not exported to our remote-cvs until now. Soon (hopefully tomorrow), it will be available at the remote-cvs (l4/pkg/thread_linux).
Greetings, Norman
Frank,
.....Double PF error. This has happened to dm_phys_test, thread_test,
Very strange. We've fixed an L4env bug today which could be related to your problem. Please wait until tomorrow until the remote-CVS is in sync and try again. At least I can not reproduce your bug with dm_phys_test with our current CVS.
New CVS checkout today (090904) but the "Double Page Fault"-problem persists!!
Correct me if I'm wrong but to be a "Double" Page Fault, it must be a Page Fault within the Pager causing this error. Since I am loading a program it must be the "Backing Pager" that fails which is still part of the Loader program.
Q1: Any suggestions/help to solve this problem! Q2: I do not know the debugger tools at all, so any pointers (or links) on how to start use them to track this problem down would be appreciated.
Thanks Leon
Hello,
On Thu, Sep 09, 2004 at 05:07:40PM +0200, Leon wrote: [...]
Q1: Any suggestions/help to solve this problem!
Maybe this problem is related to bug in the current version of DICE. Please, try downgrading DICE via
cd l4/tool/dice cvs update -D 2004-08-27
and rebuild all IDL-generated files plus all binaries.
Q2: I do not know the debugger tools at all, so any pointers (or links) on how to start use them to track this problem down would be appreciated.
A good one is JDB, look at http://os.inf.tu-dresden.de/~fm3/doc/fiasco/manual.pdf.
Hi all,
Maybe this problem is related to bug in the current version of DICE. Please, try downgrading DICE via
cd l4/tool/dice cvs update -D 2004-08-27
No success. The Double Page Fault error still persist and all my development has seized due to the unstable environment. When I display the TCB of the current thread it says:
thread: d.03 <00080000 001a0c00> prio: 10 mcp: ff mode: Con state: 001 ready
wait for: polling: rcv descr: lcked by: ---.-- timeout : cpu time: 976.000 timeslice: 9760/9760 s pager : d.00 preemptr: 0.00 ready lnk : 7.00 f.02 prsent lnk: d.01 d.02 EAX=0000000a ESI=00000000 DS=0023 EBX=0132cc58 EDI=00000004 ES=0023 <enter_kdebug ("loader pager") ECX=00004000 EBP=00bfffdc GS=0023 mov -44(%ebp),%eax EDX=00bffed4 ESP=00bfff54 SS=0023 trapno 3, error 00000000, from user mode CS=001b EIP=013037da EFlags=00003246 kernel ESP=c0341d50
d40: 00003286 c0341800 f000596b c0341800 f0005980 c0180000 f004cab4 fd7420b0 d60: 00003282 f004cab4 c0341800 00000000 00001010 00000000 f0004d08 c0341800 d80: c0180000 00000001 f004cab4 f004cab4 00000000 00000000 00000000 c01800e8 da0: f000c422 c01800e8 00000000 f0006958 c0341800 ee117b00 00000000 c0341800 dc0: c0341e78 ee117b00 c01800e8 00000000 00000003 ee110000 c0180000 00bffe18 de0: c01807d0 00004100 f000d6f9 c0341800 c0180000 00000000 fdbf9eec fdbf9ee4 e00: 00000f93 fdc733bb 00000003 000003bc 00001000 ffffffff fdbeb000 fdbf9000 e20: 00000051 00000000 00000000 ee0141b8 00bffe18 fdc94f48 00000007 00000002
Is seems to stop in the "loader pager". Can anybody give me pointers on what I can do at this point to get more information to help solve this problem.
On Monday 13 September 2004 09:20, Leon wrote:
No success. The Double Page Fault error still persist and all my development has seized due to the unstable environment.
[...]
Is seems to stop in the "loader pager". Can anybody give me pointers on what I can do at this point to get more information to help solve this problem.
To be able to help you I need the exact configuration you used -- mainly your menu.lst entry and the L4 debug output.
Frank
Hi all,
I've resorted to the last stable build I've had at the beginning of this month so that I can continue development. I made the same test with "simple_ts_test" and found the following when executing the second time.
<snip> ts_test | Expected error allocating task: -12 ts_test | 48 tasks created ts_test | Task 49.0 killed ts_test | Task 49.0 freed ts_test | Task 49.0 (00080000:00920000) with diff. version number re-allocated ts_test | --> App 48: Hello World! ts_test | Task 49.0 re-created simple_t| l4_ts_exit_component(): Exit 19.02 sent by 19.02 tftp | Loading (nd)/fiasco/simple_ts_test [97kB] loader | "(nd)/fiasco/simple_ts_test" is a valid binary image loader | Setting libpath to (nd)/fiasco/ exec | simple_ts_test: Loading exec | simple_ts_test: Has no dynamic info exec | simple_ts_test: Has no symbols exec | simple_ts_test: Has no lines exec | simple_ts_test: library "libloader.s.so" not found loader | simple_ts_test: Starting sigma0-style application loader | l4ts_allocate_task(): failed (server=A.00, ret=-12, exc 0) loader | simple_ts_test,#49: Error -12 (no task available) allocating tas loader : k at task server loader | ==> App successfully purged
Q1: Please explain "no task available" - no memory? maximum allowed tasks allocated? Q2: Is this maybe the error producing the Double PF error now?
Cheers (for today) Leon
Hi all,
With both Friday's (2004-09-10) and today's (2004-09-13) CVS update I get the error:
=== Building servers, examples of "l4io" === make[1]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io' make[2]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io/server' make[3]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci' make[4]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src' PWD=/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/OBJ-x86_586-l4v2 make -C OBJ-x86_586-l4v2 -f Makefile make[5]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/OBJ-x86_586-l4v2' ... Compiling arch-i386/pci-irq.o /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c: In function `intel_router_probe': /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:578: error: `PCI_DEVICE_ID_INTEL_82443GX_0' undeclared (first use in this function) /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:578: error: (Each undeclared identifier is reported only once /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:578: error: for each function it appears in.) /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:579: error: `PCI_DEVICE_ID_INTEL_82443GX_2' undeclared (first use in this function) /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:598: error: `PCI_DEVICE_ID_INTEL_ICH6_0' undeclared (first use in this function) make[5]: *** [arch-i386/pci-irq.o] Error 1 make[5]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/OBJ-x86_586-l4v2' make[4]: *** [OBJ-x86_586-l4v2] Error 2 make[4]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src' make[3]: *** [src] Error 2 make[3]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci' make[2]: *** [lib-pci] Error 2 make[2]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io/server' make[1]: *** [server] Error 2 make[1]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io' make: *** [l4io.bin] Error 2
Q1: Any suggestions on the above problem? Q2: Am I the only one on this mailing list that gets these compile errors? Q3: Which distro do you Dresden guys use. I will switch if it means less problems. Q4: At what time GMT does the public cvs get updated?
Thanks Leon
Hi,
On Mon, Sep 13, 2004 at 09:20:59AM +0200, Leon wrote:
Hi all,
With both Friday's (2004-09-10) and today's (2004-09-13) CVS update I get the error:
=== Building servers, examples of "l4io" === make[1]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io' make[2]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io/server' make[3]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci' make[4]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src' PWD=/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/OBJ-x86_586-l4v2 make -C OBJ-x86_586-l4v2 -f Makefile make[5]: Entering directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/OBJ-x86_586-l4v2' ... Compiling arch-i386/pci-irq.o /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c: In function `intel_router_probe': /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:578: error: `PCI_DEVICE_ID_INTEL_82443GX_0' undeclared (first use in this function) /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:578: error: (Each undeclared identifier is reported only once /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:578: error: for each function it appears in.) /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:579: error: `PCI_DEVICE_ID_INTEL_82443GX_2' undeclared (first use in this function) /root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/arch-i386/pci-irq.c:598: error: `PCI_DEVICE_ID_INTEL_ICH6_0' undeclared (first use in this function) make[5]: *** [arch-i386/pci-irq.o] Error 1 make[5]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src/OBJ-x86_586-l4v2' make[4]: *** [OBJ-x86_586-l4v2] Error 2 make[4]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci/src' make[3]: *** [src] Error 2 make[3]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io/server/lib-pci' make[2]: *** [lib-pci] Error 2 make[2]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io/server' make[1]: *** [server] Error 2 make[1]: Leaving directory `/root/Fiasco_L4Env/l4/pkg/l4io' make: *** [l4io.bin] Error 2
Q1: Any suggestions on the above problem?
These errors occur if you use incompatible Linux-Headers to L4IO's libpci. LINUX24_INCDIR must be set correctly to Linux 2.4.27 headers via "make config" in L4DIR (or manually). I use
LINUX24_AVAIL=y LINUX24_DIR=$(L4DIR)/../l4linux-2.4 LINUX24_INCDIR=$(L4DIR)/../l4linux-2.4/include
and it works for me.
Q2: Am I the only one on this mailing list that gets these compile errors? Q3: Which distro do you Dresden guys use. I will switch if it means less problems.
We use Debian, but because of problems with other distros we improved compatibility. IIRC, there is a bit of documentation about these issues on the website.
Q4: At what time GMT does the public cvs get updated?
I think it starts around "04:50:00 CEST" (02:50 GMT).
Chao
On Thursday 09 September 2004 17:07, Leon wrote:
Frank,
.....Double PF error. This has happened to dm_phys_test, thread_test,
Very strange. We've fixed an L4env bug today which could be related to your problem. Please wait until tomorrow until the remote-CVS is in sync and try again. At least I can not reproduce your bug with dm_phys_test with our current CVS.
New CVS checkout today (090904) but the "Double Page Fault"-problem persists!!
BTW: The remote CVS was not updated this night since there were errors in the build process.
Frank
Howdy there from Texas A&M, I've been listening in on the list for about a month or two, having a vested interest in T.U. Dresden.
But a question, is the OS Group, a graduate student, and PhD student type thing? (I'm still an undergrad)
I ask because i'm currently in the process of working out an exchange between my Uni. and T.U. Dresden, if I could somehow intern, or something like that while i'm there with the OS Group I would really have a chance to extend my CompEng knowledge
Just as a sidenote, Bjarne Stroustrop is one of my professors for C++, so I've got an even larger vested interest in a C++ based kernel ;)
Suggestions, comments?
-Tyler
----------------- R. Tyler Ballance NetBSD-FreeBSD
Leon wrote:
<...>
Q2: Should I still be using the "names"-module or has "name_server" replaced it?
No, name_server has not replaced names. It is used for a different purpose: the namespace administration in l4vfs. If you don't use l4vfs-features, don't run the name_server.
Greets, Martin
l4-hackers@os.inf.tu-dresden.de
-
Christian Helmuth -
Frank Mehnert -
Leon -
Martin Pohlack -
Norman Feske -
R. Tyler Ballance