Re: Unresolved page faults when running l4linux-mag

Hi,

sorry, this should be fixed now in the latest snapshot.


Adam

On Mon Mar 21, 2022 at 00:13:12 +0800, Haohui Mai wrote:
> Sorry I forgot to mention that I'm on Ubuntu 20.04 and trying to run
> the x86_64 port of L4Linux.
> 
> ~Haohui
> 
> On Sun, Mar 20, 2022 at 10:38 PM Haohui Mai <[email protected]> wrote:
> >
> > Hello,
> >
> > I'm trying to run the l4linux-mag example in the L4Re snapshot. It
> > seems it will result in an unresolved page fault using the current
> > snapshot (22.01.0):
> >
> > Loading: rom/ramdisk-amd64.rd
> > INITRD: Size of RAMdisk is 4096KiB
> > RAMdisk from 01816000 to 01c16000 [4096KiB]
> > l4lx_thread_create: Created thread 429 (timer0) (u:b3001c00,
> > v:00000000, sp:01557f28)
> > WARNING: Unknown rdmsr: c0000100 at 0x212a20
> > WARNING: Unknown wrmsr: c0000100 at 0x212a33
> > WARNING: Unknown rdmsr: c0000100 at 0x212a4f
> > WARNING: Unknown wrmsr: c0000100 at 0x212a70
> > Non-resolvable page fault at 3612f82, ip 302265.
> > Page fault (non-resolved): pfa=3612f82 pc=302265
> > Non-resolvable page fault at 3612f82, ip 302265.
> > Page fault (non-resolved): pfa=3612f82 pc=302265
> > qemu-system-x86_64: terminating on signal 2
> >
> > Changing the console from ttyS0 to ttyLv0 will go a little bit
> > further, but still result in a page fault:
> >
> > BUG: unable to handle page fault for address: 0000000003612f80
> > #PF: user write access in kernel mode
> > #PF: error_code(0x0006) - not-present page
> > PGD 0 P4D 0
> > Oops: 0006 [#1] SMP
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-l4-ge2ad9258b98e #2
> > RIP: 0028:cache_alloc_refill+0x365/0x610
> > Code: 54 24 24 31 db 85 d2 74 2e 49 8b 44 24 50 48 85 c0 74 11 89 df
> > 41 0f af 7c 24 14 49 03 7d 28 ff d0 0f 1f 00 49 8b 55 20 89 d8 <88> 1c
> > 02 83 c3 01 41 39 5c 24 24 77 d2 45 85 f6 0f 85 fd 01 00 00
> > RSP: 319f9f00:000000001006bca0 EFLAGS: 00000246 ORIG_RAX: 00000000000000f0
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 6db6db6db6db6db7
> > RDX: 0000000003612f80 RSI: 0000000000000001 RDI: 0000000000e57840
> > RBP: 000000000000003c R08: 00000000000194ff R09: 0000000000000002
> > R10: 00000000000194f8 R11: 0000000000000006 R12: 000000001001fc00
> > R13: 00000880000bd3f0 R14: 0000000000000400 R15: 0000000000000dc0
> > FS:  ffffffffffffffff(0000) GS:ffffffffffffffff(0000) knlGS:ffffffffffffffff
> > CS:  0028 DS: 0023 ES: 0023 CR0: ffffffffffffffff
> > CR2: ffffffffffffffff CR3: ffffffffffffffff CR4: ffffffffffffffff
> > Call Trace:
> >  ? idr_alloc_cyclic+0x52/0xb0
> >  kmem_cache_alloc+0xc7/0xe0
> >  __kernfs_new_node.constprop.0+0x59/0x1a0
> >  ? vsnprintf+0x3e6/0x5b0
> >  ? kernfs_link_sibling+0x8d/0xd0
> >  ? kernfs_next_descendant_post+0x7d/0x90
> >  ? kernfs_activate+0x5a/0x80
> >  ? kernfs_add_one+0xdd/0x130
> >  kernfs_new_node+0x1b/0x40
> >  __kernfs_create_file+0x20/0xb0
> >  sysfs_add_file_mode_ns+0x96/0x180
> >  sysfs_create_file_ns+0x5d/0x90
> >  bus_create_file+0x3f/0x60
> >  bus_register+0x180/0x240
> >  subsys_system_register+0x16/0x40
> >  ? ntp_init+0x21/0x21
> >  init_clocksource_sysfs+0xe/0x1f
> >  do_one_initcall+0x44/0x190
> >  kernel_init_freeable+0x161/0x1ab
> >  ? rest_init+0xb0/0xb0
> >  kernel_init+0x11/0x100
> >
> > Any ideas to debug this? Your help is appreciated.
> >
> > Thanks,
> > Haohui