From unknown Mon Jun 23 07:46:41 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#58320 <58320@debbugs.gnu.org> To: bug#58320 <58320@debbugs.gnu.org> Subject: Status: Hurd VM fails to boot on AMD EPYC (kvm-amd) Reply-To: bug#58320 <58320@debbugs.gnu.org> Date: Mon, 23 Jun 2025 14:46:41 +0000 retitle 58320 Hurd VM fails to boot on AMD EPYC (kvm-amd) reassign 58320 guix submitter 58320 Ludovic Court=C3=A8s severity 58320 normal tag 58320 wontfix thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 17:01:54 2022 Received: (at submit) by debbugs.gnu.org; 5 Oct 2022 21:01:54 +0000 Received: from localhost ([127.0.0.1]:58210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogBWc-0003mw-0z for submit@debbugs.gnu.org; Wed, 05 Oct 2022 17:01:54 -0400 Received: from lists.gnu.org ([209.51.188.17]:39858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogBWY-0003mn-8x for submit@debbugs.gnu.org; Wed, 05 Oct 2022 17:01:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38456) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogBWQ-0000xX-KB for bug-guix@gnu.org; Wed, 05 Oct 2022 17:01:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34932) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogBWQ-000057-AB for bug-guix@gnu.org; Wed, 05 Oct 2022 17:01:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:Subject:To:From:in-reply-to: references; bh=biJClVqk7ve9Jd2LsRo6jFR9ZTxGojQSSilaa4f9olI=; b=FHbLvHN2V0QBNf GPQdtPxZWs1IUgss+0qyR6CeE4392PfXHjFQyUcExy6tRLJiYYh0HqaBH9xAWdt4KjIh/BPzspdw+ UnJ85bjKvS21iPvZvrpYooKNG2Kg76HHbtZp/HnADWidr6WnywZ31pu+A2uGd4HDy/Lm3rG9McWVv rxwSXfY+2Vk08sxt8i1CvhH8zvlpb6+B8bgBbWYQDUWQJVsmpQk2Sp5lUJ5SjsgqHeAXPpNuFQ9Re 5uAda6BX5VABF9oHSRebuF0Edr0GpO4tcVZAt6crei3avO/nZPjiQxYVdQSoHL0a3rX5npe12U9f+ eiXiyHyV50hpRogA5FtQ==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:63151 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogBWP-0002ys-Sq for bug-guix@gnu.org; Wed, 05 Oct 2022 17:01:42 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: bug-guix@gnu.org Subject: Hurd VM fails to boot on AMD EPYC (kvm-amd) X-Debbugs-Cc: bug-hurd@gnu.org X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Quartidi 14 =?utf-8?Q?Vend=C3=A9miaire?= an 231 de la =?utf-8?Q?R=C3=A9volution=2C?= jour du =?utf-8?B?UsOpc8OpZGE=?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Wed, 05 Oct 2022 23:01:39 +0200 Message-ID: <87k05eouh8.fsf@inria.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello! On AMD EPYC processors, as found on the build nodes of ci.guix.gnu.org, childhurd VMs fail to boot when running with =E2=80=98qemu-system-i386 -enable-kvm=E2=80=99 (the kvm-amd Linux kernel module is used), with the Hu= rd startup process hanging before /hurd/exec has been started: --8<---------------cut here---------------start------------->8--- module 0: ext2fs --multiboot-command-line=3D${kernel-command-line} --host-p= riv-por=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 t=3D${host-port} --device-master-port=3D${device-port} --exec-server-task= =3D${exec-tas=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 k} --store-type=3Dtyped --x-xattr-translator-records ${root} $(task-create)= $(task=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 -resume)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 module 1: exec /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a51= 67/hu=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 rd/exec $(exec-task=3Dtask-create)=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 2 multiboot modules=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 task loaded: ext2fs --multiboot-command-line=3Droot=3Ddevice:hd0s1 root=3D3= 367134b-cfb=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 d-1e90-2f38-dfd13367134b gnu.system=3D/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk= 23lybn-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 system gnu.load=3D/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-system/boot -= -host-p=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 riv-port=3D1 --device-master-port=3D2 --exec-server-task=3D3 --store-type= =3Dtyped --x-xa=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ttr-translator-records device:hd0s1=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 task loaded: exec /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91= a5167=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 /hurd/exec=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 --8<---------------cut here---------------end--------------->8--- Kdb shows these two tasks: --8<---------------cut here---------------start------------->8--- Stopped at mach=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 ine_idle+0x26: nop=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 machine_idle(0,c102f380,f5f7bcd0,c102e3fa)+0x26=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 idle_thread_continue(f5f7ade0,36366000,f5f73868,f5f73890,0)+0x73=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 >>>>> user space <<<<<=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 db> show all threads=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 TASK THREADS=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 0 gnumach (f5f7cf00): 7 threads:=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 0 (f5f7be18) .W..N. 0xc11dac04=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1 (f5f7bcd0) R.....=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 1 ext2fs (f5f7ce40): 6 threads:=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 0 (f5f7b520) .W.O.F(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 1 (f5f7b290) .W.O.F(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 3 (f5f7b000) .W.O..(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 4 (f67d3e20) .W.O..(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 5 (f67d3cd8) .W.O..(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 db> trace/t 0xf5f7b520=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 Continuation mach_msg_continue=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 >>>>> user space <<<<<=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 0x80ccaec()=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --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.91a51= 67/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=E2=80=99t tell us much. The same image boots fine on the same CPU without =E2=80=98-enable-kvm=E2= =80=99. However, keeping =E2=80=98-enable-kvm=E2=80=99 and adding =E2=80=98--cpu pe= ntium=E2=80=99 and other variants of this option don=E2=80=99t 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=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 09:14:35 2022 Received: (at 58320) by debbugs.gnu.org; 6 Oct 2022 13:14:35 +0000 Received: from localhost ([127.0.0.1]:59397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogQhn-0006lW-LY for submit@debbugs.gnu.org; Thu, 06 Oct 2022 09:14:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48086) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogQhj-0006lH-Jw for 58320@debbugs.gnu.org; Thu, 06 Oct 2022 09:14:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54546) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogQhe-0001Gt-9U; Thu, 06 Oct 2022 09:14:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=JcSi9B+p0jNuMZHCyA094WD2IArM7r50u0S0J0bS2tM=; b=KcNr7Hag1mzh+NArolqv Fj+eEohDANQ1mT2/Cfbx9+w37EQl68hLRHOoU6ULf/1U/KiEwx20QUe9MrTqlzS698j2bnG6hUUJj MiNuN/+mcJFoQLpuHJvKnqaCWxOwCMPIrwO+3vR5EqcOHeL/NH2XLFKaN3j70cuclzlSFRvycGjC2 iDWVGLhNvXum0i00/SNYW3uw81WL1CI9F6xFBCMUfDdtd/VSrGP6l2NXZq8ci5c71m1HP+NORigmj GYvejVPAV9wjBx8feWiHdivcyXPooiD+hXjNLG2vvS63uELndp2uOrjNkwOfmR3zPuBqMGlcYjEiJ BKWY+VQsEDS0oQ==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:55577 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogQhc-00031F-5B; Thu, 06 Oct 2022 09:14:18 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 58320@debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) References: <87k05eouh8.fsf@inria.fr> Date: Thu, 06 Oct 2022 15:14:13 +0200 In-Reply-To: <87k05eouh8.fsf@inria.fr> ("Ludovic =?utf-8?Q?Court=C3=A8s=22?= =?utf-8?Q?'s?= message of "Wed, 05 Oct 2022 23:01:39 +0200") Message-ID: <8735c1nlga.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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=3D${kernel-command-line} --host-p= riv-por=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 t=3D${host-port} --device-master-port=3D${device-port} --exec-server-task= =3D${exec-tas=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 k} --store-type=3Dtyped --x-xattr-translator-records ${root} $(task-create)= $(task=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 -resume)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 module 1: exec /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91a51= 67/hu=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 rd/exec $(exec-task=3Dtask-create)=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 2 multiboot modules=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 task loaded: ext2fs --multiboot-command-line=3Droot=3Ddevice:hd0s1 root=3D3= 367134b-cfb=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 d-1e90-2f38-dfd13367134b gnu.system=3D/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk= 23lybn-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 system gnu.load=3D/gnu/store/m66ccpdzdbcd3k2fdvyaj8cgmk23lybn-system/boot -= -host-p=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 riv-port=3D1 --device-master-port=3D2 --exec-server-task=3D3 --store-type= =3Dtyped --x-xa=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ttr-translator-records device:hd0s1=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 task loaded: exec /gnu/store/99sqiayswrxxb80331pl7jxin18wv28b-hurd-0.9-1.91= a5167=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 /hurd/exec=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] execkernel: Page = fault=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 (14), code=3D6=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Stopped at 0x1000: pushl 0x4(%ebx)=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >>>>> user space <<<<<=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 0x1000(bfffff24,0,0,1160b,0)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 0x11627(bfffff9c,0,0,0,2)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 0x11bb()=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 db> show all threads=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 TASK THREADS=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 0 gnumach (f5f7cf00): 7 threads:=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 0 (f5f7be18) .W..N. 0xc11dac04=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1 (f5f7bcd0) R..O..(idle_thread_continue)=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 1 ext2fs (f5f7ce40): 6 threads:=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 0 (f5f7b520) .W.O.F(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 1 (f5f7b290) .W.O..(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 3 (f5f7b000) .W.O..(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 4 (f67d4e20) .W.O..(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 5 (f67d4cd8) .W.O..(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 2 exec (f5f7cd80): (f5f7b3d8) R.....=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --8<---------------cut here---------------end--------------->8--- Then lots of page faults with the same stack trace, seemingly endlessly: --8<---------------cut here---------------start------------->8--- db> c=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 kernel: Page fault (14), code=3D6=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 Stopped at 0x1000: pushl 0x4(%ebx)=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >>>>> user space <<<<<=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 0x1000(bfffff24,0,0,1160b,0)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 0x11627(bfffff9c,0,0,0,2)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 0x11bb()=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --8<---------------cut here---------------end--------------->8--- When I =E2=80=9Cdebug traps /off=E2=80=9D and continue, the startup process= hangs as normal, and at that point =E2=80=98show all threads=E2=80=99 no longer show= s exec. On a =E2=80=9Cworking=E2=80=9D VM, with traps enabled early on in the same = way, I don=E2=80=99t see any page fault until after exec, proc, auth, etc. have been started. Thoughts? Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 09:53:30 2022 Received: (at 58320) by debbugs.gnu.org; 6 Oct 2022 13:53:30 +0000 Received: from localhost ([127.0.0.1]:59462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogRJa-0001cE-2Y for submit@debbugs.gnu.org; Thu, 06 Oct 2022 09:53:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogRJV-0001bw-6m for 58320@debbugs.gnu.org; Thu, 06 Oct 2022 09:53:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57282) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogRJP-00005D-V1; Thu, 06 Oct 2022 09:53:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=oW144penIvGnY296ewMzqqMLl5i+oIqWSm8oILxwEBE=; b=HCL2xdlQQyup5jqrv9m7 52kf9FgXVhLz5Nms4omIs4GqApYA0/kXCkZrOPlLDmUQSXZERgyNmuz9ycgnP+/hLeOam//LqU+b/ FZrwz4S1Xm4bsLJTkUYKvD+jNPuloLEgHwc4TM00XiMrBh7bwy4RPPWYLP//B3PjchhY0b1JmnLgW //G9DGoveFoS5vaZhUYm0T/vhaAxDrY33xBSvCnBsMAOfyzLM2vgAwvcbI0wMt2KrfFjBXbN7TGMA 92xhVRzrv3vxFSfGsniWj9SgXoujQH2mpkOvcPajOpx6B09Vpen35Q5H1Oi9jYgkpobYujlqoP0K5 fvfr6y0i+9OJlg==; Received: from nat-inria-interne-52-gw-01-bso.bordeaux.inria.fr ([194.199.1.52]:50864 helo=begin) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogRJP-0004eX-Ns; Thu, 06 Oct 2022 09:53:19 -0400 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1ogRJM-007PKU-0x; Thu, 06 Oct 2022 15:53:16 +0200 Date: Thu, 6 Oct 2022 15:53:16 +0200 From: Samuel Thibault To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) Message-ID: <20221006135316.ijevz5ddnet4aqkr@begin> Mail-Followup-To: Ludovic =?utf-8?Q?Court=C3=A8s?= , 58320@debbugs.gnu.org, bug-hurd@gnu.org References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8735c1nlga.fsf@gnu.org> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org, 58320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 18:10:30 2022 Received: (at 58320) by debbugs.gnu.org; 6 Oct 2022 22:10:31 +0000 Received: from localhost ([127.0.0.1]:33745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogZ4Y-00078L-JE for submit@debbugs.gnu.org; Thu, 06 Oct 2022 18:10:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogZ4U-00077z-2S for 58320@debbugs.gnu.org; Thu, 06 Oct 2022 18:10:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50756) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogZ4O-0003ZJ-Q5; Thu, 06 Oct 2022 18:10:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=Ha7gtDbnfmoUy7LhoeKrXqXgfqtwug1rtPi1t2Rx8Y0=; b=ebzg8hTEoE29XxrAP3Hi nUP4aZuWU/i36VNiuREgEa/bZMCTwJAR1PlsD8Psp5vQB8PU1dtEv3NyiGZyf3gbHLlM5gHodpNfP 4Dwg4MOli85QMYO0ZcT2X1oGIra0Ikbx1FfDcW7MU7vMzIhcZp6kfZLHyJMu0hfgKxz/iDZS6MJ57 9WtLQo0uCch9ekEfwhUoUyKKHMwmOR/7QZs9oD5mI3q1olYYxjZKpiP/punXnYUyscaSX/+t/WlEW lWZ2TBKDDu6wOtYQR00Z3WjF4bxXD2ngn+OMKbVxOYxOoOeqTlsZgxTeixTRVh9iGbdGNisoR1IVd nTH0lMVQkmXLAg==; Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=37162 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogZ4M-0004Bz-Ag; Thu, 06 Oct 2022 18:10:19 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 58320@debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> Date: Fri, 07 Oct 2022 00:10:15 +0200 In-Reply-To: <20221006135316.ijevz5ddnet4aqkr@begin> (Samuel Thibault's message of "Thu, 6 Oct 2022 15:53:16 +0200") Message-ID: <87r0zkfvso.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Samuel Thibault skribis: > Ludovic Court=C3=A8s, 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 =E2=80=98exec.static=E2=80=99. So the issue might be somewhere in ld.so, or triggered by ld.so. Any debugging tricks here? Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 18:42:30 2022 Received: (at 58320) by debbugs.gnu.org; 6 Oct 2022 22:42:30 +0000 Received: from localhost ([127.0.0.1]:33783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogZZV-0007w8-U5 for submit@debbugs.gnu.org; Thu, 06 Oct 2022 18:42:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogZZU-0007vv-9P for 58320@debbugs.gnu.org; Thu, 06 Oct 2022 18:42:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33202) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogZZO-0008M3-UB; Thu, 06 Oct 2022 18:42:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=j0T6tjwKEx8Q7S7Lfb5ADqP+A1xLSUEbjCoxa1RlBag=; b=E1vMdvSZLP5pr4Dd1pIZ Pan6PzMQUEbOY12OHtZcCSQYTWPsyuUSyjxPzPFHM4huWkZ3uekkWH+pLSwEzA6DPbi77Q0eautxz nyFZgufHmneFdzaZHdAwP02/VxitWJnmGxZWD3wmlMXfZue7Qxh2Osisc0rnmlCnPuXfuRSUIIsMu z8XGKDsorjQj/OvrmzvH/zFGIghMGF4G70IaBZWIcnLJJGQhFsh/kaCY3HeVxj4Fk44wy7LTqFiWV 7Gwsd2UHI3SDbtgRDXNWmGuhw2sv5Ga7OoZ8o9V7Z0MobyiPzPwSDhLaX4ryRV36u9W0V98b2fTZJ mRGcaWXrcqFhsA==; Received: from [2a01:cb19:956:1b00:de41:a9ff:fe47:ec49] (port=54324 helo=begin.home) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogZZO-00014n-J6; Thu, 06 Oct 2022 18:42:22 -0400 Received: from samy by begin.home with local (Exim 4.96) (envelope-from ) id 1ogZZL-000b2T-2b; Fri, 07 Oct 2022 00:42:19 +0200 Date: Fri, 7 Oct 2022 00:42:19 +0200 From: Samuel Thibault To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) Message-ID: <20221006224219.mn7zp7lhzxwlyrpx@begin> Mail-Followup-To: Ludovic =?utf-8?Q?Court=C3=A8s?= , 58320@debbugs.gnu.org, bug-hurd@gnu.org References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87r0zkfvso.fsf@gnu.org> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org, 58320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ludovic Courtès, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit: > Samuel Thibault 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 07 04:24:35 2022 Received: (at 58320) by debbugs.gnu.org; 7 Oct 2022 08:24:35 +0000 Received: from localhost ([127.0.0.1]:34271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogieo-0006HD-Qk for submit@debbugs.gnu.org; Fri, 07 Oct 2022 04:24:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogiel-0006H0-RR for 58320@debbugs.gnu.org; Fri, 07 Oct 2022 04:24:33 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44998) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogieg-0007lu-IX; Fri, 07 Oct 2022 04:24:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=Y0bgg2dJ6ZIIUimeFjgjUvWXvX+EpPLtaFvT9XItwyc=; b=HaybqddkqS3nmBSimBGi P+wOwXgu9tGz6hxNpewIxD2qAY1DXhl4o/9DWPeZruVLJ6Ihin38dy/rZsSqSZY+lFgz1JIcrjRek A13aOtjHW67N6NUNC4pwFLRN9dKAPVw+HuKrT9ragYHjMLo8ENXpVXaM+dRbXVUy6Pvy0ej3KNHjO aSILSzgRZsu2EuF/tR8B2Q2e+/LXTZG537gsJzIintVWse9CpxVd7oqLCINIdc2FEb8+Q3z5Hld9p ce8pulGSSh68p3O5LquUlbYNWEmKI0WOKNLyWIxLYqRCxS+flzFxeYTgFHUiQI+fv9cMl94aoDVXx oXjVSzPR/TbLKQ==; Received: from [193.50.110.253] (port=39050 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogief-0006mY-RP; Fri, 07 Oct 2022 04:24:26 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 58320@debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> <20221006224219.mn7zp7lhzxwlyrpx@begin> Date: Fri, 07 Oct 2022 10:24:22 +0200 In-Reply-To: <20221006224219.mn7zp7lhzxwlyrpx@begin> (Samuel Thibault's message of "Fri, 7 Oct 2022 00:42:19 +0200") Message-ID: <8735c0f3d5.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi! Samuel Thibault skribis: > Ludovic Court=C3=A8s, le ven. 07 oct. 2022 00:10:15 +0200, a ecrit: [...] >> Of course, the thing boots just fine on that machine when using >> =E2=80=98exec.static=E2=80=99. > > 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=20 > > 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=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ID TASK NAME [THREADS]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 0 f5f7cf00 gnumach [7]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1 f5f7ce40 ext2fs [6]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2 f5f7cd80 exec [1]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 db> show map $map2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Map 0xf5f6ff30: name=3D"exec", pmap=3D0xf5f71fa8,ref=3D1,nentries=3D5=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 size=3D290816,resident:290816,wired=3D0=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 version=3D14=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 map entry 0xf625ec08: start=3D0x0, end=3D0x1000=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 prot=3D1/7/copy, object=3D0xf5f6a7d0, offset=3D0x0=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 Object 0xf5f6a7d0: size=3D0x1000, 1 references=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 1 resident pages, 0 absent pages, 0 paging ops=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5938968=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 uninitialized,temporary internal,copy_strategy=3D0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 shadow=3D0x0 (offset=3D0x0),copy=3D0x0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 map entry 0xf625ebb0: start=3D0x1000, end=3D0x26000=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 prot=3D5/7/copy, object=3D0xf5f6ad70, offset=3D0x0=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 Object 0xf5f6ad70: size=3D0x25000, 1 references=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 37 resident pages, 0 absent pages, 0 paging ops=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82780=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 uninitialized,temporary internal,copy_strategy=3D0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 shadow=3D0x0 (offset=3D0x0),copy=3D0x0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 map entry 0xf625eb58: start=3D0x26000, end=3D0x34000=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 prot=3D1/7/copy, object=3D0xf5f6ad20, offset=3D0x0=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 Object 0xf5f6ad20: size=3D0xe000, 1 references=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 14 resident pages, 0 absent pages, 0 paging ops=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82730=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 uninitialized,temporary internal,copy_strategy=3D0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 shadow=3D0x0 (offset=3D0x0),copy=3D0x0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 map entry 0xf625eb00: start=3D0x34000, end=3D0x37000=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 prot=3D3/7/copy, object=3D0xf5f6acd0, offset=3D0x0=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 Object 0xf5f6acd0: size=3D0x3000, 1 references=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 3 resident pages, 0 absent pages, 0 paging ops=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f826e0=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 uninitialized,temporary internal,copy_strategy=3D0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 shadow=3D0x0 (offset=3D0x0),copy=3D0x0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 map entry 0xf625eaa8: start=3D0xbfff0000, end=3D0xc0000000=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 prot=3D3/7/copy, object=3D0xf5f6ac80, offset=3D0x0=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 Object 0xf5f6ac80: size=3D0x10000, 1 references=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 16 resident pages, 0 absent pages, 0 paging ops=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82690=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 uninitialized,temporary internal,copy_strategy=3D0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 shadow=3D0x0 (offset=3D0x0),copy=3D0x0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --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/li= b/ld.so.1: file format elf32-i386 /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i586-pc-gnu-2.33/li= b/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--- =E2=80=A6 so =E2=80=98exec_load=E2=80=99 is doing its job, it seems. I also tried to set up a breakpoint on =E2=80=98task_terminate=E2=80=99 to = see what=E2=80=99s going on when the exec task vanishes: --8<---------------cut here---------------start------------->8--- module 0: ext2fs --multiboot-command-line=3D${kernel-command-line} --host-p= riv-por=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 t=3D${host-port} --device-master-port=3D${device-port} --exec-server-task= =3D${exec-tas=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 k} --store-type=3Dtyped --x-xattr-translator-records ${root} $(task-create)= $(task -resu= me)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 module 1: exec /gnu/store/0na7ic689glydngxyb7pazjixz9b6629-hurd-0.9-1.91a51= 67/hu=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 rd/exec $(exec-task=3Dtask-create)=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2 multiboot modules=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 task loaded: ext2fs --multiboot-command-line=3Droot=3Ddevice:hd0s1 root=3D3= 367134b-cf6=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 6-e06b-ee4b-4b933367134b gnu.system=3D/gnu/store/g7kssjfrxqjpbr6r31idiasggl= fph2y5-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 system gnu.load=3D/gnu/store/g7kssjfrxqjpbr6r31idiasgglfph2y5-system/boot -= -host-p=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 riv-port=3D1 --device-master-port=3D2 --exec-server-task=3D3 --store-type= =3Dtyped --x-xa=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 ttr-translator-records device:hd0s1=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 task loaded: exec /gnu/store/0na7ic689glydngxyb7pazjixz9b6629-hurd-0.9-1.91= a5167=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 /hurd/exec=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] execKernel Breakp= oint=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 trap, eip 0xc10305c1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Breakpoint at task_terminate: pushl %ebp=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 db> show all threads=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 TASK THREADS=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 0 gnumach (f5f7cf00): 7 threads:=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 0 (f5f7be18) .W..N. 0xc11dac04=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 1 (f5f7bcd0) R..O..(idle_thread_continue)=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1 ext2fs (f5f7ce40): 6 threads:=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 0 (f5f7b520) .W.O.F(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 1 (f5f7b290) .W.O..(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 3 (f5f7b000) .W.O..(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 4 (f67d4e20) .W.O..(mach_msg_receive_continue) 0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 5 (f67d4cd8) .W.O..(mach_msg_continue) 0=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 2 exec (f5f7cd80): (f5f7b3d8) R.....=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 db> trace/t 0xf5f7b3d8=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 task_terminate(f625eb10,0,f5f7cd80,f5f7b3d8,c11da940)=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 exception_try_task(1,1,bffefffc,ffffffff,c1202b4c)+0x58=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 exception(1,1,bffefffc,c10096da,f5957fbc)+0x7a=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 interrupted_pc(1,1,bffefffc,c102ce99,c1202b40)=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 trap_name(1,f5957f80,f5f73f4c,f5f73f58)=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 vm_fault(f5f6ff30,bffef000,3,0,0,c1008ee4,f5f82550,fb7d9000)+0x74a=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 user_trap(f5f7a718)+0x2df=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >>>>> Page fault (14) at 0x1000 <<<<<=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 >>>>> user space <<<<<=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 db> show map $map2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Map 0xf5f6ff30: name=3D"exec", pmap=3D0xf5f71fa8,ref=3D1,nentries=3D5=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 size=3D290816,resident:290816,wired=3D0=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 version=3D14=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 map entry 0xf625ec08: start=3D0x0, end=3D0x1000=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 prot=3D1/7/copy, object=3D0xf5f6a7d0, offset=3D0x0=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 Object 0xf5f6a7d0: size=3D0x1000, 1 references=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 1 resident pages, 0 absent pages, 0 paging ops=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5938968=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 uninitialized,temporary internal,copy_strategy=3D0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 shadow=3D0x0 (offset=3D0x0),copy=3D0x0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 map entry 0xf625ebb0: start=3D0x1000, end=3D0x26000=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 prot=3D5/7/copy, object=3D0xf5f6ad70, offset=3D0x0=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 Object 0xf5f6ad70: size=3D0x25000, 1 references=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 37 resident pages, 0 absent pages, 0 paging ops=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82780=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 uninitialized,temporary internal,copy_strategy=3D0=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 shadow=3D0x0 (offset=3D0x0),copy=3D0x0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --8<---------------cut here---------------end--------------->8--- It says =E2=80=9Cpage fault at 0x1000=E2=80=9D but there is apparently a va= lid mapping at that address. Funny thing: if I set a breakpoint on =E2=80=98read_exec=E2=80=99 and conti= nue each time it=E2=80=99s hit, the =E2=80=98exec=E2=80=99 process starts just fine. Could it be a synchronization issue somewhere? Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 07 17:16:54 2022 Received: (at 58320) by debbugs.gnu.org; 7 Oct 2022 21:16:54 +0000 Received: from localhost ([127.0.0.1]:37587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oguiE-0006j5-DA for submit@debbugs.gnu.org; Fri, 07 Oct 2022 17:16:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oguiC-0006ir-Qh for 58320@debbugs.gnu.org; Fri, 07 Oct 2022 17:16:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53484) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogui6-0006Bh-MP; Fri, 07 Oct 2022 17:16:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=y/1oDdv1N+nVAcDyvEB+Mo96LNJJXhcFW/cJ8OBE+Dc=; b=B5Xv4pb0xCQXw4bPBwxM vJA3H2BxVuHOzMw1MQ1EbWjsuTP2Mnz613vEC1Zjowv5u5eVy4dKHxQmtb6Kobxb/6sDWgVJTX6vT tRX7Lv5f+N/DxakVjAr1XqKK978lg8n+UZ6pVBBkFLuH0+QtOQFXl6iwQ+VcQ91v4edirga7Spo8Q iB9bhhImfxYB8GsFaPvb/+6BNhS3yTLCbk2BoUEhlmwkQ6GO57eBQMsnk+563HhSqsPQzHIoRIf8B 36XrgZroZSTqBHpdBh6uJAbd1iCmTllBEg2LFJ3lc8Vqs57qH8q/eXMpbG6PqszkDP2gq2ktMZD6U BvlWJTd3KN0SFA==; Received: from 2a01cb008c016e00de41a9fffe47ec49.ipv6.abo.wanadoo.fr ([2a01:cb00:8c01:6e00:de41:a9ff:fe47:ec49]:42502 helo=begin.home) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogui6-0000iX-Eb; Fri, 07 Oct 2022 17:16:46 -0400 Received: from samy by begin.home with local (Exim 4.96) (envelope-from ) id 1ogui3-001mnH-2P; Fri, 07 Oct 2022 23:16:43 +0200 Date: Fri, 7 Oct 2022 23:16:43 +0200 From: Samuel Thibault To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) Message-ID: <20221007211643.bma6b5yfaj7a2d4i@begin> Mail-Followup-To: Ludovic =?utf-8?Q?Court=C3=A8s?= , 58320@debbugs.gnu.org, bug-hurd@gnu.org References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> <20221006224219.mn7zp7lhzxwlyrpx@begin> <8735c0f3d5.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8735c0f3d5.fsf@gnu.org> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org, 58320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 11:52:37 2022 Received: (at 58320) by debbugs.gnu.org; 8 Oct 2022 15:52:37 +0000 Received: from localhost ([127.0.0.1]:41270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ohC7w-0007D4-TW for submit@debbugs.gnu.org; Sat, 08 Oct 2022 11:52:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ohC7r-0007Cl-HE for 58320@debbugs.gnu.org; Sat, 08 Oct 2022 11:52:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40606) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohC7l-0003Ir-1E; Sat, 08 Oct 2022 11:52:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=Vp2GNwOYDnO5eFTZ2XE3gNJBN/1ijJydv6WLLwy5oJg=; b=dynwnBLjvJBW5xaNUE3l e+4KKtw2zXk+PPdB3oqUfiDBtvpuvg8QacA8zBSKdLgEqOOEi1s8dqpkiwF3yPm4SR0C7QPl7ep/4 JMFx5IT1oE3XkgiMCFMr3l+QN8apvejV1+4BiywIXEKyEYEW1G56uphHuX6yir4gWwANb6QVhT1Y1 +UAgFWbH4kY1C/0pZtikNxWXjBrLnwBqoknN8wlpy7L95QFuHV/KZ1h5D1JUTzH9F3YlTOkasvji+ 6RZ4KEncf6MVheKrqaXRXAUfBkjy4QXMkv2uoNsmvn5MI3jjM3q5wd8XBLSh6tb56XXHa6RyrrMM8 TvII8euL+Cye0w==; Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=38276 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohC7Z-0003Lp-Go; Sat, 08 Oct 2022 11:52:24 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 58320@debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> <20221006224219.mn7zp7lhzxwlyrpx@begin> <8735c0f3d5.fsf@gnu.org> <20221007211643.bma6b5yfaj7a2d4i@begin> Date: Sat, 08 Oct 2022 17:52:11 +0200 In-Reply-To: <20221007211643.bma6b5yfaj7a2d4i@begin> (Samuel Thibault's message of "Fri, 7 Oct 2022 23:16:43 +0200") Message-ID: <87zge671p0.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Samuel, Samuel Thibault 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-i58= 6-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=E2=80=99s =E2=80=98_dl_fatal_printf=E2=80=99 calling =E2=80=98_exit=E2= =80=99; it=E2=80=99s trying to tell us something. I=E2=80=99ll try and rebuild the system with the debugging patches at , to get early ld.so output, for lack of a better solution=E2=80=A6 >> 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 =E2=80=98_begin=E2=80=99 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/li= brtld.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=3Dboth -Wl,-z,defs \ /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/librtld.os = -Wl,--version-script=3D/tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/b= uild/ld.map \ -Wl,-soname=3Dld.so.1 \ -Wl,-defsym=3D_begin=3D0 i586-pc-gnu-readelf -s /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/b= uild/elf/ld.so.new \ | gawk '($7 ~ /^UND(|EF)$/ && $1 !=3D "0:" && $4 !=3D "REGISTER") { print= ; p=3D1 } END { exit p !=3D 0 }' mv -f /tmp/guix-build-glibc-cross-i586-pc-gnu-2.33.drv-0/build/elf/ld.so.ne= w /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 =E2=80=98-Wl,-defsym=3D_begin=3D0=E2=80=99 flag was removed in glibc c= ommit 6f043e0ee7e477f50a44024ed0cb579d5e3f511d (April 2022). On darnassus it=E2=80=99s different but then it=E2=80=99s Debian=E2=80=99s = glibc 2.35, natively built, so I don=E2=80=99t 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=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 09 12:09:19 2022 Received: (at 58320) by debbugs.gnu.org; 9 Oct 2022 16:09:20 +0000 Received: from localhost ([127.0.0.1]:44789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ohYrf-0002so-FN for submit@debbugs.gnu.org; Sun, 09 Oct 2022 12:09:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ohYrc-0002sZ-7p for 58320@debbugs.gnu.org; Sun, 09 Oct 2022 12:09:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37870) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohYrW-0000lk-UD; Sun, 09 Oct 2022 12:09:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=cKeEyRypRNhax9v6g3NG+Stj7qNY+pdOG+9zmygYvaA=; b=CBwrAcGYw6A5VzahyDJW gC2sELro+LSjnZhqSxse31vSRocMWYOtmZU3aohucmnpc8/Qa8QdOWJjZUk3rQCDZ9Dvl5E0xO0jZ 7+lzf/LgSA1jnL5vKVZG1nyqCYPCnlahkyJf90DbnF9F4MUtgupP6u5Z5IhOtad4vlwmdurfK/9qm yT3UEoPwAZubjCiwOPWeAE2eDLI5OSbO5iYZGnZhxfuCO8OcHFi9gtI3mnu0D6Ev764Fi3Olpkh8V CdCPV/Zfo8Wg47roh1+45VZrAEHeTPNho41AB2hFtsjlQgJ83Rvpiy4T2XOazdRYqHzyW0sAbCQDm CMRHz4SYgTtpCg==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:59568 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohYrW-00037L-BE; Sun, 09 Oct 2022 12:09:10 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 58320@debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> <20221006224219.mn7zp7lhzxwlyrpx@begin> <8735c0f3d5.fsf@gnu.org> <20221007211643.bma6b5yfaj7a2d4i@begin> <87zge671p0.fsf@gnu.org> Date: Sun, 09 Oct 2022 18:09:07 +0200 In-Reply-To: <87zge671p0.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sat, 08 Oct 2022 17:52:11 +0200") Message-ID: <8735bx6kt8.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi! Ludovic Court=C3=A8s skribis: > $ addr2line -e /gnu/store/m8afvcgwmrfhvjpd7b0xllk8vv5isd6j-glibc-cross-i= 586-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=E2=80=99s =E2=80=98_dl_fatal_printf=E2=80=99 calling =E2=80=98_exit= =E2=80=99; it=E2=80=99s trying to tell us > something. > > I=E2=80=99ll try and rebuild the system with the debugging patches at > , to > get early ld.so output, for lack of a better solution=E2=80=A6 I tried adapted the patches above and tried them, but it seems that =E2=80=98_dl_sysdep_start=E2=80=99 isn=E2=80=99t even reached. For example= , I set a breakpoint on =E2=80=98mach_task_self=E2=80=99 (called from =E2=80=98__mach_init=E2=80= =99, called from =E2=80=98_dl_sysdep_start=E2=80=99), but that=E2=80=99s never reached (I=E2= =80=99m assuming =E2=80=98break/tu=E2=80=99 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,=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 eip 0xc1030d5b=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 Breakpoint at task_resume: pushl %ebp=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 db> debug traps /on=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 db> b task_terminate=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 set breakpoint #2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 db> c=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 Kernel Debug trap trap, eip 0xc1030d5b=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 execkernel: Page fault (14), code=3D6=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 Stopped at 0x1000: pushl 0x4(%ebx)=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 >>>>> user space <<<<<=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 0x1000(bfffff24,0,0,1160b,0)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 0x11627(bfffff9c,0,0,0,2)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 0x11bb()=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 --8<---------------cut here---------------end--------------->8--- =E2=80=A6 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-p= c-gnu-2.33/lib/ld.so.1 --start-address=3D0x000011b0 |head -40 /gnu/store/4p1kab1c4h7h3kvgcm1hbjja4y5k9x4p-glibc-cross-i586-pc-gnu-2.33/li= b/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 =E2=80=98_dl_start=E2=80=99 is called and somehow the= n a tail-call to =E2=80=98_dl_fatal_printf=E2=80=99 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_PREL= INKED)]) 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 =3D 1; ... 578: __rtld_malloc_init_stubs (); --8<---------------cut here---------------end--------------->8--- It=E2=80=99s hard to be more precise because ELF_DYNAMIC_RELOCATE is a macro that expands to quite a lot of code. I don=E2=80=99t see the code path that would lead to a =E2=80=98_dl_fatal_p= rintf=E2=80=99 call though. Ideas? :-) Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 09 15:09:43 2022 Received: (at 58320) by debbugs.gnu.org; 9 Oct 2022 19:09:43 +0000 Received: from localhost ([127.0.0.1]:44930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ohbgF-0001Dj-Is for submit@debbugs.gnu.org; Sun, 09 Oct 2022 15:09:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ohbgD-0001DU-AK for 58320@debbugs.gnu.org; Sun, 09 Oct 2022 15:09:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46186) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohbg8-0008BM-3W; Sun, 09 Oct 2022 15:09:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=u3PtcJgHuRcp5pqq0WqSHTXeYehYTHKLnLxDwr8i4ag=; b=LRztJraLGLNegYGIjpP7 Y2Qxl7jfgC4gjAnQd8YuO0+34DcFuYesU5gi05aqg16PeDRhS5Mb8Hpj2hRlCd3StOdIt6KZdeplV +9hvMMpMDre5woXDefwSsAIXXdUrsPeb6mo6Gn0SNlNjMhoGCRw3yiwWx4Y8EEuxKKjhI74Bg1hCJ u6tsEx4PCb7tsyu3MVfASGHYjaHcyuJ+yXUbz+6oifr/mnTedJMRt2IffFtH9DQpV33ZO+dtQmt9n lan+yC84kMVpUSk28cpE9U02p0i0kD5vTw34uN0WDTdY4hNTW2vm6PNYgyRJRR6HvBCVMWWGxX4yY kWtfseJU6KMZoA==; Received: from [2a01:cb19:956:1b00:de41:a9ff:fe47:ec49] (port=37018 helo=begin.home) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohbg7-0007ij-Nk; Sun, 09 Oct 2022 15:09:35 -0400 Received: from samy by begin.home with local (Exim 4.96) (envelope-from ) id 1ohbg5-004eoP-2e; Sun, 09 Oct 2022 21:09:33 +0200 Date: Sun, 9 Oct 2022 21:09:33 +0200 From: Samuel Thibault To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) Message-ID: <20221009190933.tdozwl6bjap6mrru@begin> Mail-Followup-To: Ludovic =?utf-8?Q?Court=C3=A8s?= , 58320@debbugs.gnu.org, bug-hurd@gnu.org References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> <20221006224219.mn7zp7lhzxwlyrpx@begin> <8735c0f3d5.fsf@gnu.org> <20221007211643.bma6b5yfaj7a2d4i@begin> <87zge671p0.fsf@gnu.org> <8735bx6kt8.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8735bx6kt8.fsf@gnu.org> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org, 58320@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 10 17:14:26 2022 Received: (at 58320) by debbugs.gnu.org; 10 Oct 2022 21:14:27 +0000 Received: from localhost ([127.0.0.1]:50124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oi06U-0006lz-H7 for submit@debbugs.gnu.org; Mon, 10 Oct 2022 17:14:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oi06S-0006lm-QI for 58320@debbugs.gnu.org; Mon, 10 Oct 2022 17:14:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43266) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi06N-0000RG-HT; Mon, 10 Oct 2022 17:14:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=BkYhZQYMG80R3XesyeEkyfxrXVlwtgAJxA3JKxo3QN0=; b=jXYaBKeZxzuS59A2mlRQ JjFo7WA8QjpRVax+fcTfoVzYRRrrp+7lRNzqVteT2iVjV5AE0qF8BJ/i4BFLu5r3XAzq3mPSQyLhk ctmnMcQ+J1WRrpKzD6wV61XdVKRXFNK+fFY9lBGRFMRSbg97c/F1unrUdinlC+TBYsThLX40SkMJ6 r0UvJRCoH7leE4Jq/pjfcikb7NI9IpD7rViEIEim+6mNr98iCSeWrbQjEbr5SQ1451g+kUFnF0MfA i3bChG93oiei8nX2z36lsgeoR28dS2nwFPtGEVRM3fcwYDvT0SP4oPENNw5Ub38vfZNT4IjAXNvoM W1HRHx3lvJwcqw==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:53666 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi06L-000460-VE; Mon, 10 Oct 2022 17:14:18 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 58320@debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> <20221006224219.mn7zp7lhzxwlyrpx@begin> <8735c0f3d5.fsf@gnu.org> <20221007211643.bma6b5yfaj7a2d4i@begin> <87zge671p0.fsf@gnu.org> <8735bx6kt8.fsf@gnu.org> Date: Mon, 10 Oct 2022 23:14:15 +0200 In-Reply-To: <8735bx6kt8.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sun, 09 Oct 2022 18:09:07 +0200") Message-ID: <87pmezxty0.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ludovic Court=C3=A8s 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_PR= ELINKED)]) > 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 =3D 1; > ... > 578: __rtld_malloc_init_stubs (); Via brute force=C2=B9, I found that =E2=80=98__assert_fail=E2=80=99 is hit,= with its first argument in $eax being: --8<---------------cut here---------------start------------->8--- db> x/c 0x28604,80=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 ELF32_R_TYPE (reloc->r_info) =3D=3D R_386_RELATIVE\000\000m= ap->l_in=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 fo[VERSYMIDX (DT_VERSYM)] !=3D NULL\000\000Fatal glibc erro= r: Too=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 many audit mo=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 --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 =3D reloc_addr_arg; assert (ELF32_R_TYPE (reloc->r_info) =3D=3D R_386_RELATIVE); *reloc_addr +=3D l_addr; } --8<---------------cut here---------------end--------------->8--- How can we get there? Looking at =E2=80=98_dl_start=E2=80=99, it could be = that =E2=80=98elf_machine_load_address=E2=80=99 returns a bogus value and we end= up reading wrong ELF data? Or it could be memory corruption somewhere. Or=E2=80=A6? Thing is, it=E2=80=99s not fully deterministic (happens 9 times out of 10 w= ith KVM, never happens without KVM). Ideas? :-) Ludo=E2=80=99. =C2=B9 Building with =E2=80=98-fno-optimize-sibling-calls=E2=80=99 didn=E2= =80=99t help get nicer backtraces, but that=E2=80=99s prolly because all that early relocation c= ode is inlined. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 17 08:51:28 2022 Received: (at 58320) by debbugs.gnu.org; 17 Oct 2022 12:51:28 +0000 Received: from localhost ([127.0.0.1]:47742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1okPaZ-0007dq-JX for submit@debbugs.gnu.org; Mon, 17 Oct 2022 08:51:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1okPaX-0007dd-Ko for 58320@debbugs.gnu.org; Mon, 17 Oct 2022 08:51:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48608) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okPaP-0004RO-5i; Mon, 17 Oct 2022 08:51:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=hGU8dRhMjjnL7rsUjDGzqjDVlUJOrghGR0fjvru5VKA=; b=oNVXhAZfQ6GKe+LbT+Ix /KTMML8ttZNfvWgqSF7e/tkyL05BfOW9G7g0OS45PMEFleTECOQsZ49/3+WYY/1Ms+A3NGL39Xf2k X5oaAEmJt66lhqN+ALMLNdb/11c/2tv1W7A01heph+mbaDxCK5q5Vn2vVqy5oRLu0/9vzTw8Tajuw Sp6K01DJBQjenvpBKc+ZA+EwpdyhLBmtUzEwqtlHKgtzfVb3MDcMuh4llX2jiifhHAoDWHfGo/QVb uHgm/fzYolkqEPZ/PSGKpPq7WxmtNgdof9khg0KxG+3xPls1SGD4dlq/S8vgtCdlSgrOReM4Sek4v zvoyXr3Sau3dRg==; Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=34480 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okPaB-00024o-Bm; Mon, 17 Oct 2022 08:51:16 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 58320@debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> <20221006224219.mn7zp7lhzxwlyrpx@begin> <8735c0f3d5.fsf@gnu.org> Date: Mon, 17 Oct 2022 14:51:01 +0200 In-Reply-To: <8735c0f3d5.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Fri, 07 Oct 2022 10:24:22 +0200") Message-ID: <87czaqsjey.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi, Ludovic Court=C3=A8s skribis: > =E2=80=A6 so =E2=80=98exec_load=E2=80=99 is doing its job, it seems. Turns out that may not be the case. Here=E2=80=99s a *bad* mapping on the second =E2=80=98task_resume=E2=80=99 = breakpoint (when =E2=80=98exec=E2=80=99 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=3D"exec", pmap=3D0xf5f71fa8,ref=3D1,nentries=3D5 size=3D290816,resident:225280,wired=3D0 version=3D13 map entry 0xf625ec08: start=3D0x0, end=3D0x1000 prot=3D1/7/copy, object=3D0x0, offset=3D0x0 map entry 0xf625ebb0: start=3D0x1000, end=3D0x26000 prot=3D5/7/copy, object=3D0xf5f6ad70, offset=3D0x0 Object 0xf5f6ad70: size=3D0x25000, 1 references 37 resident pages, 0 absent pages, 0 paging ops memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82780 uninitialized,temporary internal,copy_strategy=3D0 shadow=3D0x0 (offset=3D0x0),copy=3D0x0 map entry 0xf625eb58: start=3D0x26000, end=3D0x34000 prot=3D1/7/copy, object=3D0xf5f6ad20, offset=3D0x0 Object 0xf5f6ad20: size=3D0xe000, 1 references 14 resident pages, 0 absent pages, 0 paging ops memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82730 uninitialized,temporary internal,copy_strategy=3D0 shadow=3D0x0 (offset=3D0x0),copy=3D0x0 map entry 0xf625eb00: start=3D0x34000, end=3D0x37000 prot=3D3/7/copy, object=3D0xf5f6acd0, offset=3D0x0 Object 0xf5f6acd0: size=3D0x3000, 1 references 3 resident pages,--db_more-- --8<---------------cut here---------------end--------------->8--- Compare with what a =E2=80=9Cgood=E2=80=9D mapping looks like at that same = moment: --8<---------------cut here---------------start------------->8--- start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1]Kernel Breakpoin= t 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=3D"exec", pmap=3D0xf5f71fa8,ref=3D1,nentries=3D5 size=3D290816,resident:229376,wired=3D0 version=3D14 map entry 0xf625ec08: start=3D0x0, end=3D0x1000 prot=3D1/7/copy, object=3D0xf5f6ad70, offset=3D0x0 Object 0xf5f6ad70: size=3D0x1000, 1 references 1 resident pages, 0 absent pages, 0 paging ops memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82780 uninitialized,temporary internal,copy_strategy=3D0 shadow=3D0x0 (offset=3D0x0),copy=3D0x0 map entry 0xf625ebb0: start=3D0x1000, end=3D0x26000 prot=3D5/7/copy, object=3D0xf5f6ad20, offset=3D0x0 Object 0xf5f6ad20: size=3D0x25000, 1 references 37 resident pages, 0 absent pages, 0 paging ops memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82730 uninitialized,temporary internal,copy_strategy=3D0 shadow=3D0x0 (offset=3D0x0),copy=3D0x0 map entry 0xf625eb58: start=3D0x26000, end=3D0x34000 prot=3D1/7/copy, object=3D0xf5f6acd0, offset=3D0x0 Object 0xf5f6acd0: size=3D0xe000, 1 references 14 resident pages, 0 absent pages, 0 paging ops memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f826e0 uninitialized,temporary internal,copy_strategy=3D0 shadow=3D0x0 (offset=3D0x0),copy=3D0x0 map entry 0xf625eb00: start=3D0x34000, end=3D0x37000 prot=3D3/7/copy, object=3D0xf5f6ac80, offset=3D0x0 Object 0xf5f6ac80: size=3D0x3000, 1 references 3 resident pages, 0 absent pages, 0 paging ops memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82690 uninitialized,temporary internal,copy_strategy=3D0 shadow=3D0x0 (offset=3D0x0),copy=3D0x0 map entry 0xf625eaa8: start=3D0xbfff0000, end=3D0xc0000000 prot=3D3/7/copy, object=3D0xf5f6ac30, offset=3D0x0 Object 0xf5f6ac30: size=3D0x10000, 1 references 1 resident pages, 0 absent pages, 0 paging ops memory object=3D0x0 (offset=3D0x0),control=3D0x0, name=3D0xf5f82640 uninitialized,temporary internal,copy_strategy=3D0 shadow=3D0x0 (offset=3D0x0),copy=3D0x0 --8<---------------cut here---------------end--------------->8--- Notice that 0xcbc reads a valid relocation, where 8 =3D R_386_RELATIVE. In the =E2=80=9Cbad=E2=80=9D case, the first map entry is empty, with no as= sociated memory object and zero resident pages. My reading of =E2=80=98read_exec=E2=80=99 is that the page is supposed to b= e populated eagerly by the =E2=80=98copyout=E2=80=99 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 =3D handle; [...] err =3D vm_allocate(user_map, &start_page, end_page - start_page, FALSE); assert(err =3D=3D 0); assert(start_page =3D=3D trunc_page(mem_addr)); if (file_size > 0) { err =3D copyout((char *)phystokv (mod->mod_start) + file_ofs, (void *)mem_addr, file_size); assert(err =3D=3D 0); } [...] return 0; } --8<---------------cut here---------------end--------------->8--- There are interesting tricks in =E2=80=98copyout_retry=E2=80=99 to fake a p= age fault so the copy can actually be made, IIUC. Could it be that this bit isn=E2=80=99t quite working? Ideas? Problem with debugging this is that setting a breakpoint on =E2=80=98exec_l= oad=E2=80=99 causes the system to boot fine (breaking on =E2=80=98task_resume=E2=80=99 i= s fine tough, go figure=E2=80=A6). Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 23 09:58:57 2022 Received: (at 58320) by debbugs.gnu.org; 23 Oct 2022 13:58:58 +0000 Received: from localhost ([127.0.0.1]:46297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ombVB-0002Ss-L6 for submit@debbugs.gnu.org; Sun, 23 Oct 2022 09:58:57 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ombV9-0002Sg-U0 for 58320@debbugs.gnu.org; Sun, 23 Oct 2022 09:58:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ombV4-0007Xj-HC; Sun, 23 Oct 2022 09:58:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=TmvlmyTy7aVaUdLSAMSRS9CnXSaOVvtx2F7sdoeZKy8=; b=XyJ0HFKOdiHqxzuXsKhI UDYqI9kS8RZqdRkvJvjF7C9suX+hF5r+U6kKk7CdW9vA+LFZVYtMf6PiS61ncze2F27ndxf5oDoR9 odgEbvYLd6ak68xvCdqDZnZbHr7ffpEaFnitB1EL0hbcCgEdCDoEAdZVdshs7yeZYp9hS/WZ3swa9 SITtB96UU0s13TnvZvdxX0y3YC7dGvIWdsOeqFo6yCuVFbwZokiVaFXOJM9L6OgBQTQigVLacIzW9 cByExZ18QQf6pOOZ12VppI9+tDuXomepfVjBO9qnkCYrVks2kwtkkBWjJVv1WWpoIC4ds0cj7yJRP 6VfZAvkJuDr7vw==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201] helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ombV3-0002U0-Vq; Sun, 23 Oct 2022 09:58:50 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: 58320@debbugs.gnu.org Subject: Re: bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd) References: <87k05eouh8.fsf@inria.fr> <8735c1nlga.fsf@gnu.org> <20221006135316.ijevz5ddnet4aqkr@begin> <87r0zkfvso.fsf@gnu.org> Date: Sun, 23 Oct 2022 15:58:47 +0200 In-Reply-To: <87r0zkfvso.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Fri, 07 Oct 2022 00:10:15 +0200") Message-ID: <87pmei3alk.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58320 Cc: bug-hurd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi, Ludovic Court=C3=A8s skribis: > Of course, the thing boots just fine on that machine when using > =E2=80=98exec.static=E2=80=99. It=E2=80=99s frustrating I did not get to the bottom of it, but time passes= , so I pushed this workaround in Guix commit 3fb3bd3da530a5f82a169b1fa451474f9d90c3b6. Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 29 05:42:00 2024 Received: (at control) by debbugs.gnu.org; 29 Aug 2024 09:42:00 +0000 Received: from localhost ([127.0.0.1]:50463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sjbfC-0000vu-Pf for submit@debbugs.gnu.org; Thu, 29 Aug 2024 05:42:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sjbfA-0000va-Sd for control@debbugs.gnu.org; Thu, 29 Aug 2024 05:41:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sjbe7-0006k6-QE for control@debbugs.gnu.org; Thu, 29 Aug 2024 05:40:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:Subject:From:To:Date:in-reply-to: references; bh=/qrliwNLaDojC7JcjvmNxXDkgAxVIDbYEBWhw+rnguU=; b=DkPds3sx6rH3F4 gRnmDqTooGW1pByC2R2EXT4ueyWOKE3P8m+dCOTXrywF+M080ayrufXBcHCFMDpCZnT6kH8+ZvUN0 DkajCNi42FbGma6WopurIzcryzCMZGZUKoZxI82vqWXVe+2VMv33CyFa9SYcQyvWUAWqHfFcHrBKW v83t7+2WvvMmlm78oND3eJ3i+u3r4qty2e/mUJALSudB2k5uS/8AeeAOvj1Mb8n5NJHA922Hgs9Gl O4agWdxkdNOzScuPEcUsW+z1FaRzNX8Xt5J/aEO/HgTnVecHeADZGGJRIO9fWhe1zhZT6qrKhtcpV fORkQLryRnK4WnzbTdhA==; Date: Thu, 29 Aug 2024 11:40:50 +0200 Message-Id: <87seunfyzh.fsf@gnu.org> To: control@debbugs.gnu.org From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: control message for bug #58320 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 58320 wontfix close 58320 quit From unknown Mon Jun 23 07:46:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 26 Sep 2024 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator