Hi!
I tried running l4linux26 on fiasco-ux compiled from the actual CVS with the dietlibc using the following script:
fiasco -t 32768 \ -G800x600@16 \ -m 512 \ -R roottask \ -l names \ -l log \ -l dm_phys \ -l simple_ts -t 380 \ -l fuxfprov -n9 \ -l rtc-ux -n10 \ -l l4exec \ -l l4dope-ux \ -l "loader run l4linux26.cfg"
Unfortunatly, l4linux causes a null pointer exceptions (see attached log). I tried various kernel compiler options with always the same error. Any idea for the reason or what I can try else?
Thanks a lot Marko
PS: By the way, Im using gcc 3.3.6
Hi Marko,
On Tuesday 25 October 2005 14:28, Marko Wolf wrote:
Unfortunatly, l4linux causes a null pointer exceptions (see attached log). I tried various kernel compiler options with always the same error. Any idea for the reason or what I can try else?
Please could you provide more information: The program code near the crashing EIP is important. Please start your script again, and do
objdump -ld \ --start-address=<faulting EIP - 0x80> \ --stop-address=<faulting EIP + 0x80> \ vmlinux > vmlinux.dump
and send the resulting file vmlinux.dump to his list.
Thanks,
Frank
According to the following log I dumped the program code around EIP 0x00544bfc.
Best regards Marko
[..] l4lx | ======> L4Linux 2.6 starting... <======== l4lx | Binary name: vmlinuz26.ux l4lx | Kernel command line (8 args): mem=64M noreplacement root=1:0 load_ram l4lx : disk=1 ramdisk_size=56000 l4env_rd=ramdisk.gz panicblink=0 lang=de l4lx | Image: 00400000 - 005c11b0 [1796 KiB]. l4lx | Areas: Text: 00400000 - 00511000 [1092kB] (a bit longer) l4lx | Data: 00511000 - 0053a2c8 [164kB] l4lx | Initdata: 0053e000 - 00557000 [100kB] l4lx | BSS: 00557008 - 005c11b0 [424kB] l4lx | l4lx_thread_create: Created thread 0f.03 (server) l4lx | main thread will be 0f.03 l4lx | l4env_register_pointer_section: addr = 0053c000 size = 544768 l4lx | with-init: virt: 0x0053c000 to 0x005c0fff [532 KiB] l4lx | with-init: Number of physical regions: 1, 544768 Bytes l4lx | with-init: 1: Phys: 0x01756000 to 0x017db000, Size: 544768 l4lx | l4env_linux_startup thread 3. l4lx | main thread: received startup message. l4lx | L4RM: [PF] read at 0x00000000, eip 00544bfc, src F.03 l4lx | [F.0] l4rm/lib/src/pagefault.c:78:__unknown_pf(): l4lx | unhandled page fault
--PANIC, 'g' for exit-------------------------------ESP:00008a80 EIP:00021a33 (f.00) jdb:
Please could you provide more information: The program code near the crashing EIP is important. Please start your script again, and do
objdump -ld \ --start-address=<faulting EIP - 0x80> \ --stop-address=<faulting EIP + 0x80> \ vmlinux > vmlinux.dump
On Wednesday 26 October 2005 18:23, Marko Wolf wrote:
According to the following log I dumped the program code around EIP 0x00544bfc.
Thanks for the dump. As the fault is due to accessing gs:0, I assume a problem with 1) your host Linux setup. Which Linux kernel do you use? Which C library? 2) your Fiasco-UX setup. Did you enable Kernel Options / ABI Extensions / Handle and preserver segments? But IMHO that is checked by L4Linux itself...
Frank
Hi Frank!
I'm compiling FUX w/ a 2.6.12 Debian w/ libc 2.5.3 and I enabled all experimental options except KIP_SYSCALLS and LOCAL_IPC. However, I updated the sources from your CVS again and - viola - now its running with the same configuration as before with only a unhandled kernel trap (that fortunately doesn't halts the bootup procedure) when using l4dope instead of (errorfree) console.
Thanks for your help! Marko
fuxfprov| open "../tools/ramdisk-ux.gz" by F.03 l4lx | INITRD: Size of RAMdisk is 55000KiB l4lx | RAMdisk from 08800000 to 0bdb6000 [55000KiB] l4lx | l4lx_thread_create: Created thread 0f.04 (timer.i0) run | l4con/lib/src/contxt.c:63:contxt_init(): run | names failed run | main(): Error -3 opening contxt lib -- terminating l4lx | Starting L4FB via DOpE
KERNEL: e.2 (tcb=50702000) killed: Unhandled trap
EAX 00000000 EBX 00afff04 ECX 00000000 EDX 00000000 ESI 00000000 EDI 00000000 EBP 00affeec ESP 00affed4 EIP 01303a78 EFLAGS 00010246 CS 0002 SS 007b DS 007b ES 007b FS 0000 GS 0007 trapno 16, error 00000000, from user mode
On Thursday 27 October 2005 17:10 Frank Mehnert wrote:
Thanks for the dump. As the fault is due to accessing gs:0, I assume a problem with
- your host Linux setup. Which Linux kernel do you use? Which C library?
- your Fiasco-UX setup. Did you enable Kernel Options / ABI Extensions / Handle and preserver segments? But IMHO that is checked by L4Linux itself...
On Wed, 2 Nov 2005 13:18:15 +0100 Marko Wolf (MW) wrote:
MW> I'm compiling FUX w/ a 2.6.12 Debian w/ libc 2.5.3 and I enabled all MW> experimental options except KIP_SYSCALLS and LOCAL_IPC. However, I MW> updated the sources from your CVS again and - viola - now its running with MW> the same configuration as before with only a unhandled kernel trap (that MW> fortunately doesn't halts the bootup procedure) when using l4dope instead MW> of (errorfree) console. MW> MW> KERNEL: e.2 (tcb=50702000) killed: MW> Unhandled trap MW> MW> EAX 00000000 EBX 00afff04 ECX 00000000 EDX 00000000 MW> ESI 00000000 EDI 00000000 EBP 00affeec ESP 00affed4 MW> EIP 01303a78 EFLAGS 00010246 MW> CS 0002 SS 007b DS 007b ES 007b FS 0000 GS 0007 MW> trapno 16, error 00000000, from user mode ^^^^^^^^^
Try disassembling the offending program (Task E) using objdump -DC <binary> and find out what's at EIP 0x1303a78. I bet it's a DIV instruction and the operand is 0.
-Udo.
On Wednesday 02 November 2005 14:10, Udo A. Steinberg wrote:
On Wed, 2 Nov 2005 13:18:15 +0100 Marko Wolf (MW) wrote:
MW> I'm compiling FUX w/ a 2.6.12 Debian w/ libc 2.5.3 and I enabled all MW> experimental options except KIP_SYSCALLS and LOCAL_IPC. However, I MW> updated the sources from your CVS again and - viola - now its running with MW> the same configuration as before with only a unhandled kernel trap (that MW> fortunately doesn't halts the bootup procedure) when using l4dope instead MW> of (errorfree) console. MW> MW> KERNEL: e.2 (tcb=50702000) killed: MW> Unhandled trap MW> MW> EAX 00000000 EBX 00afff04 ECX 00000000 EDX 00000000 MW> ESI 00000000 EDI 00000000 EBP 00affeec ESP 00affed4 MW> EIP 01303a78 EFLAGS 00010246 MW> CS 0002 SS 007b DS 007b ES 007b FS 0000 GS 0007 MW> trapno 16, error 00000000, from user mode ^^^^^^^^^
Try disassembling the offending program (Task E) using objdump -DC <binary> and find out what's at EIP 0x1303a78. I bet it's a DIV instruction and the operand is 0.
Just an additional remark: At this state you simply need to press CTRL+C and type
ut16<SPACE>1303a78<SPACE>
Frank
On Wednesday 02 November 2005 14:34, Frank Mehnert wrote:
On Wednesday 02 November 2005 14:10, Udo A. Steinberg wrote:
On Wed, 2 Nov 2005 13:18:15 +0100 Marko Wolf (MW) wrote:
MW> I'm compiling FUX w/ a 2.6.12 Debian w/ libc 2.5.3 and I enabled all MW> experimental options except KIP_SYSCALLS and LOCAL_IPC. However, I MW> updated the sources from your CVS again and - viola - now its running with MW> the same configuration as before with only a unhandled kernel trap (that MW> fortunately doesn't halts the bootup procedure) when using l4dope instead MW> of (errorfree) console. MW> MW> KERNEL: e.2 (tcb=50702000) killed: MW> Unhandled trap MW> MW> EAX 00000000 EBX 00afff04 ECX 00000000 EDX 00000000 MW> ESI 00000000 EDI 00000000 EBP 00affeec ESP 00affed4 MW> EIP 01303a78 EFLAGS 00010246 MW> CS 0002 SS 007b DS 007b ES 007b FS 0000 GS 0007 MW> trapno 16, error 00000000, from user mode ^^^^^^^^^
Try disassembling the offending program (Task E) using objdump -DC <binary> and find out what's at EIP 0x1303a78. I bet it's a DIV instruction and the operand is 0.
Just an additional remark: At this state you simply need to press CTRL+C and type
ut16<SPACE>1303a78<SPACE>
Sorry, please use
ute<SPACE>1303a78<SPACE>
(That is <u> ... disassemble, <t> ... task/address space, <e> => task 0xe).
Frank
On Wednesday 02 November 2005 14:10, Udo A. Steinberg wrote: Try disassembling the offending program (Task E) using objdump -DC <binary> and find out what's at EIP 0x1303a78. I bet it's a DIV instruction and the operand is 0.
On Wednesday 02 November 2005 14:48, Frank Mehnert wrote: Please use ute<SPACE>1303a78<SPACE>
Yes, the faulting assembler instruction in the coresponding task (the "run" module) at 0x1303a78 is in fact IDIV.
Marko
On Wednesday 02 November 2005 15:25, Marko Wolf wrote:
On Wednesday 02 November 2005 14:10, Udo A. Steinberg wrote: Try disassembling the offending program (Task E) using objdump -DC <binary> and find out what's at EIP 0x1303a78. I bet it's a DIV instruction and the operand is 0.
On Wednesday 02 November 2005 14:48, Frank Mehnert wrote: Please use ute<SPACE>1303a78<SPACE>
Yes, the faulting assembler instruction in the coresponding task (the "run" module) at 0x1303a78 is in fact IDIV.
Hmm. Let me guess which module 0x0e is: The run application? To use that application together with DOpE you need the proxygon application. If you could provide some disassembler listing of your run module around the faulting EIP we could investigate the bug. Perhaps it faults because it could not found proxygon...
Frank
Yes, with proxygon loaded the kernel trap disposes, thus in fact the bug was because "run" couldn't find proxygon.
Thanks again Marko
Am Mittwoch, 2. November 2005 17:31 schrieb Frank Mehnert:
On Wednesday 02 November 2005 15:25, Marko Wolf wrote:
Yes, the faulting assembler instruction in the coresponding task (the "run" module) at 0x1303a78 is in fact IDIV.
Hmm. Let me guess which module 0x0e is: The run application? To use that application together with DOpE you need the proxygon application. If you could provide some disassembler listing of your run module around the faulting EIP we could investigate the bug. Perhaps it faults because it could not found proxygon...
Marko,
On Wednesday 02 November 2005 17:51, Marko Wolf wrote:
Yes, with proxygon loaded the kernel trap disposes, thus in fact the bug was because "run" couldn't find proxygon.
you could help me a lot (and the next user which has the same problem) if you could try to start your config again without proxygon and post some disassembler listing around the faulting EIP so we can fix the bug. Perhaps we can reproduce the behaviour, but I'm not sure ...
Frank
On Wednesday 02 November 2005 18:08, Frank Mehnert wrote:
Marko,
On Wednesday 02 November 2005 17:51, Marko Wolf wrote:
Yes, with proxygon loaded the kernel trap disposes, thus in fact the bug was because "run" couldn't find proxygon.
you could help me a lot (and the next user which has the same problem) if you could try to start your config again without proxygon and post some disassembler listing around the faulting EIP so we can fix the bug. Perhaps we can reproduce the behaviour, but I'm not sure ...
Ok,
I could reproduce that issue. Fix should be in remote CVS tomorrow. Just for info for the next time you want to search a bug like this: Enter JDB with CTRL-C (in Fiasco/UX or serial_esc in Fiasco/IA32), disassemble the code around the faulting EIP with ut<task number>, look if you find some useful info (sourcc lines). Take the backtrace of the faulting thread
bt<thread number>, in your case bte.2
Frank
l4-hackers@os.inf.tu-dresden.de
-
Frank Mehnert -
Marko Wolf -
Udo A. Steinberg