From nobody Sun Jun 29 15:33:20 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bVYGf3Jsmz60M4w for ; Sun, 29 Jun 2025 15:33:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bVYGd6R04z3krw for ; Sun, 29 Jun 2025 15:33:29 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id A3C71A64805; Sun, 29 Jun 2025 15:33:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1751211199; bh=SF93E4Ep1pohA6jFittkkWs9hRUnd0kM9wfYHeMTabE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PHrr8FmT7I8rUJ909H7x1W5M2q5rhx5InuQYWKoLZoFBD/NIRGS2wD4Id7dhKbIbT iXkSgdb1vh9KMa/lYiMuqb1QndDPvhOR8V5XQVhGly6eAwtOLIdsKdTyON9ulmQn8v 9+cftJDQTsnE2A70/tEuX4vJvwvz7K0Oqxp9ox+d6o7inpf99b0MncXvd+jNtaB9lB 5FN+SHh6Kf8yQoaGfKjs11c37msR0bDAxOQN6hMNyr4DiX+IMtALs1xGEh3nabVjIr T88EePCr2J1bYQJv9b816iy00vwxvj+kxS+eEtq/hagMH5rpbnTBD2SDO6Kbm9Oo3L 4vFPxcgMsHTdzgi3747YvKjrlTAW79DEJXqHjLNfzcQy8Cg9axqKkS51KQEFZFlaIY mCEIzIkFz+Fl1Smxf8JvhaiXh4v2usS07Vn2hPsPucwG3d8Z6KUxFoR3bim8D8PcYe GD5aKj2U6NJfz6DR92kA6Ix3Xt9j4xzrA3q6D5VfaEfoSt55p85f7eGHMwYEO6VPHx GKgpY1l8rLcTmAVt6JTC4+2hcLBtc2Qiy1saEnpvIrKqeCHCEVUNe+3mit6l7ddnTP Uddwc2Q5EKsbfOGuEhCQOQYkwkuXGZupcqX1U0ZWEIun41NlC1APMZgh47qtVfhtLa nDyk54ApJHn/BdI5Ghv3L0yI= Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 481D42D029E0; Sun, 29 Jun 2025 15:33:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id UWOzAz137yN8; Sun, 29 Jun 2025 15:33:21 +0000 (UTC) Received: from strong-rtwn0.sbone.de (strong-rtwn0.sbone.de [IPv6:fde9:577b:c1a9:4902:3e64:cfff:fe55:bc80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 30D482D029D8; Sun, 29 Jun 2025 15:33:21 +0000 (UTC) Date: Sun, 29 Jun 2025 15:33:20 +0000 (UTC) From: "Bjoern A. Zeeb" To: Konstantin Belousov cc: current@freebsd.org Subject: Re: Illegal instruction (core dumped) In-Reply-To: Message-ID: References: <357r6812-o83q-42rr-ps01-322458p6pp65@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4bVYGd6R04z3krw X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE] On Sun, 29 Jun 2025, Konstantin Belousov wrote: > On Sat, Jun 28, 2025 at 11:23:01PM +0000, Bjoern A. Zeeb wrote: >> On Sun, 29 Jun 2025, Konstantin Belousov wrote: >> >>> On Sat, Jun 28, 2025 at 05:32:17PM +0000, Bjoern A. Zeeb wrote: >>>> Hi, >>>> >>>> happened in one of my dev VMs: >>>> >>>> # more /etc/wpa_supplicant.conf Illegal instruction (core dumped) >>>> >>>> As I see nothing in UPDATING in the range from HEAD to the commit I >>>> rebased --onto b93161a7e38d (downgrade of the kernel) that would >>>> explain this I am wondering. >>>> >>>> >>>> Mounted the disk image from the base system and checked the core: >>>> >>>> Program terminated with signal SIGILL, Illegal instruction. >>>> (gdb) where >>>> #0 0x00003fabd04ebeed in tgetflag_sp (sp=0x3fa3ad42f3a0 , id=0x3fa3ad42f3a0 "") at /usr/src/contrib/ncurses/ncurses/tinfo/lib_termcap.c:259 >>>> #1 0x00003fa3ad404e9e in get_term () at /usr/src/contrib/less/screen.c:1256 >>>> #2 0x00003fa3ad4042ef in main (argc=1, argv=0x3fabce1f26b8) at /usr/src/contrib/less/main.c:344 >>>> >>> >>> What is the instruction that faulted? >>> Also show the registers values used by the instruction. >> >> I am a bit rusty with this user spaec stuff ;-) Hope the below helps. >> >> (gdb) display/i $pc >> 1: x/i $pc >> => 0x3fabd04ebeed : cmove %rbx,%rcx >> > > So this is kind of impossible. I wonder what's going on; that's #3 of really funky things I am seeing lately on different machines/VM/arhcitectures/source trees. > The instruction CMOVE is there from the PentiumPro times. It does not > access any resources except registers. It cannot cause the vmexit on its > own since it cannot generate exceptions (well perhaps except code fetch > page fault). The only possible vmexit on this instruction is due to > external events. But then bhyve does not generate #UD. > > BTW was it intel or amd cpu? intel Could it be due to any corruption? I'll keep a copy of the disk image for now but I need to keep moving and would love to do a complete installworld/kernel again just to see. BTW, when I tried gdb inside the VM it dumped core as well; same thing: (gdb) display/i $pc 1: x/i $pc => 0x828064eed : cmove %rbx,%rcx (gdb) info f Stack level 0, frame at 0x821dde8f0: rip = 0x828064eed in tgetflag_sp (/usr/src/contrib/ncurses/ncurses/tinfo/lib_termcap.c:259); saved rip = 0x8238b10ef called by frame at 0x821dde950 source language c. Arglist at 0x821dde8e0, args: sp=0xb2fd3634000, id=0xb2fd3634000 "" Locals at 0x821dde8e0, Previous frame's sp is 0x821dde8f0 Saved registers: rbx at 0x821dde8d0, rbp at 0x821dde8e0, r14 at 0x821dde8d8, rip at 0x821dde8e8 (gdb) info r rax 0x828077c30 35031317552 rbx 0x0 0 rcx 0xffffffffffffd720 -10464 rdx 0x821ddf05f 34927931487 rsi 0xb2fd3634000 12300037865472 rdi 0xb2fd3634000 12300037865472 rbp 0x821dde8e0 0x821dde8e0 rsp 0x821dde8e0 0x821dde8e0 r8 0xfffffffc 4294967292 r9 0x3 3 r10 0x54 84 r11 0x206 518 r12 0x1ff63a0 33514400 r13 0x8238c9488 34956153992 r14 0x821ddf05f 34927931487 r15 0x0 0 rip 0x828064eed 0x828064eed eflags 0x10246 [ PF ZF IF RF ] cs 0x43 67 ss 0x3b 59 ds 0x3b 59 es 0x3b 59 fs 0x13 19 gs 0x1b 27 fs_base 0xb2fd329d970 12300034103664 gs_base 0x0 0 (gdb) where #0 0x0000000828064eed in tgetflag_sp (sp=0xb2fd3634000, id=0xb2fd3634000 "") at /usr/src/contrib/ncurses/ncurses/tinfo/lib_termcap.c:259 #1 0x00000008238b10ef in _rl_init_terminal_io () from /usr/local/lib/libreadline.so.8 #2 0x00000008238b19d3 in rl_reset_terminal () from /usr/local/lib/libreadline.so.8 #3 0x0000000001822313 in init_page_info() () #4 0x00000000017eb74d in gdb_init() () #5 0x000000000159d7c3 in ?? () #6 0x000000000159c7bc in gdb_main(captured_main_args*) () #7 0x00000000012a87c1 in main () -- Bjoern A. Zeeb r15:7