* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)
@ 2022-10-05 21:01 Ludovic Courtès
2022-10-06 13:14 ` Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2022-10-05 21:01 UTC (permalink / raw)
To: 58320; +Cc: bug-hurd
Hello!
On AMD EPYC processors, as found on the build nodes of ci.guix.gnu.org,
childhurd VMs fail to boot when running with ‘qemu-system-i386
-enable-kvm’ (the kvm-amd Linux kernel module is used), with the Hurd
startup process hanging before /hurd/exec has been started:
--8<---------------cut here---------------start------------->8---
module 0: ext2fs --multiboot-command-line=${kernel-command-line} --host-priv-por
t=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-tas
k} --store-type=typed --x-xattr-translator-records ${root} $(task-create) $(task
-resume)
module 1: exec /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167/hu
rd/exec $(exec-task=task-create)
2 multiboot modules
task loaded: ext2fs --multiboot-command-line=root=device:hd0s1 root=3367134b-cfb
d-1e90-2f38-dfd13367134b gnu.system=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-
system gnu.load=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-system/boot --host-p
riv-port=1 --device-master-port=2 --exec-server-task=3 --store-type=typed --x-xa
ttr-translator-records device:hd0s1
task loaded: exec /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167
/hurd/exec
start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec
--8<---------------cut here---------------end--------------->8---
Kdb shows these two tasks:
--8<---------------cut here---------------start------------->8---
Stopped at mach
ine_idle+0x26: nop
machine_idle(0,c102f380,f5f7bcd0,c102e3fa)+0x26
idle_thread_continue(f5f7ade0,36366000,f5f73868,f5f73890,0)+0x73
>>>>> user space <<<<<
db> show all threads
TASK THREADS
0 gnumach (f5f7cf00): 7 threads:
0 (f5f7be18) .W..N. 0xc11dac04
1 (f5f7bcd0) R.....
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.F(mach_msg_receive_continue) 0
2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0
3 (f5f7b000) .W.O..(mach_msg_continue) 0
4 (f67d3e20) .W.O..(mach_msg_receive_continue) 0
5 (f67d3cd8) .W.O..(mach_msg_continue) 0
db> trace/t 0xf5f7b520
Continuation mach_msg_continue
>>>>> user space <<<<<
0x80ccaec()
--8<---------------cut here---------------end--------------->8---
For ext2fs.static, that just means thread 0 is here:
--8<---------------cut here---------------start------------->8---
$ addr2line -e /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167/hurd/ext2fs.static 0x80ccaec
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/mach/mach_msg_trap.S:2
--8<---------------cut here---------------end--------------->8---
That doesn’t tell us much.
The same image boots fine on the same CPU without ‘-enable-kvm’.
However, keeping ‘-enable-kvm’ and adding ‘--cpu pentium’ and other
variants of this option don’t make any difference, AFAICS.
Ideas on how to debug this further, and/or ways to work around it
without giving up on KVM?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-05 21:01 bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) Ludovic Courtès @ 2022-10-06 13:14 ` Ludovic Courtès 2022-10-06 13:53 ` Samuel Thibault 0 siblings, 1 reply; 13+ messages in thread From: Ludovic Courtès @ 2022-10-06 13:14 UTC (permalink / raw) To: 58320; +Cc: bug-hurd Hi! As suggested by Samuel on IRC, I did that early on in kdb: debug traps /on such that it would stop on each trap, hopefully allowing me to see why exec is not starting. --8<---------------cut here---------------start------------->8--- module 0: ext2fs --multiboot-command-line=${kernel-command-line} --host-priv-por t=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-tas k} --store-type=typed --x-xattr-translator-records ${root} $(task-create) $(task -resume) module 1: exec /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167/hu rd/exec $(exec-task=task-create) 2 multiboot modules task loaded: ext2fs --multiboot-command-line=root=device:hd0s1 root=3367134b-cfb d-1e90-2f38-dfd13367134b gnu.system=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn- system gnu.load=/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-system/boot --host-p riv-port=1 --device-master-port=2 --exec-server-task=3 --store-type=typed --x-xa ttr-translator-records device:hd0s1 task loaded: exec /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a5167 /hurd/exec start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] execkernel: Page fault (14), code=6 Stopped at 0x1000: pushl 0x4(%ebx) >>>>> user space <<<<< 0x1000(bfffff24,0,0,1160b,0) 0x11627(bfffff9c,0,0,0,2) 0x11bb() 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..... --8<---------------cut here---------------end--------------->8--- Then lots of page faults with the same stack trace, seemingly endlessly: --8<---------------cut here---------------start------------->8--- db> c kernel: Page fault (14), code=6 Stopped at 0x1000: pushl 0x4(%ebx) >>>>> user space <<<<< 0x1000(bfffff24,0,0,1160b,0) 0x11627(bfffff9c,0,0,0,2) 0x11bb() --8<---------------cut here---------------end--------------->8--- When I “debug traps /off” and continue, the startup process hangs as normal, and at that point ‘show all threads’ no longer shows exec. On a “working” VM, with traps enabled early on in the same way, I don’t see any page fault until after exec, proc, auth, etc. have been started. Thoughts? Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-06 13:14 ` Ludovic Courtès @ 2022-10-06 13:53 ` Samuel Thibault 2022-10-06 22:10 ` Ludovic Courtès 0 siblings, 1 reply; 13+ messages in thread From: Samuel Thibault @ 2022-10-06 13:53 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-hurd, 58320 Ludovic Courtès, le jeu. 06 oct. 2022 15:14:13 +0200, a ecrit: > such that it would stop on each trap, hopefully allowing me to see why > exec is not starting. Also, better use exec.static to have static addresses. We use the dynamic version of exec "just because we can", but that makes debugging difficult. Samuel ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-06 13:53 ` Samuel Thibault @ 2022-10-06 22:10 ` Ludovic Courtès 2022-10-06 22:42 ` Samuel Thibault 2022-10-23 13:58 ` Ludovic Courtès 0 siblings, 2 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-10-06 22:10 UTC (permalink / raw) To: 58320; +Cc: bug-hurd Samuel Thibault <samuel.thibault@gnu.org> skribis: > Ludovic Courtès, le jeu. 06 oct. 2022 15:14:13 +0200, a ecrit: >> such that it would stop on each trap, hopefully allowing me to see why >> exec is not starting. > > Also, better use exec.static to have static addresses. Thanks for the hint. Of course, the thing boots just fine on that machine when using ‘exec.static’. So the issue might be somewhere in ld.so, or triggered by ld.so. Any debugging tricks here? Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-06 22:10 ` Ludovic Courtès @ 2022-10-06 22:42 ` Samuel Thibault 2022-10-07 8:24 ` Ludovic Courtès 2022-10-23 13:58 ` Ludovic Courtès 1 sibling, 1 reply; 13+ messages in thread From: Samuel Thibault @ 2022-10-06 22:42 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-hurd, 58320 Ludovic Courtès, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit: > Samuel Thibault <samuel.thibault@gnu.org> skribis: > > > Ludovic Courtès, le jeu. 06 oct. 2022 15:14:13 +0200, a ecrit: > >> such that it would stop on each trap, hopefully allowing me to see why > >> exec is not starting. > > > > Also, better use exec.static to have static addresses. > > Thanks for the hint. > > Of course, the thing boots just fine on that machine when using > ‘exec.static’. Uh. At least you have a workaround :) > So the issue might be somewhere in ld.so, or triggered by ld.so. > Any debugging tricks here? maybe for a start check with show map $map2 what is actually mapped, whether it's just ld.so, or also exec, etc. Perhaps you can also try to run other programs than exec, like small dumb programs. Samuel ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-06 22:42 ` Samuel Thibault @ 2022-10-07 8:24 ` Ludovic Courtès 2022-10-07 21:16 ` Samuel Thibault 2022-10-17 12:51 ` Ludovic Courtès 0 siblings, 2 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-10-07 8:24 UTC (permalink / raw) To: 58320; +Cc: bug-hurd Hi! Samuel Thibault <samuel.thibault@gnu.org> skribis: > Ludovic Courtès, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit: [...] >> Of course, the thing boots just fine on that machine when using >> ‘exec.static’. > > Uh. At least you have a workaround :) Yup. :-) >> So the issue might be somewhere in ld.so, or triggered by ld.so. >> Any debugging tricks here? > > maybe for a start check with > > show map $map2 > > what is actually mapped, whether it's just ld.so, or also exec, etc. On the first trap (page fault) I see: --8<---------------cut here---------------start------------->8--- db> show all tasks ID TASK NAME [THREADS] 0 f5f7cf00 gnumach [7] 1 f5f7ce40 ext2fs [6] 2 f5f7cd80 exec [1] 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 map entry 0xf625eb58: start=0x26000, end=0x34000 prot=1/7/copy, object=0xf5f6ad20, offset=0x0 Object 0xf5f6ad20: size=0xe000, 1 references 14 resident pages, 0 absent pages, 0 paging ops memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82730 uninitialized,temporary internal,copy_strategy=0 shadow=0x0 (offset=0x0),copy=0x0 map entry 0xf625eb00: start=0x34000, end=0x37000 prot=3/7/copy, object=0xf5f6acd0, offset=0x0 Object 0xf5f6acd0: size=0x3000, 1 references 3 resident pages, 0 absent pages, 0 paging ops memory object=0x0 (offset=0x0),control=0x0, name=0xf5f826e0 uninitialized,temporary internal,copy_strategy=0 shadow=0x0 (offset=0x0),copy=0x0 map entry 0xf625eaa8: start=0xbfff0000, end=0xc0000000 prot=3/7/copy, object=0xf5f6ac80, offset=0x0 Object 0xf5f6ac80: size=0x10000, 1 references 16 resident pages, 0 absent pages, 0 paging ops memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82690 uninitialized,temporary internal,copy_strategy=0 shadow=0x0 (offset=0x0),copy=0x0 --8<---------------cut here---------------end--------------->8--- The mappings appear to match the PT_LOAD sections of ld.so: --8<---------------cut here---------------start------------->8--- $ objdump -x /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1|head -16 /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1: file format elf32-i386 /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1 architecture: i386, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x000011b0 Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x00000dd8 memsz 0x00000dd8 flags r-- 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- --8<---------------cut here---------------end--------------->8--- … so ‘exec_load’ is doing its job, it seems. I also tried to set up a breakpoint on ‘task_terminate’ to see what’s going on when the exec task vanishes: --8<---------------cut here---------------start------------->8--- module 0: ext2fs --multiboot-command-line=${kernel-command-line} --host-priv-por t=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-tas k} --store-type=typed --x-xattr-translator-records ${root} $(task-create) $(task -resume) module 1: exec /gnu/store/0na7ic689glydngxyb7pazjixz9b6629-hurd-0.9-1.91a5167/hu rd/exec $(exec-task=task-create) 2 multiboot modules task loaded: ext2fs --multiboot-command-line=root=device:hd0s1 root=3367134b-cf6 6-e06b-ee4b-4b933367134b gnu.system=/gnu/store/g7kssjfrxqjpbr6r31idiasgglfph2y5- system gnu.load=/gnu/store/g7kssjfrxqjpbr6r31idiasgglfph2y5-system/boot --host-p riv-port=1 --device-master-port=2 --exec-server-task=3 --store-type=typed --x-xa ttr-translator-records device:hd0s1 task loaded: exec /gnu/store/0na7ic689glydngxyb7pazjixz9b6629-hurd-0.9-1.91a5167 /hurd/exec start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] execKernel Breakpoint 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? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-07 8:24 ` Ludovic Courtès @ 2022-10-07 21:16 ` Samuel Thibault 2022-10-08 15:52 ` Ludovic Courtès 2022-10-17 12:51 ` Ludovic Courtès 1 sibling, 1 reply; 13+ messages in thread From: Samuel Thibault @ 2022-10-07 21:16 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-hurd, 58320 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-07 21:16 ` Samuel Thibault @ 2022-10-08 15:52 ` Ludovic Courtès 2022-10-09 16:09 ` Ludovic Courtès 0 siblings, 1 reply; 13+ messages in thread From: Ludovic Courtès @ 2022-10-08 15:52 UTC (permalink / raw) To: 58320; +Cc: bug-hurd Hi Samuel, Samuel Thibault <samuel.thibault@gnu.org> skribis: > 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? Sure: --8<---------------cut here---------------start------------->8--- $ addr2line -e /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1 0x1000 0x11627 0x11bb ??:0 /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/glibc-2.33/elf/dl-misc.c:333 :? --8<---------------cut here---------------end--------------->8--- That’s ‘_dl_fatal_printf’ calling ‘_exit’; it’s trying to tell us something. I’ll try and rebuild the system with the debugging patches at <https://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00038.html>, to get early ld.so output, for lack of a better solution… >> 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. Address 0 is for the ‘_begin’ symbol, passed by -Wl,-defsym: --8<---------------cut here---------------start------------->8--- i586-pc-gnu-gcc -nostdlib -nostartfiles -r -o /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/librtld.os '-Wl,-(' /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/dl-allobjs.os /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/rtld-libc.a -lgcc '-Wl,-)' \ -Wl,-Map,/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/librtld.os.map i586-pc-gnu-gcc -nostdlib -nostartfiles -shared -o /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so.new \ -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs \ /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/librtld.os -Wl,--version-script=/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/ld.map \ -Wl,-soname=ld.so.1 \ -Wl,-defsym=_begin=0 i586-pc-gnu-readelf -s /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so.new \ | gawk '($7 ~ /^UND(|EF)$/ && $1 != "0:" && $4 != "REGISTER") { print; p=1 } END { exit p != 0 }' mv -f /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so.new /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so --8<---------------cut here---------------end--------------->8--- And indeed: --8<---------------cut here---------------start------------->8--- $ objdump -t /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1|grep _begin 00000000 l *ABS* 00000000 _begin --8<---------------cut here---------------end--------------->8--- That ‘-Wl,-defsym=_begin=0’ flag was removed in glibc commit 6f043e0ee7e477f50a44024ed0cb579d5e3f511d (April 2022). On darnassus it’s different but then it’s Debian’s glibc 2.35, natively built, so I don’t what conclusions can be drawn: --8<---------------cut here---------------start------------->8--- ludo@darnassus:~$ /lib/ld.so.1 --version ld.so (Debian GLIBC 2.35-1) stable release version 2.35. Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ludo@darnassus:~$ objdump -x /lib/ld.so.1 |head -40 /lib/ld.so.1: file format elf32-i386 /lib/ld.so.1 architecture: i386, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x0001cc40 Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x00038494 memsz 0x00038494 flags r-x LOAD off 0x00038c00 vaddr 0x00039c00 paddr 0x00039c00 align 2**12 filesz 0x00001ca8 memsz 0x00001e34 flags rw- DYNAMIC off 0x00039f24 vaddr 0x0003af24 paddr 0x0003af24 align 2**2 filesz 0x000000b8 memsz 0x000000b8 flags rw- NOTE off 0x00000114 vaddr 0x00000114 paddr 0x00000114 align 2**2 filesz 0x00000024 memsz 0x00000024 flags r-- --8<---------------cut here---------------end--------------->8--- Thanks for your feedback! Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-08 15:52 ` Ludovic Courtès @ 2022-10-09 16:09 ` Ludovic Courtès 2022-10-09 19:09 ` Samuel Thibault 2022-10-10 21:14 ` Ludovic Courtès 0 siblings, 2 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-10-09 16:09 UTC (permalink / raw) To: 58320; +Cc: bug-hurd Hi! Ludovic Courtès <ludo@gnu.org> skribis: > $ addr2line -e /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1 0x1000 0x11627 0x11bb > ??:0 > /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/glibc-2.33/elf/dl-misc.c:333 > :? > > > That’s ‘_dl_fatal_printf’ calling ‘_exit’; it’s trying to tell us > something. > > I’ll try and rebuild the system with the debugging patches at > <https://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00038.html>, to > get early ld.so output, for lack of a better solution… I tried adapted the patches above and tried them, but it seems that ‘_dl_sysdep_start’ isn’t even reached. For example, I set a breakpoint on ‘mach_task_self’ (called from ‘__mach_init’, called from ‘_dl_sysdep_start’), but that’s never reached (I’m assuming ‘break/tu’ is reliable, is it?). The user-space backtrace upon trap remains unhelpful: --8<---------------cut here---------------start------------->8--- start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1]Kernel Breakpoint trap, eip 0xc1030d5b Breakpoint at task_resume: pushl %ebp db> debug traps /on db> b task_terminate set breakpoint #2 db> c Kernel Debug trap trap, eip 0xc1030d5b execkernel: Page fault (14), code=6 Stopped at 0x1000: pushl 0x4(%ebx) >>>>> user space <<<<< 0x1000(bfffff24,0,0,1160b,0) 0x11627(bfffff9c,0,0,0,2) 0x11bb() --8<---------------cut here---------------end--------------->8--- … where: --8<---------------cut here---------------start------------->8--- $ addr2line -e /gnu/store/4p1kab1c4h7h3kvgcm1hbjja4y5k9x4p-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1 0x11627 0x11bb /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/glibc-2.33/elf/dl-misc.c:333 :? $ objdump -S /gnu/store/4p1kab1c4h7h3kvgcm1hbjja4y5k9x4p-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1 --start-address=0x000011b0 |head -40 /gnu/store/4p1kab1c4h7h3kvgcm1hbjja4y5k9x4p-glibc-cross-i586-pc-gnu-2.33/lib/ld.so.1: file format elf32-i386 Disassembly of section .text: 000011b0 <_start>: 11b0: 89 e0 mov %esp,%eax 11b2: 83 ec 0c sub $0xc,%esp 11b5: 50 push %eax 11b6: e8 b5 0a 00 00 call 1c70 <_dl_start> 11bb: 83 c4 10 add $0x10,%esp --8<---------------cut here---------------end--------------->8--- So it would seem that ‘_dl_start’ is called and somehow then a tail-call to ‘_dl_fatal_printf’ is made. Through a dichotomy I tried to see how far it goes. The info I have so far is that ld.so errors out from elf/rtld.c:563 (line 565 is not reached): --8<---------------cut here---------------start------------->8--- 558: if (bootstrap_map.l_addr || ! bootstrap_map.l_info[VALIDX(DT_GNU_PRELINKED)]) 559: { 560: /* Relocate ourselves so we can do normal function calls and 561: data access using the global offset table. */ 562: 563: ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0, 0); 564: } 565: bootstrap_map.l_relocated = 1; ... 578: __rtld_malloc_init_stubs (); --8<---------------cut here---------------end--------------->8--- It’s hard to be more precise because ELF_DYNAMIC_RELOCATE is a macro that expands to quite a lot of code. I don’t see the code path that would lead to a ‘_dl_fatal_printf’ call though. Ideas? :-) Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-09 16:09 ` Ludovic Courtès @ 2022-10-09 19:09 ` Samuel Thibault 2022-10-10 21:14 ` Ludovic Courtès 1 sibling, 0 replies; 13+ messages in thread From: Samuel Thibault @ 2022-10-09 19:09 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-hurd, 58320 Ludovic Courtès, le dim. 09 oct. 2022 18:09:07 +0200, a ecrit: > So it would seem that ‘_dl_start’ is called and somehow then a tail-call > to ‘_dl_fatal_printf’ is made. Perhaps you can build glibc without tail-call optimization? (-fno-optimize-sibling-calls) Samuel ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-09 16:09 ` Ludovic Courtès 2022-10-09 19:09 ` Samuel Thibault @ 2022-10-10 21:14 ` Ludovic Courtès 1 sibling, 0 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-10-10 21:14 UTC (permalink / raw) To: 58320; +Cc: bug-hurd Ludovic Courtès <ludo@gnu.org> skribis: > Through a dichotomy I tried to see how far it goes. The info I have so > far is that ld.so errors out from elf/rtld.c:563 (line 565 is not > reached): > > 558: if (bootstrap_map.l_addr || ! bootstrap_map.l_info[VALIDX(DT_GNU_PRELINKED)]) > 559: { > 560: /* Relocate ourselves so we can do normal function calls and > 561: data access using the global offset table. */ > 562: > 563: ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0, 0); > 564: } > 565: bootstrap_map.l_relocated = 1; > ... > 578: __rtld_malloc_init_stubs (); Via brute force¹, I found that ‘__assert_fail’ is hit, with its first argument in $eax being: --8<---------------cut here---------------start------------->8--- db> x/c 0x28604,80 ELF32_R_TYPE (reloc->r_info) == R_386_RELATIVE\000\000map->l_in fo[VERSYMIDX (DT_VERSYM)] != NULL\000\000Fatal glibc error: Too many audit mo --8<---------------cut here---------------end--------------->8--- This comes from i386/dl-machine.h: --8<---------------cut here---------------start------------->8--- auto inline void __attribute ((always_inline)) elf_machine_rel_relative (Elf32_Addr l_addr, const Elf32_Rel *reloc, void *const reloc_addr_arg) { Elf32_Addr *const reloc_addr = reloc_addr_arg; assert (ELF32_R_TYPE (reloc->r_info) == R_386_RELATIVE); *reloc_addr += l_addr; } --8<---------------cut here---------------end--------------->8--- How can we get there? Looking at ‘_dl_start’, it could be that ‘elf_machine_load_address’ returns a bogus value and we end up reading wrong ELF data? Or it could be memory corruption somewhere. Or…? Thing is, it’s not fully deterministic (happens 9 times out of 10 with KVM, never happens without KVM). Ideas? :-) Ludo’. ¹ Building with ‘-fno-optimize-sibling-calls’ didn’t help get nicer backtraces, but that’s prolly because all that early relocation code is inlined. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-07 8:24 ` Ludovic Courtès 2022-10-07 21:16 ` Samuel Thibault @ 2022-10-17 12:51 ` Ludovic Courtès 1 sibling, 0 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-10-17 12:51 UTC (permalink / raw) To: 58320; +Cc: bug-hurd Hi, Ludovic Courtès <ludo@gnu.org> skribis: > … so ‘exec_load’ is doing its job, it seems. Turns out that may not be the case. Here’s a *bad* mapping on the second ‘task_resume’ breakpoint (when ‘exec’ is about to start): --8<---------------cut here---------------start------------->8--- 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) R....F 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 (f67d3e20) .W.O..(mach_msg_receive_continue) 0 5 (f67d3cd8) .W.O..(mach_msg_continue) 0 2 exec (f5f7cd80): (f5f7b3d8) ..SO..(thread_bootstrap_return) db> trace task_resume(f593e010,fb7d9010,f5f73e80,c106972a) ipc_kobject_server(f593e000,3,18,0)+0x1eb mach_msg_trap(bffff4c0,3,18,20,8)+0x1703 >>>>> user space <<<<< db> x/tbx 0xcbc 0xf5f7b3d8 no memory is assigned to address 00000cbc 0 db> show map $map2 Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5 size=290816,resident:225280,wired=0 version=13 map entry 0xf625ec08: start=0x0, end=0x1000 prot=1/7/copy, object=0x0, offset=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 map entry 0xf625eb58: start=0x26000, end=0x34000 prot=1/7/copy, object=0xf5f6ad20, offset=0x0 Object 0xf5f6ad20: size=0xe000, 1 references 14 resident pages, 0 absent pages, 0 paging ops memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82730 uninitialized,temporary internal,copy_strategy=0 shadow=0x0 (offset=0x0),copy=0x0 map entry 0xf625eb00: start=0x34000, end=0x37000 prot=3/7/copy, object=0xf5f6acd0, offset=0x0 Object 0xf5f6acd0: size=0x3000, 1 references 3 resident pages,--db_more-- --8<---------------cut here---------------end--------------->8--- Compare with what a “good” mapping looks like at that same moment: --8<---------------cut here---------------start------------->8--- start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1]Kernel Breakpoint trap, eip 0xc1030d5b Breakpoint at task_resume: 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) R....F 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 (f67d2e20) .W.O..(mach_msg_receive_continue) 0 5 (f67d2cd8) .W.O..(mach_msg_continue) 0 2 exec (f5f7cd80): (f5f7b3d8) ..SO..(thread_bootstrap_return) db> x/tbx 0xcbc 0xf5f7b3d8 8 db> show map $map2 Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5 size=290816,resident:229376,wired=0 version=14 map entry 0xf625ec08: start=0x0, end=0x1000 prot=1/7/copy, object=0xf5f6ad70, offset=0x0 Object 0xf5f6ad70: size=0x1000, 1 references 1 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 map entry 0xf625ebb0: start=0x1000, end=0x26000 prot=5/7/copy, object=0xf5f6ad20, offset=0x0 Object 0xf5f6ad20: size=0x25000, 1 references 37 resident pages, 0 absent pages, 0 paging ops memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82730 uninitialized,temporary internal,copy_strategy=0 shadow=0x0 (offset=0x0),copy=0x0 map entry 0xf625eb58: start=0x26000, end=0x34000 prot=1/7/copy, object=0xf5f6acd0, offset=0x0 Object 0xf5f6acd0: size=0xe000, 1 references 14 resident pages, 0 absent pages, 0 paging ops memory object=0x0 (offset=0x0),control=0x0, name=0xf5f826e0 uninitialized,temporary internal,copy_strategy=0 shadow=0x0 (offset=0x0),copy=0x0 map entry 0xf625eb00: start=0x34000, end=0x37000 prot=3/7/copy, object=0xf5f6ac80, offset=0x0 Object 0xf5f6ac80: size=0x3000, 1 references 3 resident pages, 0 absent pages, 0 paging ops memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82690 uninitialized,temporary internal,copy_strategy=0 shadow=0x0 (offset=0x0),copy=0x0 map entry 0xf625eaa8: start=0xbfff0000, end=0xc0000000 prot=3/7/copy, object=0xf5f6ac30, offset=0x0 Object 0xf5f6ac30: size=0x10000, 1 references 1 resident pages, 0 absent pages, 0 paging ops memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82640 uninitialized,temporary internal,copy_strategy=0 shadow=0x0 (offset=0x0),copy=0x0 --8<---------------cut here---------------end--------------->8--- Notice that 0xcbc reads a valid relocation, where 8 = R_386_RELATIVE. In the “bad” case, the first map entry is empty, with no associated memory object and zero resident pages. My reading of ‘read_exec’ is that the page is supposed to be populated eagerly by the ‘copyout’ call here: --8<---------------cut here---------------start------------->8--- static int read_exec(void *handle, vm_offset_t file_ofs, vm_size_t file_size, vm_offset_t mem_addr, vm_size_t mem_size, exec_sectype_t sec_type) { struct multiboot_module *mod = handle; [...] err = vm_allocate(user_map, &start_page, end_page - start_page, FALSE); assert(err == 0); assert(start_page == trunc_page(mem_addr)); if (file_size > 0) { err = copyout((char *)phystokv (mod->mod_start) + file_ofs, (void *)mem_addr, file_size); assert(err == 0); } [...] return 0; } --8<---------------cut here---------------end--------------->8--- There are interesting tricks in ‘copyout_retry’ to fake a page fault so the copy can actually be made, IIUC. Could it be that this bit isn’t quite working? Ideas? Problem with debugging this is that setting a breakpoint on ‘exec_load’ causes the system to boot fine (breaking on ‘task_resume’ is fine tough, go figure…). Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) 2022-10-06 22:10 ` Ludovic Courtès 2022-10-06 22:42 ` Samuel Thibault @ 2022-10-23 13:58 ` Ludovic Courtès 1 sibling, 0 replies; 13+ messages in thread From: Ludovic Courtès @ 2022-10-23 13:58 UTC (permalink / raw) To: 58320; +Cc: bug-hurd Hi, Ludovic Courtès <ludo@gnu.org> skribis: > Of course, the thing boots just fine on that machine when using > ‘exec.static’. It’s frustrating I did not get to the bottom of it, but time passes, so I pushed this workaround in Guix commit 3fb3bd3da530a5f82a169b1fa451474f9d90c3b6. Ludo’. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-10-24 3:44 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-05 21:01 bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) Ludovic Courtès 2022-10-06 13:14 ` Ludovic Courtès 2022-10-06 13:53 ` Samuel Thibault 2022-10-06 22:10 ` Ludovic Courtès 2022-10-06 22:42 ` Samuel Thibault 2022-10-07 8:24 ` Ludovic Courtès 2022-10-07 21:16 ` Samuel Thibault 2022-10-08 15:52 ` Ludovic Courtès 2022-10-09 16:09 ` Ludovic Courtès 2022-10-09 19:09 ` Samuel Thibault 2022-10-10 21:14 ` Ludovic Courtès 2022-10-17 12:51 ` Ludovic Courtès 2022-10-23 13:58 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).