Package: guix;
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Wed, 5 Oct 2022 21:02:01 UTC
Severity: normal
Tags: wontfix
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Message #23 received at 58320 <at> debbugs.gnu.org (full text, mbox):
From: Samuel Thibault <samuel.thibault <at> gnu.org> To: Ludovic Courtès <ludo <at> gnu.org> Cc: bug-hurd <at> gnu.org, 58320 <at> debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) Date: Fri, 7 Oct 2022 23:16:43 +0200
Ludovic Courtès, le ven. 07 oct. 2022 10:24:22 +0200, a ecrit: > trap, eip 0xc10305c1 > Breakpoint at task_terminate: pushl %ebp > db> show all threads > TASK THREADS > 0 gnumach (f5f7cf00): 7 threads: > 0 (f5f7be18) .W..N. 0xc11dac04 > 1 (f5f7bcd0) R..O..(idle_thread_continue) > 2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4 > 3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c > 4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0 > 5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74 > 6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8 > 1 ext2fs (f5f7ce40): 6 threads: > 0 (f5f7b520) .W.O.F(mach_msg_continue) 0 > 1 (f5f7b290) .W.O..(mach_msg_receive_continue) 0 > 2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0 > 3 (f5f7b000) .W.O..(mach_msg_continue) 0 > 4 (f67d4e20) .W.O..(mach_msg_receive_continue) 0 > 5 (f67d4cd8) .W.O..(mach_msg_continue) 0 > 2 exec (f5f7cd80): (f5f7b3d8) R..... > db> trace/t 0xf5f7b3d8 > task_terminate(f625eb10,0,f5f7cd80,f5f7b3d8,c11da940) > exception_try_task(1,1,bffefffc,ffffffff,c1202b4c)+0x58 > exception(1,1,bffefffc,c10096da,f5957fbc)+0x7a > interrupted_pc(1,1,bffefffc,c102ce99,c1202b40) > trap_name(1,f5957f80,f5f73f4c,f5f73f58) > vm_fault(f5f6ff30,bffef000,3,0,0,c1008ee4,f5f82550,fb7d9000)+0x74a > user_trap(f5f7a718)+0x2df > >>>>> Page fault (14) at 0x1000 <<<<< > >>>>> user space <<<<< > db> show map $map2 > Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5 > size=290816,resident:290816,wired=0 > version=14 > map entry 0xf625ec08: start=0x0, end=0x1000 > prot=1/7/copy, object=0xf5f6a7d0, offset=0x0 > Object 0xf5f6a7d0: size=0x1000, 1 references > 1 resident pages, 0 absent pages, 0 paging ops > memory object=0x0 (offset=0x0),control=0x0, name=0xf5938968 > uninitialized,temporary internal,copy_strategy=0 > shadow=0x0 (offset=0x0),copy=0x0 > map entry 0xf625ebb0: start=0x1000, end=0x26000 > prot=5/7/copy, object=0xf5f6ad70, offset=0x0 > Object 0xf5f6ad70: size=0x25000, 1 references > 37 resident pages, 0 absent pages, 0 paging ops > memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82780 > uninitialized,temporary internal,copy_strategy=0 > shadow=0x0 (offset=0x0),copy=0x0 > --8<---------------cut here---------------end--------------->8--- > > It says “page fault at 0x1000” but there is apparently a valid mapping > at that address. > > Funny thing: if I set a breakpoint on ‘read_exec’ and continue each time > it’s hit, the ‘exec’ process starts just fine. > > Could it be a synchronization issue somewhere? It'd be surprising that you never gets the issue later on with the system fully booted. About the backtrace: >>>>> user space <<<<< 0x1000(bfffff24,0,0,1160b,0) 0x11627(bfffff9c,0,0,0,2) 0x11bb() That is quite surprising actually: in my ld.so there is nothing useful at 0x1000. Perhaps you can check what 0x11627 is all about? Also, > Program Header: > LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 > filesz 0x00000dd8 memsz 0x00000dd8 flags r-- We don't have this section in the Debian glibc. It'd probably be useful to know what this is about. > LOAD off 0x00001000 vaddr 0x00001000 paddr 0x00001000 align 2**12 > filesz 0x000244a1 memsz 0x000244a1 flags r-x > LOAD off 0x00026000 vaddr 0x00026000 paddr 0x00026000 align 2**12 > filesz 0x0000d5e8 memsz 0x0000d5e8 flags r-- > LOAD off 0x00033f60 vaddr 0x00034f60 paddr 0x00034f60 align 2**12 > filesz 0x00001910 memsz 0x00001a6c flags rw- Samuel
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.