Hello,
I have been looking at trying out L4Linux in UX mode as a first step towards its use on "native" Fiasco, and I seem to be experiencing a problem with launching the Linux kernel itself.
I have followed the instructions from these pages:
https://l4linux.org/download.shtml https://l4linux.org/build.shtml https://l4linux.org/use.shtml
Specifically, I have an existing build of UX that has been used for some time to develop software. I have updated it to revision 83 and have checked out the l4linux_requirements, which appear to be some packages (rtc and shmc) I already have. I then performed a build once again:
make O=mybuild
The L4Linux repository has also been checked out and updated to revision 83. The code has been configured and built using the following invocations:
make O=mybuild x86_32-ux_defconfig make O=mybuild menuconfig # to set the L4Re build directory make O=mybuild
Here, the mybuild directory is distinct from the L4Re mybuild directory.
For the initial RAM filesystem, I downloaded the ramdisk-x86.rd file, and I run the system as follows:
make O=mybuild ux E=L4Linux-basic
After the usual familiar start-up messages, I see this output specific to the configuration being launched:
---- Ned: loading file: 'rom/l4lx.cfg' libio: Warning: Query of 'vbus' failed! PH 0 offs=00001000 flags=r-x PH-type=0x1 virt=00100000 evirt=0053f000 phys=00100000 ephys=0053f000 f_sz=0043f000 memsz=0043f000 PH 1 offs=00440000 flags=rw- PH-type=0x1 virt=0053f000 evirt=00a58000 phys=0053f000 ephys=00a58000 f_sz=0006ce9f memsz=00519000 PH 2 offs=00371ee0 flags=--- PH-type=0x4 virt=00470ee0 evirt=00470f1c phys=00470ee0 ephys=00470f1c f_sz=0000003c memsz=0000003c Starting binary at 0x100000, argc=6 argv=0xafff4f84 *argv=0xb1007ff4 argv0=rom/vmlinuz External resolver is at 0xa8000bd0 L4Re: rom/vmlinuz: Unhandled exception: PC=0x46980b PFA=97d47fe0 LdrFlgs=0 ----
In order to try and identify the problem, I used the following command:
addr2line -e ~/L4/L4Linux/l4linux/mybuild/vmlinux 0x46980b
This seems to indicate that the point of failure is at line 2727 in arch/l4/kernel/main.c which is the start of this function:
int __ref L4_CV main(int argc, char **argv)
So, I wonder what the problem might be that leads to a crash as the main function is being invoked. Have I missed anything obvious?
All of this is being done in a Debian unstable chroot on x86.
Paul
Hi Paul,
On Thu Mar 28, 2019 at 23:28:17 +0100, Paul Boddie wrote:
I have been looking at trying out L4Linux in UX mode as a first step towards its use on "native" Fiasco, and I seem to be experiencing a problem with launching the Linux kernel itself.
I have followed the instructions from these pages:
https://l4linux.org/download.shtml https://l4linux.org/build.shtml https://l4linux.org/use.shtml
Specifically, I have an existing build of UX that has been used for some time to develop software. I have updated it to revision 83 and have checked out the l4linux_requirements, which appear to be some packages (rtc and shmc) I already have. I then performed a build once again:
make O=mybuild
The L4Linux repository has also been checked out and updated to revision 83. The code has been configured and built using the following invocations:
make O=mybuild x86_32-ux_defconfig make O=mybuild menuconfig # to set the L4Re build directory make O=mybuild
Here, the mybuild directory is distinct from the L4Re mybuild directory.
For the initial RAM filesystem, I downloaded the ramdisk-x86.rd file, and I run the system as follows:
make O=mybuild ux E=L4Linux-basic
After the usual familiar start-up messages, I see this output specific to the configuration being launched:
Ned: loading file: 'rom/l4lx.cfg' libio: Warning: Query of 'vbus' failed! PH 0 offs=00001000 flags=r-x PH-type=0x1 virt=00100000 evirt=0053f000 phys=00100000 ephys=0053f000 f_sz=0043f000 memsz=0043f000 PH 1 offs=00440000 flags=rw- PH-type=0x1 virt=0053f000 evirt=00a58000 phys=0053f000 ephys=00a58000 f_sz=0006ce9f memsz=00519000 PH 2 offs=00371ee0 flags=--- PH-type=0x4 virt=00470ee0 evirt=00470f1c phys=00470ee0 ephys=00470f1c f_sz=0000003c memsz=0000003c Starting binary at 0x100000, argc=6 argv=0xafff4f84 *argv=0xb1007ff4 argv0=rom/vmlinuz External resolver is at 0xa8000bd0 L4Re: rom/vmlinuz: Unhandled exception: PC=0x46980b PFA=97d47fe0 LdrFlgs=0
In order to try and identify the problem, I used the following command:
addr2line -e ~/L4/L4Linux/l4linux/mybuild/vmlinux 0x46980b
This seems to indicate that the point of failure is at line 2727 in arch/l4/kernel/main.c which is the start of this function:
int __ref L4_CV main(int argc, char **argv)
So, I wonder what the problem might be that leads to a crash as the main function is being invoked. Have I missed anything obvious?
Guess not except that doing this on UX could be a bit adventurous nowadays. Which instruction is sitting at 0x46980b?
Adam
On Wednesday 3. April 2019 07.56.32 Adam Lackorzynski wrote:
On Thu Mar 28, 2019 at 23:28:17 +0100, Paul Boddie wrote:
In order to try and identify the problem, I used the following command:
addr2line -e ~/L4/L4Linux/l4linux/mybuild/vmlinux 0x46980b
This seems to indicate that the point of failure is at line 2727 in arch/l4/kernel/main.c which is the start of this function:
int __ref L4_CV main(int argc, char **argv)
So, I wonder what the problem might be that leads to a crash as the main function is being invoked. Have I missed anything obvious?
Guess not except that doing this on UX could be a bit adventurous nowadays. Which instruction is sitting at 0x46980b?
I used this command to check:
objdump -d -S ~/L4/L4Linux/l4linux/mybuild/vmlinux
Here's the instruction in context (as the third from the end):
004697f0 <main>: { 4697f0: 55 push %ebp 4697f1: 89 e5 mov %esp,%ebp 4697f3: 57 push %edi 4697f4: 56 push %esi LOG_printf("%s", linux_banner); 4697f5: be 80 40 47 00 mov $0x474080,%esi { 4697fa: 53 push %ebx 4697fb: 81 ec 9c 01 00 00 sub $0x19c,%esp LOG_printf("\033[34;1m======> L4Linux starting... <========\033[0m\n"); 469801: c7 04 24 c8 b5 4e 00 movl $0x4eb5c8,(%esp) { 469808: 8b 5d 0c mov 0xc(%ebp),%ebx 46980b: 65 a1 14 00 00 00 mov %gs:0x14,%eax 469811: 89 45 f0 mov %eax,-0x10(%ebp) 469814: 31 c0 xor %eax,%eax
So, it seems to be storing a register value into a particular segment, as far as I can tell. I hope this is helpful.
Paul
l4-hackers@os.inf.tu-dresden.de