From owner-freebsd-current@freebsd.org Sun Feb 24 01:28:57 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04010150BD43 for ; Sun, 24 Feb 2019 01:28:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3924A777D3; Sun, 24 Feb 2019 01:28:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1O1SpZS022340 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 23 Feb 2019 17:28:51 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1O1SpIS022339; Sat, 23 Feb 2019 17:28:51 -0800 (PST) (envelope-from sgk) Date: Sat, 23 Feb 2019 17:28:51 -0800 From: Steve Kargl To: Warner Losh Cc: Konstantin Belousov , FreeBSD Current , Peter Holm , Mark Johnston Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190224012851.GA21748@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223091931.GE2420@kib.kiev.ua> <20190223163619.GA18805@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 3924A777D3 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.92 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.92)[0.924,0]; IP_SCORE(0.05)[ip: (0.11), ipnet: 128.95.0.0/16(0.17), asn: 73(0.06), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-0.55)[-0.550,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.80)[0.800,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 01:28:57 -0000 On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: > On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > > > Supposely, the laptop only has 4 GB of memory. Not sure how > > it finds memory above 4 GB. > > > > Some older chipsets had a 'hole' in memory that they mapped the PCI bus > into and then remapped RAM in that range up above the 4GB boundary. That's > how it can find memory above 4GB when you have only 4GB of RAM. I hit it > with the PC Card stuff I did back in the day since it broke certain > heuristics I had in the code that turned out to be unwise for many reasons > (not just this one). I don't recall all the details, since it's been so > long ago. > > So I think kib@ is right when he highlights > > +0x0000000100000000 - 0x000000011ffe7fff, 536772608 bytes (131048 pages) > > as the memory, since this is indeed above the 4GB limit. It's about 128k > of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly > round number. Also one that's easy to implement in hardware. So it > certainly "smells" the same... > > That's why I agree with others that hw.above4g_allow=0 is worth a shot, for > at least diagnostic purposes. This memory wasn't used before and if it's > used now by the drm drivers, and those aren't PAE safe (meaning they cope > with allocations beyond 4GB), then that's quite useful to know. Or maybe > it's a different driver hating things and stomping on video memory due to > wrap around. > > Warner Thanks for the explanation. Here's an update. TL;DR: xorg is up and running; drm-legacy-kmod seems to be unsafe/unaware of PAE. Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. Kernel is unmodified GENERIC. Reboot without setting anything in /boot/loader.conf % sysctl -a | grep above % sysctl -a | grep pae vm.pmap.pae_mode: 1 % kldload /boot/modules/i915kms.ko Black screen of death. Did not even get to running xinit. Hard reset to single user mode. # fsck -y # mount -a # vi /boot/loader.conf. (Add hw.above4g_allow=0) # sync # shutdown -r now % sysctl -a | grep above % sysctl -a | grep pae vm.pmap.pae_mode: 1 % cat /boot/loader.conf if_ath_load="YES" if_ath_pci_load="YES" cpuctl_load="YES" hw.above4g_allow=0 % kldload /boot/modules/i915kms.ko Switch to vt3, login as normal user. % startx -- -depth 24 >& ~/tmp/.x.out Xorg is up and running. Not sure why my first attempt at using hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg bits and kernel/world bits. % sysctl -a | grep mem vm.lowmem_period: 10 vm.kmem_map_free: 1669365760 vm.kmem_map_size: 41910272 vm.kmem_size_scale: 1 vm.kmem_size_max: 1711276032 vm.kmem_size_min: 12582912 vm.kmem_zmax: 65536 vm.kmem_size: 1711276032 hw.physmem: 3715489792 hw.usermem: 3592175616 hw.realmem: 4294963200 % dmesg | grep memory real memory = 4294967296 (4096 MB) avail memory = 3637673984 (3469 MB) agp0: aperture size is 256M, detected 7676k stolen memory The pre-r343567 dmesg has real memory = 4294967296 (4096 MB) avail memory = 3639914496 (3471 MB) I can live with 2 MB loss. Conclusion, drm-legacy-kmod is not PAE safe/aware. Probably want to put something in /usr/src about possible problems with new pmap.h on i386 FreeBSD. -- Steve From owner-freebsd-current@freebsd.org Sun Feb 24 03:52:20 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AF9F1510BC0 for ; Sun, 24 Feb 2019 03:52:20 +0000 (UTC) (envelope-from ume@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A0FE8492D; Sun, 24 Feb 2019 03:52:20 +0000 (UTC) (envelope-from ume@FreeBSD.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ume) by smtp.freebsd.org (Postfix) with ESMTPSA id 4FA65483D; Sun, 24 Feb 2019 03:52:19 +0000 (UTC) (envelope-from ume@FreeBSD.org) Date: Sun, 24 Feb 2019 12:52:16 +0900 Message-ID: From: Hajimu UMEMOTO To: "O. Hartmann" Cc: freebsd-current Subject: Re: syslogd: using IPv6 as hostnames results in "IP mismatch" In-Reply-To: <20190131082420.7724799c@freyja> References: <20190131082420.7724799c@freyja> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 11.2-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 2A0FE8492D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; NEURAL_HAM_SHORT(-0.95)[-0.953,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 03:52:20 -0000 Hi, >>>>> On Thu, 31 Jan 2019 08:24:38 +0100 >>>>> "O. Hartmann" said: ohartmann> validate: dgram from IP ffdff:dead:beef::aaaa, port 514, name \ ohartmann> fdff:dead:beef::aaaa; ohartmann> rejected in rule 1 due to IP mismatch. The -a option was broken. It should be fixed now. Please try it. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume From owner-freebsd-current@freebsd.org Sun Feb 24 06:23:06 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2809115140F2 for ; Sun, 24 Feb 2019 06:23:06 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 89451886B8 for ; Sun, 24 Feb 2019 06:23:04 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.15.2/8.15.2) with ESMTPSA/inet6 id x1O6Mhr8097330 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Feb 2019 15:22:48 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 24 Feb 2019 15:22:43 +0900 Message-ID: From: Hajimu UMEMOTO To: "O. Hartmann" Cc: freebsd-current Subject: Re: syslogd: using IPv6 as hostnames results in "IP mismatch" In-Reply-To: <20190131082420.7724799c@freyja> References: <20190131082420.7724799c@freyja> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 11.2-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.mahoroba.org [IPv6:2001:2f0:104:8010:0:0:0:1]); Sun, 24 Feb 2019 15:22:48 +0900 (JST) X-Virus-Scanned: clamav-milter 0.101.1 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on asuka.mahoroba.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 06:23:06 -0000 Hi, >>>>> On Thu, 31 Jan 2019 08:24:38 +0100 >>>>> "O. Hartmann" said: ohartmann> validate: dgram from IP ffdff:dead:beef::aaaa, port 514, name \ ohartmann> fdff:dead:beef::aaaa; ohartmann> rejected in rule 1 due to IP mismatch. The -a option was broken. It should be fixed now. Please, try it. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-current@freebsd.org Sun Feb 24 03:51:14 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B0811510A7E for ; Sun, 24 Feb 2019 03:51:14 +0000 (UTC) (envelope-from ume@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B01C58484F; Sun, 24 Feb 2019 03:51:13 +0000 (UTC) (envelope-from ume@FreeBSD.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ume) by smtp.freebsd.org (Postfix) with ESMTPSA id F287A483C; Sun, 24 Feb 2019 03:51:12 +0000 (UTC) (envelope-from ume@FreeBSD.org) Date: Sun, 24 Feb 2019 12:51:04 +0900 Message-ID: From: Hajimu UMEMOTO To: "O. Hartmann" Cc: freebsd-current Subject: Re: syslogd: using IPv6 as hostnames results in "IP mismatch" In-Reply-To: <20190131082420.7724799c@freyja> References: <20190131082420.7724799c@freyja> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 11.2-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: B01C58484F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; NEURAL_HAM_SHORT(-0.95)[-0.953,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 03:51:14 -0000 Hi, >>>>> On Thu, 31 Jan 2019 08:24:38 +0100 >>>>> "O. Hartmann" said: ohartmann> validate: dgram from IP ffdff:dead:beef::aaaa, port 514, name \ ohartmann> fdff:dead:beef::aaaa; ohartmann> rejected in rule 1 due to IP mismatch. The -a option was broken. It should be fixed now. Please try it. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume From owner-freebsd-current@freebsd.org Sun Feb 24 09:28:42 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B486315184DA for ; Sun, 24 Feb 2019 09:28:42 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay104.isp.belgacom.be (mailrelay104.isp.belgacom.be [195.238.20.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A5B88CE7C; Sun, 24 Feb 2019 09:28:41 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DJAAC+YnJc/99MQFdkDg0BAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVMEAQEBCwEBggJWYQEgEieNAIp2AQGCDDUBiXCNeBSBZ4R5AoN?= =?us-ascii?q?9IzYHDQEDAQECAQECbShCAQEECwGEdwEFOhwjEAsOCgkNARcPKh4GE4UXrFm?= =?us-ascii?q?JFIEOjF+Bf4QjhFsPXwKFFwKJeIIXhQuSPwmOUoQCJYFxkR6LXpJzBSyBVk0?= =?us-ascii?q?wCIMngiUDF41jPD4DMAGDBIIiiBgBDReCJwEB?= X-IPAS-Result: =?us-ascii?q?A2DJAAC+YnJc/99MQFdkDg0BAQEBAwEBAQcDAQEBgVMEA?= =?us-ascii?q?QEBCwEBggJWYQEgEieNAIp2AQGCDDUBiXCNeBSBZ4R5AoN9IzYHDQEDAQECA?= =?us-ascii?q?QECbShCAQEECwGEdwEFOhwjEAsOCgkNARcPKh4GE4UXrFmJFIEOjF+Bf4Qjh?= =?us-ascii?q?FsPXwKFFwKJeIIXhQuSPwmOUoQCJYFxkR6LXpJzBSyBVk0wCIMngiUDF41jP?= =?us-ascii?q?D4DMAGDBIIiiBgBDReCJwEB?= Received: from 223.76-64-87.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([87.64.76.223]) by relay.skynet.be with ESMTP; 24 Feb 2019 10:27:28 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id x1O9RRHO001524; Sun, 24 Feb 2019 10:27:28 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Sun, 24 Feb 2019 10:27:26 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Steve Kargl Cc: Warner Losh , Konstantin Belousov , FreeBSD Current , Peter Holm , Mark Johnston Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190224102726.746adb9f@kalimero.tijl.coosemans.org> In-Reply-To: <20190224012851.GA21748@troutmask.apl.washington.edu> References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223091931.GE2420@kib.kiev.ua> <20190223163619.GA18805@troutmask.apl.washington.edu> <20190224012851.GA21748@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6A5B88CE7C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.90 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; NEURAL_HAM_SHORT(-0.91)[-0.906,0]; ASN(0.00)[asn:5432, ipnet:195.238.0.0/19, country:BE]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 09:28:42 -0000 On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl wrote: > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl >> wrote: >>> Supposely, the laptop only has 4 GB of memory. Not sure how >>> it finds memory above 4 GB. >> >> Some older chipsets had a 'hole' in memory that they mapped the PCI bus >> into and then remapped RAM in that range up above the 4GB boundary. That's >> how it can find memory above 4GB when you have only 4GB of RAM. I hit it >> with the PC Card stuff I did back in the day since it broke certain >> heuristics I had in the code that turned out to be unwise for many reasons >> (not just this one). I don't recall all the details, since it's been so >> long ago. >> >> So I think kib@ is right when he highlights >>> +0x0000000100000000 - 0x000000011ffe7fff, 536772608 bytes (131048 pages) >> >> as the memory, since this is indeed above the 4GB limit. It's about 128k >> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly >> round number. Also one that's easy to implement in hardware. So it >> certainly "smells" the same... >> >> That's why I agree with others that hw.above4g_allow=0 is worth a shot, for >> at least diagnostic purposes. This memory wasn't used before and if it's >> used now by the drm drivers, and those aren't PAE safe (meaning they cope >> with allocations beyond 4GB), then that's quite useful to know. Or maybe >> it's a different driver hating things and stomping on video memory due to >> wrap around. > > Thanks for the explanation. Here's an update. TL;DR: xorg is > up and running; drm-legacy-kmod seems to be unsafe/unaware of > PAE. > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > Kernel is unmodified GENERIC. > > Reboot without setting anything in /boot/loader.conf > > % sysctl -a | grep above > % sysctl -a | grep pae > vm.pmap.pae_mode: 1 > % kldload /boot/modules/i915kms.ko > > Black screen of death. Did not even get to running xinit. > > Hard reset to single user mode. > > # fsck -y > # mount -a > # vi /boot/loader.conf. > (Add hw.above4g_allow=0) > # sync > # shutdown -r now > > % sysctl -a | grep above > % sysctl -a | grep pae > vm.pmap.pae_mode: 1 > % cat /boot/loader.conf > if_ath_load="YES" > if_ath_pci_load="YES" > cpuctl_load="YES" > hw.above4g_allow=0 > % kldload /boot/modules/i915kms.ko > > Switch to vt3, login as normal user. > > % startx -- -depth 24 >& ~/tmp/.x.out > > Xorg is up and running. Not sure why my first attempt at using > hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg > bits and kernel/world bits. > > % sysctl -a | grep mem > vm.lowmem_period: 10 > vm.kmem_map_free: 1669365760 > vm.kmem_map_size: 41910272 > vm.kmem_size_scale: 1 > vm.kmem_size_max: 1711276032 > vm.kmem_size_min: 12582912 > vm.kmem_zmax: 65536 > vm.kmem_size: 1711276032 > hw.physmem: 3715489792 > hw.usermem: 3592175616 > hw.realmem: 4294963200 > > % dmesg | grep memory > real memory = 4294967296 (4096 MB) > avail memory = 3637673984 (3469 MB) > agp0: aperture size is 256M, detected 7676k stolen memory > > The pre-r343567 dmesg has > > real memory = 4294967296 (4096 MB) > avail memory = 3639914496 (3471 MB) > > I can live with 2 MB loss. > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > Probably want to put something in /usr/src about possible > problems with new pmap.h on i386 FreeBSD. Now it would be interesting to do the same tests with drm-current-kmod. From owner-freebsd-current@freebsd.org Sun Feb 24 17:07:06 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FA2E1504448 for ; Sun, 24 Feb 2019 17:07:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B1A275109 for ; Sun, 24 Feb 2019 17:07:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id z13so4003763qki.2 for ; Sun, 24 Feb 2019 09:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u6sSNMbV7AWggVafGl+9EjQ2biXDsQUnKCQVNFxppZI=; b=csoE0+jaYza9lPQIEKfu2muywhY0kn8AFTKroMgxVVfGkDqrhiZL6SLgjmNInweJdB j4ktbRArWjbMP93N+8xBjOvcx0hzW09hx8ETVu+0oKAlELJt3psrRdz08FM1L8eSVbHa KplB7sJQkJ2G4o6IG71GwWwn/rSkp4DJnLZ2pOL/UVlkED+Su2UnAp7+/9wBPTnOoLwk bfY5uhPd5i1qFi3HhpAKqHPv/6E4m4hxFuwiKS0nk0ZDbUbr7rWbD9T5SSvSfXVWZGn6 opNMzaXQinYYGaulIcXcrBQA1LgwTcwmhPnAM3tE1Pa8gK07NrFwq41WltChUjhRfPPT og+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u6sSNMbV7AWggVafGl+9EjQ2biXDsQUnKCQVNFxppZI=; b=CyDxbl2Zxi+Wc+t7O0NdeEfNo0HNdRRq3jYSRXjqdbWF54osiDErID8TbpooHuUHNc DwWbAxF5ipp/Z5pScxx2ew9FIyj7XITewGsflOQAH4H5ShpH9jDBKG1Kglu4wBN75Adi UUGagrH37+Ghg9FlUnS4MKiScWBsCRBRIHAtcwivJp7gFTLzdIZJnlB+5Dpf8++bgHCL P6XvxssUjr5LmBKZtnkw3x3wi3c14f/GLJpirgyUdYN/iVlpV6lTWoBqQtc0jIQCKpSk I3mgceE3HGf8JBPGM5zzqPr2snv8mXsMuypeUE3/iGk+c+uyrp5Q4KvCRuWTVQooWd2E ShKw== X-Gm-Message-State: AHQUAua8jZCyLHEWmmut3EkbXa6s+1AXrCxJHHMojHV8AnSxFMY01FyX msV1XSfrGK44amQ9vtffIYuCqut5hUT9miVkDzxrGQ== X-Google-Smtp-Source: AHgI3IaGu5lPTLgnKxyLRYH7+d9aDXJUe9G+1bVd58Wiwe+CGgYoA3oftPEXGNQsHL/myYpBiHh871XHZ5UnWjp7eSE= X-Received: by 2002:a37:9201:: with SMTP id u1mr10288653qkd.258.1551028024496; Sun, 24 Feb 2019 09:07:04 -0800 (PST) MIME-Version: 1.0 References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223091931.GE2420@kib.kiev.ua> <20190223163619.GA18805@troutmask.apl.washington.edu> <20190224012851.GA21748@troutmask.apl.washington.edu> <20190224102726.746adb9f@kalimero.tijl.coosemans.org> In-Reply-To: <20190224102726.746adb9f@kalimero.tijl.coosemans.org> From: Warner Losh Date: Sun, 24 Feb 2019 10:06:53 -0700 Message-ID: Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: =?UTF-8?Q?T=C4=B3l_Coosemans?= Cc: Steve Kargl , Konstantin Belousov , FreeBSD Current , Peter Holm , Mark Johnston X-Rspamd-Queue-Id: 6B1A275109 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=csoE0+ja X-Spamd-Result: default: False [-5.62 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[0.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.85)[-0.847,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.76)[ip: (-9.10), ipnet: 2607:f8b0::/32(-2.65), asn: 15169(-2.00), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 17:07:06 -0000 On Sun, Feb 24, 2019 at 2:27 AM T=C4=B3l Coosemans wrote= : > On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl > wrote: > > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: > >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl > >> wrote: > >>> Supposely, the laptop only has 4 GB of memory. Not sure how > >>> it finds memory above 4 GB. > >> > >> Some older chipsets had a 'hole' in memory that they mapped the PCI bu= s > >> into and then remapped RAM in that range up above the 4GB boundary. > That's > >> how it can find memory above 4GB when you have only 4GB of RAM. I hit = it > >> with the PC Card stuff I did back in the day since it broke certain > >> heuristics I had in the code that turned out to be unwise for many > reasons > >> (not just this one). I don't recall all the details, since it's been s= o > >> long ago. > >> > >> So I think kib@ is right when he highlights > >>> +0x0000000100000000 - 0x000000011ffe7fff, 536772608 bytes (131048 > pages) > >> > >> as the memory, since this is indeed above the 4GB limit. It's about > 128k > >> of 4k pages (just shy of the 131072 I'd expect), which is a surprising= ly > >> round number. Also one that's easy to implement in hardware. So it > >> certainly "smells" the same... > >> > >> That's why I agree with others that hw.above4g_allow=3D0 is worth a sh= ot, > for > >> at least diagnostic purposes. This memory wasn't used before and if it= 's > >> used now by the drm drivers, and those aren't PAE safe (meaning they > cope > >> with allocations beyond 4GB), then that's quite useful to know. Or may= be > >> it's a different driver hating things and stomping on video memory due > to > >> wrap around. > > > > Thanks for the explanation. Here's an update. TL;DR: xorg is > > up and running; drm-legacy-kmod seems to be unsafe/unaware of > > PAE. > > > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > > Kernel is unmodified GENERIC. > > > > Reboot without setting anything in /boot/loader.conf > > > > % sysctl -a | grep above > > % sysctl -a | grep pae > > vm.pmap.pae_mode: 1 > > % kldload /boot/modules/i915kms.ko > > > > Black screen of death. Did not even get to running xinit. > > > > Hard reset to single user mode. > > > > # fsck -y > > # mount -a > > # vi /boot/loader.conf. > > (Add hw.above4g_allow=3D0) > > # sync > > # shutdown -r now > > > > % sysctl -a | grep above > > % sysctl -a | grep pae > > vm.pmap.pae_mode: 1 > > % cat /boot/loader.conf > > if_ath_load=3D"YES" > > if_ath_pci_load=3D"YES" > > cpuctl_load=3D"YES" > > hw.above4g_allow=3D0 > > % kldload /boot/modules/i915kms.ko > > > > Switch to vt3, login as normal user. > > > > % startx -- -depth 24 >& ~/tmp/.x.out > > > > Xorg is up and running. Not sure why my first attempt at using > > hw.above4g_allow=3D0 did not work. Perhaps, mismatch between the xorg > > bits and kernel/world bits. > > > > % sysctl -a | grep mem > > vm.lowmem_period: 10 > > vm.kmem_map_free: 1669365760 > > vm.kmem_map_size: 41910272 > > vm.kmem_size_scale: 1 > > vm.kmem_size_max: 1711276032 > > vm.kmem_size_min: 12582912 > > vm.kmem_zmax: 65536 > > vm.kmem_size: 1711276032 > > hw.physmem: 3715489792 > > hw.usermem: 3592175616 > > hw.realmem: 4294963200 > > > > % dmesg | grep memory > > real memory =3D 4294967296 (4096 MB) > > avail memory =3D 3637673984 (3469 MB) > > agp0: aperture size is 256M, detected 7676k stolen memory > > > > The pre-r343567 dmesg has > > > > real memory =3D 4294967296 (4096 MB) > > avail memory =3D 3639914496 (3471 MB) > > > > I can live with 2 MB loss. > > > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > > > Probably want to put something in /usr/src about possible > > problems with new pmap.h on i386 FreeBSD. > > Now it would be interesting to do the same tests with drm-current-kmod. > Maybe I missed it, but Steve, did you run the patched in a different way tests that I suggested? Replacing the limits with 0xffffffff for testing purposes to ensure that drm isn't saying it can cope with larger addresses? That might help narrow down what the problem here one more level than "It's PAE". Warner From owner-freebsd-current@freebsd.org Sun Feb 24 17:58:30 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEF0615056B7 for ; Sun, 24 Feb 2019 17:58:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 471EF77558; Sun, 24 Feb 2019 17:58:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1OHwRAw026349 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Feb 2019 09:58:27 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1OHwR3g026348; Sun, 24 Feb 2019 09:58:27 -0800 (PST) (envelope-from sgk) Date: Sun, 24 Feb 2019 09:58:27 -0800 From: Steve Kargl To: Warner Losh Cc: =?utf-8?Q?T=C4=B3l?= Coosemans , Konstantin Belousov , FreeBSD Current , Peter Holm , Mark Johnston Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190224175827.GB26240@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223091931.GE2420@kib.kiev.ua> <20190223163619.GA18805@troutmask.apl.washington.edu> <20190224012851.GA21748@troutmask.apl.washington.edu> <20190224102726.746adb9f@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 471EF77558 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.88 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.84)[0.837,0]; NEURAL_HAM_LONG(-0.54)[-0.543,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.84)[0.844,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.05)[ip: (0.11), ipnet: 128.95.0.0/16(0.17), asn: 73(0.06), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 17:58:31 -0000 On Sun, Feb 24, 2019 at 10:06:53AM -0700, Warner Losh wrote: > > > > Maybe I missed it, but Steve, did you run the patched in a different way > tests that I suggested? Replacing the limits with 0xffffffff for testing > purposes to ensure that drm isn't saying it can cope with larger addresses? > That might help narrow down what the problem here one more level than "It's > PAE". > So, I dug through the code a bit. Niclas changed the port to use BUS_SPACE_MAXADDR. This is defined in include/x86/bus.h #if defined(__amd64__) || defined(PAE) #define BUS_SPACE_MAXADDR_48BIT 0xFFFFFFFFFFFFULL #define BUS_SPACE_MAXADDR 0xFFFFFFFFFFFFFFFFULL #else #define BUS_SPACE_MAXADDR 0xFFFFFFFF #endif I don't know if defined(PAE) is effected by hw.above4g_allow, or where it gets defined or if it is defined. -- Steve From owner-freebsd-current@freebsd.org Sun Feb 24 17:37:53 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C08931504DD4 for ; Sun, 24 Feb 2019 17:37:53 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 825E375F42; Sun, 24 Feb 2019 17:37:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1OHboeb026233 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Feb 2019 09:37:50 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1OHbofQ026232; Sun, 24 Feb 2019 09:37:50 -0800 (PST) (envelope-from sgk) Date: Sun, 24 Feb 2019 09:37:50 -0800 From: Steve Kargl To: Warner Losh Cc: =?utf-8?Q?T=C4=B3l?= Coosemans , Konstantin Belousov , FreeBSD Current , Peter Holm , Mark Johnston Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190224173750.GA26171@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223091931.GE2420@kib.kiev.ua> <20190223163619.GA18805@troutmask.apl.washington.edu> <20190224012851.GA21748@troutmask.apl.washington.edu> <20190224102726.746adb9f@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 825E375F42 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.95 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.906,0]; NEURAL_HAM_LONG(-0.51)[-0.508,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.81)[0.809,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.05)[ip: (0.11), ipnet: 128.95.0.0/16(0.17), asn: 73(0.06), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 17:37:54 -0000 On Sun, Feb 24, 2019 at 10:06:53AM -0700, Warner Losh wrote: > On Sun, Feb 24, 2019 at 2:27 AM Tijl Coosemans wrote: > > > On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl > > wrote: > > > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: > > >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl > > >> wrote: > > >>> Supposely, the laptop only has 4 GB of memory. Not sure how > > >>> it finds memory above 4 GB. > > >> > > >> Some older chipsets had a 'hole' in memory that they mapped the PCI bus > > >> into and then remapped RAM in that range up above the 4GB boundary. > > That's > > >> how it can find memory above 4GB when you have only 4GB of RAM. I hit it > > >> with the PC Card stuff I did back in the day since it broke certain > > >> heuristics I had in the code that turned out to be unwise for many > > reasons > > >> (not just this one). I don't recall all the details, since it's been so > > >> long ago. > > >> > > >> So I think kib@ is right when he highlights > > >>> +0x0000000100000000 - 0x000000011ffe7fff, 536772608 bytes (131048 > > pages) > > >> > > >> as the memory, since this is indeed above the 4GB limit. It's about > > 128k > > >> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly > > >> round number. Also one that's easy to implement in hardware. So it > > >> certainly "smells" the same... > > >> > > >> That's why I agree with others that hw.above4g_allow=0 is worth a shot, > > for > > >> at least diagnostic purposes. This memory wasn't used before and if it's > > >> used now by the drm drivers, and those aren't PAE safe (meaning they > > cope > > >> with allocations beyond 4GB), then that's quite useful to know. Or maybe > > >> it's a different driver hating things and stomping on video memory due > > to > > >> wrap around. > > > > > > Thanks for the explanation. Here's an update. TL;DR: xorg is > > > up and running; drm-legacy-kmod seems to be unsafe/unaware of > > > PAE. > > > > > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > > > Kernel is unmodified GENERIC. > > > > > > Reboot without setting anything in /boot/loader.conf > > > > > > % sysctl -a | grep above > > > % sysctl -a | grep pae > > > vm.pmap.pae_mode: 1 > > > % kldload /boot/modules/i915kms.ko > > > > > > Black screen of death. Did not even get to running xinit. > > > > > > Hard reset to single user mode. > > > > > > # fsck -y > > > # mount -a > > > # vi /boot/loader.conf. > > > (Add hw.above4g_allow=0) > > > # sync > > > # shutdown -r now > > > > > > % sysctl -a | grep above > > > % sysctl -a | grep pae > > > vm.pmap.pae_mode: 1 > > > % cat /boot/loader.conf > > > if_ath_load="YES" > > > if_ath_pci_load="YES" > > > cpuctl_load="YES" > > > hw.above4g_allow=0 > > > % kldload /boot/modules/i915kms.ko > > > > > > Switch to vt3, login as normal user. > > > > > > % startx -- -depth 24 >& ~/tmp/.x.out > > > > > > Xorg is up and running. Not sure why my first attempt at using > > > hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg > > > bits and kernel/world bits. > > > > > > % sysctl -a | grep mem > > > vm.lowmem_period: 10 > > > vm.kmem_map_free: 1669365760 > > > vm.kmem_map_size: 41910272 > > > vm.kmem_size_scale: 1 > > > vm.kmem_size_max: 1711276032 > > > vm.kmem_size_min: 12582912 > > > vm.kmem_zmax: 65536 > > > vm.kmem_size: 1711276032 > > > hw.physmem: 3715489792 > > > hw.usermem: 3592175616 > > > hw.realmem: 4294963200 > > > > > > % dmesg | grep memory > > > real memory = 4294967296 (4096 MB) > > > avail memory = 3637673984 (3469 MB) > > > agp0: aperture size is 256M, detected 7676k stolen memory > > > > > > The pre-r343567 dmesg has > > > > > > real memory = 4294967296 (4096 MB) > > > avail memory = 3639914496 (3471 MB) > > > > > > I can live with 2 MB loss. > > > > > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > > > > > Probably want to put something in /usr/src about possible > > > problems with new pmap.h on i386 FreeBSD. > > > > Now it would be interesting to do the same tests with drm-current-kmod. > > > > Maybe I missed it, but Steve, did you run the patched in a different way > tests that I suggested? Replacing the limits with 0xffffffff for testing > purposes to ensure that drm isn't saying it can cope with larger addresses? > That might help narrow down what the problem here one more level than "It's > PAE". > I did try a few patches to the drm-legacy-kmod port when I first found that it would not build, but I honestly don't remember if your suggestion was one of them. I'm testing with the stock port at r492863 | zeising | 2019-02-13 12:52:03 -0800 (Wed, 13 Feb 2019) | 8 lines graphics/drm-legacy-kmod: Update snapshot Update the graphics/drm-legacy-kmod drivers to the latest snapshot. This includes fixes to make the driver build on CURRENT after base r343567. Reported by: Steve Kargl Approved by: jmd (maintainer, implicit) If I do not set hw.above4g_allow to 0, the above port will lock up the system. I will need to find your email with the 0xffffffff sugestion and compare that to what Niclas did to fix the build of the port. -- Steve From owner-freebsd-current@freebsd.org Mon Feb 25 20:47:45 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 554171515BA4 for ; Mon, 25 Feb 2019 20:47:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D88F81026 for ; Mon, 25 Feb 2019 20:47:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x844.google.com with SMTP id u7so3060248qtg.9 for ; Mon, 25 Feb 2019 12:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gvplOCrWO95tdd664nZ4S+VnO7xMJN42DnwBX4uWEiY=; b=j0+KZy9J725ExnAYIx9OuHjOq8Ve5WhUtYObdqyk1s1oDk84EBbtQhYyjRvyq3kCYH X0G3dNIhLswV28Omb8czyCFOE7EOD391uuJJymraYjzRU+OBop1MSNWrSDd3gti+q2ma 5yTw/GXTh7jkZgG4b45Yj+fVJIdnPqrftWJRT0mW06eIDe8NoCjcCV5m1RUoUK5kOD3K lsEnnUdCwp6g9635qfNg87EpVUM4I/M4WRfBJb26KKJef7fFnL61g10Ru/Fnf7h2pAoB H6jSUBgzc3AYxKEtVtLD4jVwslDT3YyLAp9a2PUYduSTOv+WwBcQkt9CnFuENWdPz8zH kI/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gvplOCrWO95tdd664nZ4S+VnO7xMJN42DnwBX4uWEiY=; b=RF1Z8CboInsJdoKfiNmeyRS32YdgCoWR7bANdRq6s0HWTVR6N6r4k1NQWAgHjJWfxT 8gkKZFmCIOo7XYPeBjptnd9tcFB8mU4jagi5PyktFK5YeiRyP0KqYePOvQaDBf6hObAn /gBW89G+vTN7cLYoXp7yTbFWUXwhLZ05hFhSO/5FaJT3HleVOdU9gPaaDT/9YzAQ5y2c aWQxi8jjdYkO6qrMAojQA9QnVrk4Nomh0j+ov8VVo/3B5kzt3U068TRYkopt5x1LTwH6 XBr/QwEyBL/u8XLqsZpO05/VIZuP4qIY1Vo6C3UeA67uJJZE/xMeZzvaGsINtx6puv/D lg6A== X-Gm-Message-State: AHQUAuZs/poWfj55UACuFXIwxfKoXZs0Cp1rwIGEDqGM+ncCrlc7/QTU mnmpfoaLor2maoTz7e20r+2vXqhWkoSTiQbu0QzgWw== X-Google-Smtp-Source: AHgI3IbIUFGkHDrxxzjYqp57p8WIStFhDUmccuN45AzHXseY2btjcLwMERLIHF6JUDd0zsgzqP08VIbp3W/R4XjV2rE= X-Received: by 2002:a0c:9ba7:: with SMTP id o39mr9651109qve.153.1551127663625; Mon, 25 Feb 2019 12:47:43 -0800 (PST) MIME-Version: 1.0 References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223091931.GE2420@kib.kiev.ua> <20190223163619.GA18805@troutmask.apl.washington.edu> <20190224012851.GA21748@troutmask.apl.washington.edu> <20190224102726.746adb9f@kalimero.tijl.coosemans.org> <20190224175827.GB26240@troutmask.apl.washington.edu> In-Reply-To: <20190224175827.GB26240@troutmask.apl.washington.edu> From: Warner Losh Date: Mon, 25 Feb 2019 13:47:32 -0700 Message-ID: Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: Steve Kargl Cc: =?UTF-8?Q?T=C4=B3l_Coosemans?= , Konstantin Belousov , FreeBSD Current , Peter Holm , Mark Johnston X-Rspamd-Queue-Id: 4D88F81026 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=j0+KZy9J X-Spamd-Result: default: False [-1.24 / 15.00]; RCPT_COUNT_FIVE(0.00)[6]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.82)[-0.822,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.71)[0.707,0]; NEURAL_HAM_LONG(-0.98)[-0.982,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.14)[ip: (4.05), ipnet: 2607:f8b0::/32(-2.66), asn: 15169(-2.00), country: US(-0.07)] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 20:47:45 -0000 On Sun, Feb 24, 2019 at 10:58 AM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Sun, Feb 24, 2019 at 10:06:53AM -0700, Warner Losh wrote: > > > > > > > Maybe I missed it, but Steve, did you run the patched in a different way > > tests that I suggested? Replacing the limits with 0xffffffff for testing > > purposes to ensure that drm isn't saying it can cope with larger > addresses? > > That might help narrow down what the problem here one more level than > "It's > > PAE". > > > > So, I dug through the code a bit. Niclas changed the port to > use BUS_SPACE_MAXADDR. This is defined in include/x86/bus.h > > #if defined(__amd64__) || defined(PAE) > #define BUS_SPACE_MAXADDR_48BIT 0xFFFFFFFFFFFFULL > #define BUS_SPACE_MAXADDR 0xFFFFFFFFFFFFFFFFULL > #else > #define BUS_SPACE_MAXADDR 0xFFFFFFFF > #endif > > I don't know if defined(PAE) is effected by hw.above4g_allow, > or where it gets defined or if it is defined. > Grepping suggests that PAE isn't defined w/o the option. The option is only in the PAE kernel, so maybe my test wouldn't say anything useful and it's a different issue. Warner From owner-freebsd-current@freebsd.org Tue Feb 26 02:05:06 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19094152228C for ; Tue, 26 Feb 2019 02:05:06 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [96.73.9.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D19DE8F3F8 for ; Tue, 26 Feb 2019 02:05:04 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 0778678CE7 for ; Mon, 25 Feb 2019 19:05:47 -0700 (MST) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LTw-2-L7H-Ba for ; Mon, 25 Feb 2019 19:05:46 -0700 (MST) Received: from photon.int.bluestop.org (gw.bluestop.org [96.73.9.3]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA for ; Mon, 25 Feb 2019 19:05:46 -0700 (MST) To: freebsd-current@freebsd.org From: Rebecca Cran Subject: i386 EFI booting is broken (ExitBootServices called in two places) Message-ID: Date: Mon, 25 Feb 2019 19:04:56 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: D19DE8F3F8 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.88 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bluestop.org:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-2.93)[ip: (-9.74), ipnet: 96.64.0.0/11(-4.29), asn: 7922(-0.56), country: US(-0.07)]; DKIM_TRACE(0.00)[bluestop.org:+]; DMARC_POLICY_ALLOW(-0.50)[bluestop.org,quarantine]; MX_GOOD(-0.01)[mail.bluestop.org]; NEURAL_HAM_SHORT(-0.94)[-0.937,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7922, ipnet:96.64.0.0/11, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 02:05:06 -0000 I've been working on some EFI changes, and in the process found that i386 booting is broken. On real hardware - my MinnowBoard Turbot - the loader hangs when calling ExitBootServices, while in a VM I get a panic saying "exec returned". The problem appears to be that ExitBootServices is called twice: elf32_exec in arch/i386/efimd.c calls bi_load which calls bi_load_efi_data in bootinfo.c - which calls ExitBootServices the first time. Then elf32_exec keeps going, and after printing "Start @ 0x....." calls ldr_enter which tries to call ExitBootServices again - this time with a mapkey whose value is zero since it never attempts to fetch the memory map. I'm guessing that subsequently causes the exec to fail. -- Rebecca Cran From owner-freebsd-current@freebsd.org Tue Feb 26 02:58:32 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8701715039FA for ; Tue, 26 Feb 2019 02:58:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15A5692E4A for ; Tue, 26 Feb 2019 02:58:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 97F4D17B6C for ; Tue, 26 Feb 2019 02:58:31 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f46.google.com with SMTP id q12so8528553lfm.0 for ; Mon, 25 Feb 2019 18:58:31 -0800 (PST) X-Gm-Message-State: AHQUAuYUJkiCMl8j6zUP787YgJyueyH7DCB8DGdPkc0Mshc/vOXos9Db CkbpgdTMNjrt5XlqjctbETMOjE9UONZ7wzGJRJA= X-Google-Smtp-Source: AHgI3IaOzbUQNjblGBm4nJbHzlo3+rMsKCEqqqOeP4/WkdXGyhwJ4/lB7CWNj+NYvFFeg1g0A8XTYOPgTEvekPC7TNE= X-Received: by 2002:a19:c50c:: with SMTP id w12mr12214459lfe.53.1551149910132; Mon, 25 Feb 2019 18:58:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Mon, 25 Feb 2019 20:58:18 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: i386 EFI booting is broken (ExitBootServices called in two places) To: Rebecca Cran Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 15A5692E4A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 02:58:32 -0000 On Mon, Feb 25, 2019 at 8:18 PM Rebecca Cran wrote: > > I've been working on some EFI changes, and in the process found that > i386 booting is broken. On real hardware - my MinnowBoard Turbot - the > loader hangs when calling ExitBootServices, while in a VM I get a panic > saying "exec returned". > > The problem appears to be that ExitBootServices is called twice: > elf32_exec in arch/i386/efimd.c calls bi_load which calls > bi_load_efi_data in bootinfo.c - which calls ExitBootServices the first > time. Then elf32_exec keeps going, and after printing "Start @ 0x....." > calls ldr_enter which tries to call ExitBootServices again - this time > with a mapkey whose value is zero since it never attempts to fetch the > memory map. I'm guessing that subsequently causes the exec to fail. > efimd.c should be garbage collected and the ldr_enter called removed. r328169 removed the copy of bootinfo that demonstrated the expected ordering: bi_load returned ldr_bootinfo(), then elf32_exec finished it off with ldr_enter. These details are captured in MI bootinfo bits nowadays and none of this is of use in the current world. From owner-freebsd-current@freebsd.org Tue Feb 26 05:10:05 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FD50150AB45 for ; Tue, 26 Feb 2019 05:10:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 446E76AC19; Tue, 26 Feb 2019 05:10:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1Q59uor062658 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 25 Feb 2019 21:09:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1Q59uqB062657; Mon, 25 Feb 2019 21:09:56 -0800 (PST) (envelope-from sgk) Date: Mon, 25 Feb 2019 21:09:56 -0800 From: Steve Kargl To: =?utf-8?Q?T=C4=B3l?= Coosemans Cc: Warner Losh , Konstantin Belousov , FreeBSD Current , Peter Holm , Mark Johnston Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190226050956.GA62632@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223091931.GE2420@kib.kiev.ua> <20190223163619.GA18805@troutmask.apl.washington.edu> <20190224012851.GA21748@troutmask.apl.washington.edu> <20190224102726.746adb9f@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190224102726.746adb9f@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 446E76AC19 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.18 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.92)[0.915,0]; NEURAL_HAM_LONG(-0.28)[-0.278,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.80)[0.798,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.05)[ip: (0.11), ipnet: 128.95.0.0/16(0.16), asn: 73(0.06), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 05:10:05 -0000 On Sun, Feb 24, 2019 at 10:27:26AM +0100, Tijl Coosemans wrote: > On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl > wrote: > > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: > >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl > >> wrote: > >>> Supposely, the laptop only has 4 GB of memory. Not sure how > >>> it finds memory above 4 GB. > >> > >> Some older chipsets had a 'hole' in memory that they mapped the PCI bus > >> into and then remapped RAM in that range up above the 4GB boundary. That's > >> how it can find memory above 4GB when you have only 4GB of RAM. I hit it > >> with the PC Card stuff I did back in the day since it broke certain > >> heuristics I had in the code that turned out to be unwise for many reasons > >> (not just this one). I don't recall all the details, since it's been so > >> long ago. > >> > >> So I think kib@ is right when he highlights > >>> +0x0000000100000000 - 0x000000011ffe7fff, 536772608 bytes (131048 pages) > >> > >> as the memory, since this is indeed above the 4GB limit. It's about 128k > >> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly > >> round number. Also one that's easy to implement in hardware. So it > >> certainly "smells" the same... > >> > >> That's why I agree with others that hw.above4g_allow=0 is worth a shot, for > >> at least diagnostic purposes. This memory wasn't used before and if it's > >> used now by the drm drivers, and those aren't PAE safe (meaning they cope > >> with allocations beyond 4GB), then that's quite useful to know. Or maybe > >> it's a different driver hating things and stomping on video memory due to > >> wrap around. > > > > Thanks for the explanation. Here's an update. TL;DR: xorg is > > up and running; drm-legacy-kmod seems to be unsafe/unaware of > > PAE. > > > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > > Kernel is unmodified GENERIC. > > > > Reboot without setting anything in /boot/loader.conf > > > > % sysctl -a | grep above > > % sysctl -a | grep pae > > vm.pmap.pae_mode: 1 > > % kldload /boot/modules/i915kms.ko > > > > Black screen of death. Did not even get to running xinit. > > > > Hard reset to single user mode. > > > > # fsck -y > > # mount -a > > # vi /boot/loader.conf. > > (Add hw.above4g_allow=0) > > # sync > > # shutdown -r now > > > > % sysctl -a | grep above > > % sysctl -a | grep pae > > vm.pmap.pae_mode: 1 > > % cat /boot/loader.conf > > if_ath_load="YES" > > if_ath_pci_load="YES" > > cpuctl_load="YES" > > hw.above4g_allow=0 > > % kldload /boot/modules/i915kms.ko > > > > Switch to vt3, login as normal user. > > > > % startx -- -depth 24 >& ~/tmp/.x.out > > > > Xorg is up and running. Not sure why my first attempt at using > > hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg > > bits and kernel/world bits. > > > > % sysctl -a | grep mem > > vm.lowmem_period: 10 > > vm.kmem_map_free: 1669365760 > > vm.kmem_map_size: 41910272 > > vm.kmem_size_scale: 1 > > vm.kmem_size_max: 1711276032 > > vm.kmem_size_min: 12582912 > > vm.kmem_zmax: 65536 > > vm.kmem_size: 1711276032 > > hw.physmem: 3715489792 > > hw.usermem: 3592175616 > > hw.realmem: 4294963200 > > > > % dmesg | grep memory > > real memory = 4294967296 (4096 MB) > > avail memory = 3637673984 (3469 MB) > > agp0: aperture size is 256M, detected 7676k stolen memory > > > > The pre-r343567 dmesg has > > > > real memory = 4294967296 (4096 MB) > > avail memory = 3639914496 (3471 MB) > > > > I can live with 2 MB loss. > > > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > > > Probably want to put something in /usr/src about possible > > problems with new pmap.h on i386 FreeBSD. > > Now it would be interesting to do the same tests with drm-current-kmod. Caveats: old laptop and I only rebuilt drm-current-kmod and the gpu-firmware-kmod. drm-current-kmod does not work. The setting of hw.above4g_allow is immaterial. -- Steve From owner-freebsd-current@freebsd.org Tue Feb 26 22:54:34 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB9751507087 for ; Tue, 26 Feb 2019 22:54:33 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-yw1-f66.google.com (mail-yw1-f66.google.com [209.85.161.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE50980022 for ; Tue, 26 Feb 2019 22:54:32 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-yw1-f66.google.com with SMTP id s204so6584158ywg.2 for ; Tue, 26 Feb 2019 14:54:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Wk7odRJLPnAWnxaxeHiqbNDY7PJ/4nKc2QhqP4jC0vU=; b=eBjJ+qKlthopi5BI15c6h27Q2MqaSFeNIIrQST9ZRSmjsabDY9Vd2iLWBZdagwWYiF cyPJtI5gZ6iEJyOmIESfBc/y93V/nT05nCPutttaZgXZHkwEB/Jh4UBGyOLUW1fAcrzL UNkeaSQhvDsw3KkJcMY6LLhVPebkM+IGyFVwqyadsKNuJPZRsw2IcZRX7hQ3OYSjugsh QnVyOeM0xuKWcVd8aM47vt3IpUz6sKvyeK4gzkzfojPb781RL0+axW8+8rEr8IDW7UNK 4UqTIYfv3m2MNOnENuUe6GJnmYkVuSGaWg4btMHJmi5/oVxW+8O4nhIaLy/ds1F4bJJQ DywQ== X-Gm-Message-State: AHQUAuZuP+O1h9TKLC7V3te12hn8ceNpVYs02ws0gz3OZjFlPe+RXQ87 R/A2rAjQU9RiIn3QpSUsD/agyNuZB1nFLGBDjPs= X-Google-Smtp-Source: AHgI3IajoOq9JD3nHYedEAnyZqCTJRf//2Zmda+1ZlhSWw0AKRu8Mgd2YmEtq9A9SvUz2G6ADvy51xKI3V8MZSuCx8A= X-Received: by 2002:a25:25d4:: with SMTP id l203mr6197359ybl.490.1551221344158; Tue, 26 Feb 2019 14:49:04 -0800 (PST) MIME-Version: 1.0 From: Li-Wen Hsu Date: Wed, 27 Feb 2019 06:48:48 +0800 Message-ID: Subject: FreeBSD CI Weekly Report 2019-02-24 To: freebsd-testing@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: BE50980022 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of lwhsufreebsd@gmail.com designates 209.85.161.66 as permitted sender) smtp.mailfrom=lwhsufreebsd@gmail.com X-Spamd-Result: default: False [-3.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.76)[-0.759,0]; RCVD_IN_DNSWL_NONE(0.00)[66.161.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.18)[ipnet: 209.85.128.0/17(-3.81), asn: 15169(-2.01), country: US(-0.07)]; FORGED_SENDER(0.30)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; DMARC_NA(0.00)[freebsd.org]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FORGED_RECIPIENTS(0.00)[freebsd-testing@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Mailman-Approved-At: Wed, 27 Feb 2019 00:22:09 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 22:54:34 -0000 (bcc -current and -stable for more audience) FreeBSD CI Weekly Report 2019-02-24 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-02-18 to 2019-02-24. During this period, we have: * 2214 builds (98.7% passed, 1.3% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 575 test runs (32.2% passed, 65.5% unstable, 2.3% exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 7 doc buils (100% passed) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. Web version of this report is available at https://hackmd.io/s/rJAJu2RSE and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * lib.libc.sys.sendfile_test.hdtr_positive_v4 * lib.libc.sys.sendfile_test.hdtr_positive_v6 Fixed (Remove expected failure) in https://svnweb.freebsd.org/changeset/base/344310 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * common.rates.t_dtrace_contrib.tst_switchrate_d * common.syscall.t_dtrace_contrib.tst_args_d * common.ip.t_dtrace_contrib.tst_ipv4localsctp_ksh * common.ip.t_dtrace_contrib.tst_localsctpstate_ksh * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sbin.bectl.bectl_test.bectl_mount * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/ * usr.bin.procstat.procstat_test.kernel_stacks * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * usr.bin.procstat.procstat_test.kernel_stacks * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * usr.bin.procstat.procstat_test.command_line_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Open Issues ### Cause build fails * [233339: genassym.o build race](https://bugs.freebsd.org/233339) * Patch available: https://people.freebsd.org/~bdrewery/patches/PR233339.diff * [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory](https://bugs.freebsd.org/233735) * [233769: Possible build race: ld: error: unable to find library -lgcc_s](https://bugs.freebsd.org/233769) ### Others [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) ## Other News * After creating pipeline for clang800-import branch in project/, now we support adding pipeline for other projects. Please contact jenkins-admin through "Testing & CI" component of "Services" product on https://bugs.freebsd.org From owner-freebsd-current@freebsd.org Wed Feb 27 19:09:09 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B17C1502359 for ; Wed, 27 Feb 2019 19:09:09 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 420398B110 for ; Wed, 27 Feb 2019 19:09:07 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.1.226]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lq9oW-1hTkd82GDw-00dkZJ for ; Wed, 27 Feb 2019 20:08:58 +0100 Date: Wed, 27 Feb 2019 20:08:24 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: 12-STABLE revision 344629: pid 26 (sh), jid 0, uid 0: exited on signal 11 Message-ID: <20190227200851.4e794d89@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:XgguACBR7FbYn6hudSRBjkRC9hSHQ7UUFyc9Ow7JkCNj28L9qQ2 Ez2u99hYEKqLgeoMA09Ye4XXU2qlXRCoQ8HyKXNlnksvu8qxn+HgCOmevgbTUwp4vHifx2t Ssqo59iSKm/ox5z3AWzla7BdaUT5TFEJxVFDTrcPh7Q7USOCoA17ibaO0AVIIOPaz6Dp9F4 7hhSZTFXrJrf0mdXWh4sg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:EnuwIhl8BQM=:1Vd4EKxB3vmbtfN7PwPLCA imhyU1pogCAJj3BSayt2nBuTu4CKTcHaur9um6Ik04D1CTgWBNBMpkSOdR3EXTPXindnQb6L2 XArLpFwkTa1976NisAuWttHiu3fZCS8WSuM+vdzFXS5f83dR89zr9iOhhtaZlAP7NI6Btoe0r uDyZBwBy44vRN7gv3mMo+tEO4UG9UNG8oit5Mud27At5bUHVci1LWX1SIR0lsm9Ushu/9VCtD BVMdmWbc1UWly7wOsgLZalBzJRC0VJiv65P16v+yN01o+NhHigyv1iegZG0peIes0ZeFZZVq/ SIWW33ory2CLESOgJgbf2qtIsIqDhKHM4Q4ss19cGvEr5c63fwSc4Stx/Yrp6rfRR6+/LKQq+ MYvA4JeF96BTqnDeR0WCXyxMJHqAeV+yNBwW9JfkEIQG3Ncxhgyyye5aOZ787GZZp/ZNDSQl8 H0SeqjSqsnbZBY3s8cwVSLR8NKksOEIUpsYEZZDzCIlQne6HwwiqcEk9CnDSAXKYFYBwLV+p8 z/nIYnSNwyo94KkuBAK2iP1N4HUwfMFIeD2F3Ker05yfwbGwyhEfgHD1227f8Wv3EcJryOMTG 1S8L04Tdf+hnEUJ+55I025mE82xUOTQA0mjQB2EC9j6SGFrO6yPPiczV1gr0032Az0Lur/rVo Ygm9Wc4g9lwVRgo5IumJrVWeS4B8aex3IQKk5TvHjXi+yPnMQyYxSDkkPtY1U6YiZfk1hKFxA ZqurqLC0CEKfFTLAeNq/lKMc7jA5HnwQQcnS3dNLtyd7zPJRWkWGIttSlUsFRKZFu/8LlFZM5 +FHKMWVZJhBg6Xr2Rs8oL/5nFSM3/Sn65XLinxCgGR0D2c84baBbHVxFfsPU+m0gf21o1STSf Wnx52OEM7q03HKIHqgmRdOMCn5zx+oiAMHPJ1b8JLzUpAGBDMfRDr7iUzYZgu12HuR/PIObi3 nZIo6Rc6lAw== X-Rspamd-Queue-Id: 420398B110 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.23 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx00.gmx.net,mx01.gmx.net]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-0.33)[-0.325,0]; RCVD_IN_DNSWL_LOW(-0.10)[15.15.227.212.list.dnswl.org : 127.0.3.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; IP_SCORE(-0.81)[ip: (-4.88), ipnet: 212.227.0.0/16(-0.96), asn: 8560(1.80), country: DE(-0.01)]; RECEIVED_SPAMHAUS_PBL(0.00)[226.1.55.78.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.985,0]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 19:09:09 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNClJ1bm5p bmcgMTItU1RBQkxFIGFuZCBDVVJSRU5UIG9uIGEgUENlbmdpbmUgQVBVNEMgKENQVTogQU1EIEdY LTQxMlRDIFNPQywgIENvcmVib290IFZlcnNpb246DQp2NC45LjAuMiksIEkgcmFuIGludG8gdHJv dWJsZSBydW5uaW5nIGxhdGVzdCAxMi1TVEFCTEUgb24gdGhhdCBoYXJkd2FyZS4NCg0KVGhlIGJv eCBpcyBxdWl0dGluZyB3aXRoDQoNCg0KWy4uLl0NCm1tY3NkMDogMzFHQiA8U0RIQyBTRDMyRyAz LjAgU04gMDE4MDEyOTkgTUZHIDA5LzIwMTUgYnkgMzkgUEg+IGF0IG1tYzAgNTAuME1Iei80Yml0 LzY1NTM1LWJsb2NrDQphZGEwIGF0IGFoY2ljaDAgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAw DQphZGEwOiA8VFM2NEdNU0EzNzAgTzEyMjVHPiBBQ1MtMiBBVEEgU0FUQSAzLnggZGV2aWNlDQph ZGEwOiA2MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMy54LCBVRE1BNiwgUElPIDEwMjRieXRl cykNCmFkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZA0KYWRhMDogNjEwNTdNQiAoMTI1MDQ1 NDI0IDUxMiBieXRlIHNlY3RvcnMpDQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2 L2dwdC9kc2tzMWEgW3JvXS4uLg0KVENQIEhwdHMgY3JlYXRlZCA0IHN3aSBpbnRlcnJ1cHQgdGhy ZWFkIGFuZCBib3VuZCAwDQp1aHViMTogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQNCnBpZCAyNiAoc2gpLCBqaWQgMCwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwgMTENCjIw MTktMDItMjdUMTk6NDI6MzUuNzIxODg1KzAxOjAwICBpbml0IDEgLSAtIC9iaW4vc2ggb24gL2V0 Yy9yYyB0ZXJtaW5hdGVkIGFibm9ybWFsbHksIGdvaW5nDQp0byBzaW5nbGUgdXNlciBtb2RlIEVu dGVyIHJvb3QgcGFzc3dvcmQsIG9yIF5EIHRvIGdvIG11bHRpLXVzZXINClBhc3N3b3JkOg0KdWh1 YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1Z2VuMS4yOiA8dmVu ZG9yIDB4MDQzOCBwcm9kdWN0IDB4NzkwMD4gYXQgdXNidXMxDQp1aHViMiBvbiB1aHViMA0KdWh1 YjI6IDx2ZW5kb3IgMHgwNDM4IHByb2R1Y3QgMHg3OTAwLCBjbGFzcyA5LzAsIHJldiAyLjAwLzAu MTgsIGFkZHIgMj4gb24gdXNidXMxDQp1aHViMjogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQNCnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuDQphcmM0cmFuZG9tOiBubyBw cmVsb2FkZWQgZW50cm9weSBjYWNoZQ0KYXJjNHJhbmRvbTogbm8gcHJlbG9hZGVkIGVudHJvcHkg Y2FjaGUNClsuLi5dDQoNCg0KLi4uIGFuZCB3aGVuIHR5cGluZyB0aGUgcGFzc3dvcmQsIHRoZSBw cm9tcHRlciBpcyBpbW1lZGlhdGVseSBhdA0KDQoyMDE5LTAyLTI3VDE5OjQyOjM1LjcyMTg4NSsw MTowMCAgaW5pdCAxIC0gLSAvYmluL3NoIG9uIC9ldGMvcmMgdGVybWluYXRlZCBhYm5vcm1hbGx5 LCBnb2luZw0KdG8gc2luZ2xlIHVzZXIgbW9kZSBFbnRlciByb290IHBhc3N3b3JkLCBvciBeRCB0 byBnbyBtdWx0aS11c2VyDQpQYXNzd29yZDoNCg0KDQpSdW5uaW5nIA0KDQpGcmVlQlNEIDEyLjAt U1RBQkxFICMzNiByMzQzODcxOiBUaHUgRmViICA3IDE3OjM0OjQ0IENFVCAyMDE5IGFtZDY0DQoN CkRvZXNuJ3Qgc2hvdyB0aGlzIHBoZW5vbWVub24gd2l0aCB0aGUgdmVyeSBzYW1lIGNvbmZpZ3Vy YXRpb24gYW5kIGtlcm5lbC4NCg0KDQoNCi0gLS0gDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVS RS0tLS0tDQoNCmlIVUVBUllJQUIwV0lRU3k4SUJ4QVBEa3FWQmFUSjQ0TjFaWlBiYTVSd1VDWEhi Z1F3QUtDUkE0TjFaWlBiYTUNClI3WUFBUDlVZGoxd0I5bnE1MzFWU1FhN0J3M1p2R2RicDFqOE1h S1VuTzlpUTcva0pnRUFrRnE2amRuMVNVN1UNClJ3VlhtQXZOV3FjRDBZSEpualg2TlppTHhmbytn d2s9DQo9WHY3bA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-current@freebsd.org Wed Feb 27 19:19:09 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6323615026FB for ; Wed, 27 Feb 2019 19:19:09 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ACDC8B78E for ; Wed, 27 Feb 2019 19:19:07 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wr1-x441.google.com with SMTP id i16so19242658wrs.13 for ; Wed, 27 Feb 2019 11:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=tfJCauM0yUPfmcc45vWYhGcYeg/X15WpG7ZgsyQaTu8=; b=TG2jgy/0X50TlTcaPoE0vRo+6ud3C7Wm1d/ynrXhaHQT4EB9fh+yE0VJ41nFrgRb0T rfKAlMBQJkF1ed7BrScwathX8X7KzjtZBsqdB2YGpNNeAM8eRl8nqD2QZl3MSdJQu/v/ bs+5R3xW+uVo6Jk+hk/zsy9QgVUXa7EcjNVYZC+EDpt6FvM4pNASwjTcK3DHb7O21czK LHMbPpQ1MqggOzwTrONFHg906QVkqIfD1MJxSuxM7GSMzszICQy/G6T3UApNsmwWX7yE wsGfec10cjG1ODQg/INcTYP7MIVE6+DbGQgUwv9qXzdrUOJwcSS7DlY02i9Iq5Vuzap8 kK9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tfJCauM0yUPfmcc45vWYhGcYeg/X15WpG7ZgsyQaTu8=; b=DWjr/P6Ba6p6omhiO/jwl++3VvZHsmaxlu8UsnBbOijwo/DK58JsP3z7p1Uy+Veoy7 jDTpZWMIEao3zIeZgRNoxPiNCGKO8lnwbGTCuzGirZTDeGlBgdGrfuAaVe/j4jJLWKJm X43ac0qnqIhmjt0z0TsCVP8wDBaISa/1HWC88F6DocHjSN0gp6iE6A2Kt0SO4pvO59Ri 7J1X13r2O78ULQ8gQYOe/UExIMfEMJUP+LB2PTSYBFLcpDMBCN7BEbEeLkAGY4fGhB6w iqcKWYY1GxJT3+Tye6f/ZOFr26jeZP0S9hU4aJaW0jxryoj+aHlhlEi6gaWahu4ruKz+ Zgfw== X-Gm-Message-State: APjAAAXcVpYuB0gp9+5S62uhV68D5jpqp+sWImA6YJG6X71XEwmcEnwq obkC3OSQMjHLGZLemP2vIJHcV0b3qo0+iQ== X-Google-Smtp-Source: APXvYqxNzUp/Gge7LIuRwTt0bKDeh772Ko2ZiM1gTXnZOkghgpQ5fCCGjbq3VKvsYx/QmLdn+0UtIg== X-Received: by 2002:adf:e647:: with SMTP id b7mr3554050wrn.260.1551295146703; Wed, 27 Feb 2019 11:19:06 -0800 (PST) Received: from mutt-hbsd ([137.74.167.96]) by smtp.gmail.com with ESMTPSA id z8sm2092955wmi.28.2019.02.27.11.19.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Feb 2019 11:19:05 -0800 (PST) Date: Wed, 27 Feb 2019 14:18:28 -0500 From: Shawn Webb To: "O. Hartmann" Cc: FreeBSD CURRENT Subject: Re: 12-STABLE revision 344629: pid 26 (sh), jid 0, uid 0: exited on signal 11 Message-ID: <20190227191828.evlr67yv4uwreslv@mutt-hbsd> References: <20190227200851.4e794d89@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eyiu6z5tcoe7tz4t" Content-Disposition: inline In-Reply-To: <20190227200851.4e794d89@thor.intern.walstatt.dynvpn.de> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD HARDENEDBSD-13-CURRENT amd64 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: 7ACDC8B78E X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=TG2jgy/0; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2a00:1450:4864:20::441 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-2.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.936,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; IP_SCORE(-0.54)[ip: (1.64), ipnet: 2a00:1450::/32(-2.26), asn: 15169(-2.02), country: US(-0.07)]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(3.00)[96.167.74.137.zen.spamhaus.org : 127.0.0.4]; R_DKIM_ALLOW(0.00)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MID_RHS_NOT_FQDN(0.50)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 19:19:09 -0000 --eyiu6z5tcoe7tz4t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2019 at 08:08:24PM +0100, O. Hartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Running 12-STABLE and CURRENT on a PCengine APU4C (CPU: AMD GX-412TC SOC,= Coreboot Version: > v4.9.0.2), I ran into trouble running latest 12-STABLE on that hardware. >=20 > The box is quitting with >=20 >=20 > [...] > mmcsd0: 31GB at mmc0 50= =2E0MHz/4bit/65535-block > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > ada0: Command Queueing enabled > ada0: 61057MB (125045424 512 byte sectors) > Trying to mount root from ufs:/dev/gpt/dsks1a [ro]... > TCP Hpts created 4 swi interrupt thread and bound 0 > uhub1: 4 ports with 4 removable, self powered > pid 26 (sh), jid 0, uid 0: exited on signal 11 > 2019-02-27T19:42:35.721885+01:00 init 1 - - /bin/sh on /etc/rc terminate= d abnormally, going > to single user mode Enter root password, or ^D to go multi-user > Password: > uhub0: 2 ports with 2 removable, self powered > ugen1.2: at usbus1 > uhub2 on uhub0 > uhub2: o= n usbus1 > uhub2: 4 ports with 4 removable, self powered > random: unblocking device. > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > [...] >=20 >=20 > ... and when typing the password, the prompter is immediately at >=20 > 2019-02-27T19:42:35.721885+01:00 init 1 - - /bin/sh on /etc/rc terminate= d abnormally, going > to single user mode Enter root password, or ^D to go multi-user > Password: >=20 >=20 > Running=20 >=20 > FreeBSD 12.0-STABLE #36 r343871: Thu Feb 7 17:34:44 CET 2019 amd64 >=20 > Doesn't show this phenomenon with the very same configuration and kernel. Have you enabled retpoline? There are known issues with ifunc in libc and retpoline. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --eyiu6z5tcoe7tz4t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlx24n8ACgkQaoRlj1JF bu5wDxAAompsxJd+Tm0lIeKMNilUvcDfoaxlagj7FLHMinROCW4SfPwiggj9qlRI SdDwfdMz5XdlZcunMspBSPS4DwNXdDHQt59i+GCduP3jG0ZQvpWdVaI/0UU0lQxS jcblJ+SLGxCP/bzH0Xq5I3LMVVraEe4a+IynCPjHeXRyYbYuDoN2Byy0KbwQz68s Z8zfK1JZUSRaDcxmo7DWcbGq34WeanrQ+2HDQVQBXrn3Zn+h5KdmxlRIH7N+OZgU o4ibPt9t7OBCjTbzka5Bj4tFxQfufOkYFLUkqzTsCSfi/72RE1vqj3pw1VXwTJ5G 6CbJkjb0OFINscD7a9cgFYKTZm5+ZvS6jXkmQVRJfIs0mpmFq3nJ/Y/NuM9FCcSR +KgXEcgFbcunUaZKgsZ97nSf/lle9OoAOn84odAlWM7IO1o95EfsbUEhW8ewjC23 natITeNgB/+f2Izy1Ygs+Jg/LiyhGwRft/8e6K7noYkBoWNIZO+WaVo3Uf0YunSC mS3DAoZOaZzO1geIJLgjliodQ9zJlKoEIHXeb3ND8iHjkzZGGkt7eN8Z3AoLLzoq MQRuy6zBiWjo019Vgvjwyq131mk+43eUo4/aQl2GZ4zL/29cn4FsUgpJWWcFJ5KF /0KbL9YH71qhmMfi1s+8GoNtg7IPTqaQw409nio4SLhZM5dlZp0= =tneW -----END PGP SIGNATURE----- --eyiu6z5tcoe7tz4t-- From owner-freebsd-current@freebsd.org Wed Feb 27 20:40:29 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1273A15049AC for ; Wed, 27 Feb 2019 20:40:29 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 097798ECEB for ; Wed, 27 Feb 2019 20:40:27 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([89.12.154.239]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lt1eU-1h9JaH45Sk-012cAo; Wed, 27 Feb 2019 21:40:24 +0100 Date: Wed, 27 Feb 2019 21:39:48 +0100 From: "O. Hartmann" To: Shawn Webb Cc: FreeBSD CURRENT Subject: Re: 12-STABLE revision 344629: pid 26 (sh), jid 0, uid 0: exited on signal 11 Message-ID: <20190227214015.6ddd0785@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20190227191828.evlr67yv4uwreslv@mutt-hbsd> References: <20190227200851.4e794d89@thor.intern.walstatt.dynvpn.de> <20190227191828.evlr67yv4uwreslv@mutt-hbsd> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:7Q9BZOFBsSjDmcVMrCFlRfB5KDcfOgg5xMSxPRmBnAG+Is8xxI0 xIaPvwxaIh33bVCPKWtIFqfpQnwJhM2uUItYnVdvnUPsTBa4EqUO8nbGsjnB8h9XF1sVo8T hddgQk24DoWym2Gyam0q47HEwXdTgXJzmSJZQ4tcEKUFCTMw/K9VKD9lZKheqN2wBoBGGpD ovDWHCI+gXRJQbOUe5Q2w== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:muMUtZK+XmI=:2FUiLk3q1XuAThLDudw+4m GHqBByIwehFAx/36ICHZafut/x2nVdr45NoJi1vUipqJqkPcDzvGE2C48r7BiMCjDSniLQS2r XAwm7YTOjejONxaNUspS0wOpmfcVC7hhimWw0mStA7uhp2qENjcfBnx24cN73WmdvkyEGHDol VKc/TiEWTfy5uLXEMEO7OpHBeJYyQkghLMjPYXTqkcr7vil/RqmKCm5RSRT4tjMVfwwZOezoh I4WAnIlCb1U+GaiKxGFWfS3aYtHD69IMQWbfkyLcPgV/pR7U8GcOKf6unj+gngGFXxAAbj0f4 eac1iLx5lMTrc0h8YLK9kp5IyKpnPcBqmL4QJToEmDYUBl0/4a0NTgpfM0XqRx02qTH+PedSl i5HaxPPdWgP7FSNC6jXI83JMKBm3K6ouuN7YQChEgrBg825br0ucxz5wE5bVlnmZDTfHVc+Gx eb7wLo6kJ60mmiAM/NJwrWLKBgp+yadylXr8fVVCMTrONUfzOY1nNbSPO+ZctyLWwW46JHCBL DpwHNK44H5OwM2u4OU6vNOV9H2yUOO4wy+JhGlSyg0FCoUuWi5E6LVXuezoKCXK+NCOg+PAj4 2XdlRQVK78pePuHpe+pE0uStRfw8UBwJ5FO4N+odz5W+ceX811U0VZI8haSB956HIOZ2GdUG+ Vc9ugNsN6hsURW8mDi+mBNTzjh8qCxEdVrh1YCOFqQ1KBr6jhTz3qt1SOxIQF068mAG1lOIfx pGvBuivRDGkCK7imQ+yCq9KAr1mxEerTBHzhXGLTrV9yaAtxNnCTBwLo89kspaaI8SzTjPBUS mb6gZaSCpaQuSD3OjZR99J4H6Av5AEUPxDbth1PaxwV0gnCeOw7l41CoBlmkdPujB6t7ZxC3F dEv5v7k0zxsMUcst+Cd2GaNoYAR48Hr6PLDvIRHDliFdcMhYbm0jc0J9YQmwtUHIU9T2Mgdc4 qo/bkwkSzEA== X-Rspamd-Queue-Id: 097798ECEB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.09 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; IP_SCORE(-0.78)[ip: (-4.80), ipnet: 212.227.0.0/16(-0.92), asn: 8560(1.81), country: DE(-0.01)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt.org]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx00.gmx.net]; RCPT_COUNT_TWO(0.00)[2]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-0.20)[-0.203,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[15.15.227.212.list.dnswl.org : 127.0.3.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[239.154.12.89.zen.spamhaus.org : 127.0.0.11] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 20:40:29 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkFtIFdl ZCwgMjcgRmViIDIwMTkgMTQ6MTg6MjggLTA1MDANClNoYXduIFdlYmIgPHNoYXduLndlYmJAaGFy ZGVuZWRic2Qub3JnPiBzY2hyaWViOg0KDQo+IE9uIFdlZCwgRmViIDI3LCAyMDE5IGF0IDA4OjA4 OjI0UE0gKzAxMDAsIE8uIEhhcnRtYW5uIHdyb3RlOg0KPiA+IC0tLS0tQkVHSU4gUEdQIFNJR05F RCBNRVNTQUdFLS0tLS0NCj4gPiBIYXNoOiBTSEEyNTYNCj4gPiANCj4gPiBSdW5uaW5nIDEyLVNU QUJMRSBhbmQgQ1VSUkVOVCBvbiBhIFBDZW5naW5lIEFQVTRDIChDUFU6IEFNRCBHWC00MTJUQyBT T0MsICBDb3JlYm9vdA0KPiA+IFZlcnNpb246IHY0LjkuMC4yKSwgSSByYW4gaW50byB0cm91Ymxl IHJ1bm5pbmcgbGF0ZXN0IDEyLVNUQUJMRSBvbiB0aGF0IGhhcmR3YXJlLg0KPiA+IA0KPiA+IFRo ZSBib3ggaXMgcXVpdHRpbmcgd2l0aA0KPiA+IA0KPiA+IA0KPiA+IFsuLi5dDQo+ID4gbW1jc2Qw OiAzMUdCIDxTREhDIFNEMzJHIDMuMCBTTiAwMTgwMTI5OSBNRkcgMDkvMjAxNSBieSAzOSBQSD4g YXQgbW1jMA0KPiA+IDUwLjBNSHovNGJpdC82NTUzNS1ibG9jayBhZGEwIGF0IGFoY2ljaDAgYnVz IDAgc2NidXMwIHRhcmdldCAwIGx1biAwDQo+ID4gYWRhMDogPFRTNjRHTVNBMzcwIE8xMjI1Rz4g QUNTLTIgQVRBIFNBVEEgMy54IGRldmljZQ0KPiA+IGFkYTA6IDYwMC4wMDBNQi9zIHRyYW5zZmVy cyAoU0FUQSAzLngsIFVETUE2LCBQSU8gMTAyNGJ5dGVzKQ0KPiA+IGFkYTA6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZA0KPiA+IGFkYTA6IDYxMDU3TUIgKDEyNTA0NTQyNCA1MTIgYnl0ZSBzZWN0 b3JzKQ0KPiA+IFRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvZ3B0L2Rza3MxYSBb cm9dLi4uDQo+ID4gVENQIEhwdHMgY3JlYXRlZCA0IHN3aSBpbnRlcnJ1cHQgdGhyZWFkIGFuZCBi b3VuZCAwDQo+ID4gdWh1YjE6IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk DQo+ID4gcGlkIDI2IChzaCksIGppZCAwLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCAxMQ0KPiA+ IDIwMTktMDItMjdUMTk6NDI6MzUuNzIxODg1KzAxOjAwICBpbml0IDEgLSAtIC9iaW4vc2ggb24g L2V0Yy9yYyB0ZXJtaW5hdGVkIGFibm9ybWFsbHksDQo+ID4gZ29pbmcgdG8gc2luZ2xlIHVzZXIg bW9kZSBFbnRlciByb290IHBhc3N3b3JkLCBvciBeRCB0byBnbyBtdWx0aS11c2VyDQo+ID4gUGFz c3dvcmQ6DQo+ID4gdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk DQo+ID4gdWdlbjEuMjogPHZlbmRvciAweDA0MzggcHJvZHVjdCAweDc5MDA+IGF0IHVzYnVzMQ0K PiA+IHVodWIyIG9uIHVodWIwDQo+ID4gdWh1YjI6IDx2ZW5kb3IgMHgwNDM4IHByb2R1Y3QgMHg3 OTAwLCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMTgsIGFkZHIgMj4gb24gdXNidXMxDQo+ID4gdWh1 YjI6IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQo+ID4gcmFuZG9tOiB1 bmJsb2NraW5nIGRldmljZS4NCj4gPiBhcmM0cmFuZG9tOiBubyBwcmVsb2FkZWQgZW50cm9weSBj YWNoZQ0KPiA+IGFyYzRyYW5kb206IG5vIHByZWxvYWRlZCBlbnRyb3B5IGNhY2hlDQo+ID4gWy4u Ll0NCj4gPiANCj4gPiANCj4gPiAuLi4gYW5kIHdoZW4gdHlwaW5nIHRoZSBwYXNzd29yZCwgdGhl IHByb21wdGVyIGlzIGltbWVkaWF0ZWx5IGF0DQo+ID4gDQo+ID4gMjAxOS0wMi0yN1QxOTo0Mjoz NS43MjE4ODUrMDE6MDAgIGluaXQgMSAtIC0gL2Jpbi9zaCBvbiAvZXRjL3JjIHRlcm1pbmF0ZWQg YWJub3JtYWxseSwNCj4gPiBnb2luZyB0byBzaW5nbGUgdXNlciBtb2RlIEVudGVyIHJvb3QgcGFz c3dvcmQsIG9yIF5EIHRvIGdvIG11bHRpLXVzZXINCj4gPiBQYXNzd29yZDoNCj4gPiANCj4gPiAN Cj4gPiBSdW5uaW5nIA0KPiA+IA0KPiA+IEZyZWVCU0QgMTIuMC1TVEFCTEUgIzM2IHIzNDM4NzE6 IFRodSBGZWIgIDcgMTc6MzQ6NDQgQ0VUIDIwMTkgYW1kNjQNCj4gPiANCj4gPiBEb2Vzbid0IHNo b3cgdGhpcyBwaGVub21lbm9uIHdpdGggdGhlIHZlcnkgc2FtZSBjb25maWd1cmF0aW9uIGFuZCBr ZXJuZWwuICANCj4gDQo+IEhhdmUgeW91IGVuYWJsZWQgcmV0cG9saW5lPyBUaGVyZSBhcmUga25v d24gaXNzdWVzIHdpdGggaWZ1bmMgaW4gbGliYw0KPiBhbmQgcmV0cG9saW5lLg0KPiANCj4gVGhh bmtzLA0KPiANCg0KDQpJIHdhcyBqdXN0IHByZXBhcmluZyBmdXJ0aGVyIGluZm9ybWF0aW9ucyB3 aGVuIEkgZmFpbGVkIHRvIGdhdGhlciBtb3JlIGluc2lnaHRzIGVuYWJsaW5nIGRlYnVnDQppbmZv IGluIHJjLmNvbmYgd2hlbiB5b3VyIGVtYWlsIGFycml2ZWQuDQoNClllcywgSSB1c2UgTmFub0JT RCBhbmQgYnVpbGQgd29ybGQgd2l0aCB0aGVzZSBzZXR0aW5nczoNCg0KIyBPcHRpb25zIHRvIHB1 dCBpbiBtYWtlLmNvbmYgZHVyaW5nIGJ1aWxkd29ybGQgb25seQ0KQ09ORl9CVUlMRD0nDQojQ0ZM QUdTPS1PMyAtcGlwZSAtRE5ERUJVRw0KQ0ZMQUdTPS1PMiAtcGlwZSAtRE5ERUJVRw0KV0lUSF9L RVJORUxfUkVUUE9MSU5FPVlFUw0KV0lUSF9SRVRQT0xJTkU9WUVTDQpNQUxMT0NfUFJPRFVDVElP Tj1ZRVMNCicNCg0KUmlnaHQgbm93LCBJIGNvbW1lbnRlZCBvdXQgdGhvc2Ugc2V0dGluZ3MgYW5k IHJlY29tcGlsZSB3b3JsZCB3aXRob3V0IFJFVFBPTElORS4NCg0KS2luZCByZWdhcmRzLA0KDQpv aA0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQppSFVFQVJZSUFCMFdJUVN5OElC eEFQRGtxVkJhVEo0NE4xWlpQYmE1UndVQ1hIYjFyd0FLQ1JBNE4xWlpQYmE1DQpSenljQVA5VFVJ V0RMbkpPek45amxLN3ROcmUwd2RwRmxHU1A5ZEg1NkpwM2tqWkF0d0VBa3hLSGVyN0l0dCtFDQpW ZnU2VWE1anhaTVVvaWhiVkVZT3pLZFdMZjVLVGdzPQ0KPVl1eWENCi0tLS0tRU5EIFBHUCBTSUdO QVRVUkUtLS0tLQ0K From owner-freebsd-current@freebsd.org Thu Feb 28 17:09:58 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33132150F35A for ; Thu, 28 Feb 2019 17:09:58 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0371874E1B; Thu, 28 Feb 2019 17:09:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id AC3C61167B; Thu, 28 Feb 2019 17:09:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: sgk@troutmask.apl.washington.edu, Conrad Meyer Cc: freebsd-current References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Thu, 28 Feb 2019 09:09:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190223163947.GB18805@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 0371874E1B X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.95 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.95)[-0.947,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 17:09:58 -0000 On 2/23/19 8:39 AM, Steve Kargl wrote: > On Sat, Feb 23, 2019 at 08:32:23AM -0800, Conrad Meyer wrote: >> On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl >> wrote: >>> Ideas? >>> ... >>> +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) >>> Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 >> >> https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-2-duo-processor-t7250-2m-cache-2-00-ghz-800-mhz-fsb.html >> >>> Intel® Virtualization Technology (VT-x) ‡ Yes >>> Intel® 64 ‡ Yes >> >>> Merom is the first Intel mobile processor to feature Intel 64 architecture. >> >> So, as a workaround, maybe run amd64? > > This is the only i386 FreeBSD system that I have. This > is the system where all the libm changes I've made have > been tested. i386 floating point is different than > amd64 floating point. See npx.c and the history of any > of the long double functions that I've worked on. If > this laptop does not run i386, there will be no testing > of libm changes on the architecture. Yes, but we set the initial FPU control word for 32-bit binaries to match i386 when running i386 binaries under an amd64 kernel. See these comments in sys/x86/include/fpu.h with which you are likely familiar: /* * The hardware default control word for i387's and later coprocessors is * 0x37F, giving: * * round to nearest * 64-bit precision * all exceptions masked. * * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc * because of the difference between memory and fpu register stack arguments. * If its using an intermediate fpu register, it has 80/64 bits to work * with. If it uses memory, it has 64/53 bits to work with. However, * gcc is aware of this and goes to a fair bit of trouble to make the * best use of it. * * This is mostly academic for AMD64, because the ABI prefers the use * SSE2 based math. For FreeBSD/amd64, we go with the default settings. */ #define __INITIAL_FPUCW__ 0x037F #define __INITIAL_FPUCW_I386__ 0x127F #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ #define __INITIAL_MXCSR__ 0x1F80 #define __INITIAL_MXCSR_MASK__ 0xFFBF And this code in ia32_setregs() in sys/amd64/ia32/ia32_signal.c to set the initial register values for i386 processes: /* * Clear registers on exec */ void ia32_setregs(struct thread *td, struct image_params *imgp, u_long stack) { ... pcb->pcb_initial_fpucw = __INITIAL_FPUCW_I386__; ... } This matches what exec_setregs() in sys/i386/i386/machdep.c does: /* * Reset registers to default values on exec. */ void exec_setregs(struct thread *td, struct image_params *imgp, u_long stack) { ... pcb->pcb_initial_npxcw = __INITIAL_NPXCW__; ... } You can do all your tests directly on amd64 by just adding "-m32" to compile i386 binaries against the libraries in /usr/lib32 and you will generate the same i386 binaries as if you were building on an i386 system. If you are a bit more paranoid, you can install an i386 world and chroot into it and use that to test i386. I do this myself (-m32) for testing i386 things. I also run i386 VMs under bhyve on amd64 hosts. I'm not sure your laptop's CPU can run i386 VMs though, and you don't need a VM to test userland-only changes (I'm usually trying to test kernel changes). However, an amd64 kernel is going to be a more stable, better supported kernel for running i386 binaries than an i386 kernel at this point, and that will become even more true in the future. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Feb 28 18:32:24 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1122F1512721 for ; Thu, 28 Feb 2019 18:32:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 89B4180B9A; Thu, 28 Feb 2019 18:32:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1SIWEFh017747 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Feb 2019 10:32:14 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1SIWE7v017746; Thu, 28 Feb 2019 10:32:14 -0800 (PST) (envelope-from sgk) Date: Thu, 28 Feb 2019 10:32:14 -0800 From: Steve Kargl To: John Baldwin Cc: Conrad Meyer , freebsd-current Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190228183214.GA17372@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 89B4180B9A X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.01 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_SPAM_SHORT(0.52)[0.517,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.29)[-0.288,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.10), ipnet: 128.95.0.0/16(0.16), asn: 73(0.06), country: US(-0.07)]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[troutmask.apl.washington.edu]; NEURAL_SPAM_MEDIUM(0.05)[0.045,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 18:32:24 -0000 On Thu, Feb 28, 2019 at 09:09:38AM -0800, John Baldwin wrote: > On 2/23/19 8:39 AM, Steve Kargl wrote: > > On Sat, Feb 23, 2019 at 08:32:23AM -0800, Conrad Meyer wrote: > >> On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl > >> wrote: > >>> Ideas? > >>> ... > >>> +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) > >>> Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > >> > >> https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-2-duo-processor-t7250-2m-cache-2-00-ghz-800-mhz-fsb.html > >> > >>> Intel® Virtualization Technology (VT-x) ‡ Yes > >>> Intel® 64 ‡ Yes > >> > >>> Merom is the first Intel mobile processor to feature Intel 64 architecture. > >> > >> So, as a workaround, maybe run amd64? > > > > This is the only i386 FreeBSD system that I have. This > > is the system where all the libm changes I've made have > > been tested. i386 floating point is different than > > amd64 floating point. See npx.c and the history of any > > of the long double functions that I've worked on. If > > this laptop does not run i386, there will be no testing > > of libm changes on the architecture. > > Yes, but we set the initial FPU control word for 32-bit binaries > to match i386 when running i386 binaries under an amd64 kernel. > > See these comments in sys/x86/include/fpu.h with which you are > likely familiar: > > /* > * The hardware default control word for i387's and later coprocessors is > * 0x37F, giving: > * > * round to nearest > * 64-bit precision > * all exceptions masked. > * > * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc > * because of the difference between memory and fpu register stack arguments. > * If its using an intermediate fpu register, it has 80/64 bits to work > * with. If it uses memory, it has 64/53 bits to work with. However, > * gcc is aware of this and goes to a fair bit of trouble to make the > * best use of it. > * > * This is mostly academic for AMD64, because the ABI prefers the use > * SSE2 based math. For FreeBSD/amd64, we go with the default settings. > */ > #define __INITIAL_FPUCW__ 0x037F > #define __INITIAL_FPUCW_I386__ 0x127F > #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ > #define __INITIAL_MXCSR__ 0x1F80 > #define __INITIAL_MXCSR_MASK__ 0xFFBF > > And this code in ia32_setregs() in sys/amd64/ia32/ia32_signal.c > to set the initial register values for i386 processes: > > /* > * Clear registers on exec > */ > void > ia32_setregs(struct thread *td, struct image_params *imgp, u_long stack) > { > ... > pcb->pcb_initial_fpucw = __INITIAL_FPUCW_I386__; > ... > } > > This matches what exec_setregs() in sys/i386/i386/machdep.c does: > > /* > * Reset registers to default values on exec. > */ > void > exec_setregs(struct thread *td, struct image_params *imgp, u_long stack) > { > ... > pcb->pcb_initial_npxcw = __INITIAL_NPXCW__; > ... > } > > You can do all your tests directly on amd64 by just adding > "-m32" to compile i386 binaries against the libraries in /usr/lib32 > and you will generate the same i386 binaries as if you were building > on an i386 system. If you are a bit more paranoid, you can install > an i386 world and chroot into it and use that to test i386. I do this > myself (-m32) for testing i386 things. I also run i386 VMs under > bhyve on amd64 hosts. I'm not sure your laptop's CPU can run i386 > VMs though, and you don't need a VM to test userland-only changes > (I'm usually trying to test kernel changes). Interesting. Did not know I could use -m32 with any reliability. Setting up my testing environment may be a challenge as I use mpfr/gmp, so would need -m32 aware versions of those libraries. I normally install whatever the port collection offers for mpfr/gmp. I suppose I would need to install those independently to get multilib support. I would also need to compile 2 versions of my testing framework (ie., additional support library). The BIOS does have a enable/disable button for virtualization. During the great drm-legacy-kmod event of the last month, enabling virtualization locks up a i386 FreeBSD kernel very quickly. Perhaps, virtualization works under amd64. Guess I'll burn an image onto a memstick an d give it a whirl. > However, an amd64 kernel is going to be a more stable, better > supported kernel for running i386 binaries than an i386 kernel > at this point, and that will become even more true in the future. This is interesting as well. Does this mean that amd64 is now the only tier 1 platform and all other architectures are after thoughts? -- Steve From owner-freebsd-current@freebsd.org Thu Feb 28 19:07:05 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B0801513B07 for ; Thu, 28 Feb 2019 19:07:05 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f175.google.com (mail-it1-f175.google.com [209.85.166.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D727826C6; Thu, 28 Feb 2019 19:07:04 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f175.google.com with SMTP id v2so16356306ith.3; Thu, 28 Feb 2019 11:07:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=D8LbkVwpZEXJrKQOPZZlBkhplilBqfrDvpjQGhOcYwQ=; b=qDlaMLm81uhkRZZfeUhk7UdSBWqlp2TDglOZzOUmFIxMboVEwCIavpSHLkmKqCA/YC RmlfdJHlGsoB6xzHfJFgOOl2VPUQAcqf/WaWjMftG+DpV1wF/Bk1nnKX6ho7raUy9UG5 bi7Jm3CLwGppBrdLaymek/pUF8AsmO83QJKOyHy8xoz6i0y8WKzScsw+D9nkz94cUf1b P9y7ueXeiIVT7vb5GbhqaSSyhe+2tcbkX7uRFfV3kfMIfztcbumxIcKwAd80PbplPV13 gXhmKGjhDUHYaE3vbpd7RlLSWGWNs9nmk0t/Lz9dp4CReDHVkPIv3dWxAolppq8sbyln 3sMQ== X-Gm-Message-State: APjAAAV3ebcFv6gJouuWZLlsDt7DwayyfnQVgTkiPMcPt9fQd6gPagU1 rV6rXquls7ijahAEzxJkVeR35bB/ X-Google-Smtp-Source: APXvYqzQBJoTC4x/HmqmBeIyEIoAjQoqEIGcKK46pbGfm/2LrKoTnqmf94KRs40v7N4Gay6IavqM3w== X-Received: by 2002:a24:b643:: with SMTP id d3mr909536itj.146.1551380817856; Thu, 28 Feb 2019 11:06:57 -0800 (PST) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com. [209.85.166.49]) by smtp.gmail.com with ESMTPSA id x24sm7641190ioa.50.2019.02.28.11.06.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Feb 2019 11:06:57 -0800 (PST) Received: by mail-io1-f49.google.com with SMTP id x9so17475713iog.12; Thu, 28 Feb 2019 11:06:57 -0800 (PST) X-Received: by 2002:a6b:6007:: with SMTP id r7mr552387iog.124.1551380817486; Thu, 28 Feb 2019 11:06:57 -0800 (PST) MIME-Version: 1.0 References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> In-Reply-To: <20190228183214.GA17372@troutmask.apl.washington.edu> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Thu, 28 Feb 2019 11:06:46 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: sgk@troutmask.apl.washington.edu Cc: John Baldwin , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 7D727826C6 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.175 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-5.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.86)[-0.864,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; IP_SCORE(-2.60)[ip: (-7.11), ipnet: 209.85.128.0/17(-3.81), asn: 15169(-2.03), country: US(-0.07)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[175.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 19:07:05 -0000 On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl wrote: > This is interesting as well. Does this mean that amd64 is now > the only tier 1 platform and all other architectures are after > thoughts? This has been the de facto truth for years. i386 is mostly only supported by virtue of sharing code with amd64. There are efforts to promote arm64 to Tier 1, but it isn't there yet. Power8+ might be another good alternative Tier 1 candidate eventually. None have anything like the developer popularity that amd64 enjoys. Conrad From owner-freebsd-current@freebsd.org Thu Feb 28 19:12:24 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCBE41513E6D for ; Thu, 28 Feb 2019 19:12:23 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 193F882C4C for ; Thu, 28 Feb 2019 19:12:22 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1551381134; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=AEoNNgt0+CoaQsSWj+XZCf2G+yInhUOn35uAIujZmsArggqH2LkZgX8C9CYwO28mMq8RUFppjXpCr sd8rQSgHmKQV26zhof7zCb2gM5GDP9r4o1RWjhJ0ibQnxME7UMdANrcPy05fHgnN0Jw0Ho3Tx5vu4P fMHwVAigN23PUEIrKYLy434/NEI7xnho+LQ0XxDb5eb+PpmEig0k+rYNdJQ/dIS9fi++yGt1CQgpjP l8MVHrZSYySzkivW09j9Zr/ulYe8qbJvbNSd9ZK5Iw0xss2XQYP4g2sp11WdHFj5B7A64d2WQTkghJ ZOHsuJmQn3RcW3+kP4VcL7PQmGgm2Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=ygT33yTS889o4/5bnOqpfOZ4CrznZ6sGsDB0aN/HiW8=; b=ltUD54KzKO4XR+F9DFXimZhfJdzpoPpDrLpthOlYF5jipSgd7eGjnJN0VQMxn0VOhtWo2DqGU95OH eK/TDLjUkD2bzQ6QP+x60tJoml/a3gAvZTzUue5kLLqhH8ZBOeeZq7i1P7iylBVHVgnJK4V4s0EL20 In9h/uD+6QjDAsYKReggmQcNuxe5BaEEqgxOR2xZegTkxONoqWwPnfz6FyhlBdMv6Zb0WucfrCJNJr 5IfjPjeTihmGUFbwWTz0rrgKx1VDP0GmHSK0IRr6x8mflyf4iR2dThf1rbMnVO4lmwpwrejD0EjN+L fir+M7i1+DjTKnv9cGTSReoXeCyIIRA== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=ygT33yTS889o4/5bnOqpfOZ4CrznZ6sGsDB0aN/HiW8=; b=u278EC1DJrFWNPbf2efa4tRMos9BXFWvsMFvxI9ByKoFq4hrYCXkUBfr+9WgOtVzvzKPVvPD7sYqA csCrbgbc4lsmjKvIn1KvzhJuFM35+CcOe+VZTA8WBtrpASD/MWY5CCasuX67YbQjtbosKRUTh1uGRV OeJPVG8DpGcpa/xyzjPEr9AhCYfCkSNS6wICqwdyX9SpuEGeLozdnzWgXnza25qgdxqC1IYGUbDqTU tQoIGegfd4tz8ie4Dun4gINYhK5VeJJ78dTxV2XRYnI2jKfi6vvIVQSka1KWp57v2C+sc2OaNvRms5 3aNCrWrj5xzgk0e+rowBroOPGoaeEnw== X-MHO-RoutePath: aGlwcGll X-MHO-User: beff0231-3b8c-11e9-803b-31925da7267c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id beff0231-3b8c-11e9-803b-31925da7267c; Thu, 28 Feb 2019 19:12:12 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x1SJC9XD007656; Thu, 28 Feb 2019 12:12:09 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <55eb26fb977fe90e323a8721e39bfc0185d994ba.camel@freebsd.org> Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd From: Ian Lepore To: cem@freebsd.org, sgk@troutmask.apl.washington.edu Cc: John Baldwin , freebsd-current Date: Thu, 28 Feb 2019 12:12:09 -0700 In-Reply-To: References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 193F882C4C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-3.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 19:12:24 -0000 On Thu, 2019-02-28 at 11:06 -0800, Conrad Meyer wrote: > On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > wrote: > > This is interesting as well. Does this mean that amd64 is now > > the only tier 1 platform and all other architectures are after > > thoughts? > > This has been the de facto truth for years. i386 is mostly only > supported by virtue of sharing code with amd64. There are efforts to > promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > another good alternative Tier 1 candidate eventually. None have > anything like the developer popularity that amd64 enjoys. > > I have been of the opinion that armv[67] has met all the bullet points to be a tier-1 arch for several years, but nobody seemed interested in declaring it so. Now it'll never happen, because there seems to be growing momentum to throw everything 32-bit under the bus and declare freebsd to be a 64-bit-only OS. Netflix wins; those of us building smaller embedded products will eventually be forced to move to linux. -- Ian From owner-freebsd-current@freebsd.org Thu Feb 28 19:15:25 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AAE315140ED for ; Thu, 28 Feb 2019 19:15:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B50782F47; Thu, 28 Feb 2019 19:15:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id zR9HgDvojqO6dzR9JgdPBW; Thu, 28 Feb 2019 12:15:17 -0700 X-Authority-Analysis: v=2.3 cv=B/XHL9lM c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=CFTnQlWoA9kA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=L5W3fVIDw7R9AlMd5dMA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from [IPv6:2605:8d80:402:e6fa:7662:4608:c1c9:df9c] (unknown [72.143.238.20]) by spqr.komquats.com (Postfix) with ESMTPSA id 804032527; Thu, 28 Feb 2019 11:15:15 -0800 (PST) Date: Thu, 28 Feb 2019 11:14:51 -0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: cem@freebsd.org, Conrad Meyer , sgk@troutmask.apl.washington.edu CC: John Baldwin , freebsd-current From: Cy Schubert Message-ID: <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> X-CMAE-Envelope: MS4wfF4/MGsx8d7oxHB/A9k0/h8CkaY1vu5hfipVZva6G7/0eFOL82D/XmxhMWr0J3Mi7L+w1p4mqc4MM8rgEpsCx1VFb8IbgZ8uLX0vIR/BBNhEEOdXAjUW cGaCj73RjOO1PoQRz39rkwl/HoXyuB7xiy6xinAACrSFl954LkysAHr0Po8bhFQHNP7Cdh9dxuy8+SOGV9RbYqkrnSZSR3TgHvmWhqS1RyNLOT8RWSnJA6Eu 1l6VhmfqnZvnll2QWH9CofFpZfgBAv598yZO9fq5K2ztF/zLzQQPuw/49KPg9ZD0 X-Rspamd-Queue-Id: 3B50782F47 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.35 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-2.16)[ip: (-5.95), ipnet: 64.59.128.0/20(-2.68), asn: 6327(-2.10), country: CA(-0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[spqr.komquats.com]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 19:15:25 -0000 On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrot= e: >On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > wrote: >> This is interesting as well=2E Does this mean that amd64 is now >> the only tier 1 platform and all other architectures are after >> thoughts? > >This has been the de facto truth for years=2E i386 is mostly only >supported by virtue of sharing code with amd64=2E There are efforts to >promote arm64 to Tier 1, but it isn't there yet=2E Power8+ might be >another good alternative Tier 1 candidate eventually=2E None have >anything like the developer popularity that amd64 enjoys=2E > >Conrad >_______________________________________________ >freebsd-current@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscribe@freebsd=2Eorg" We deprecated and removed support for 386 and 486 processors=2E We should = consider removing support for low end Pentium as well=2E I'm specifically t= hinking of removing the workarounds like F00F=2E Are there any processors t= hat are still vulnerable to this? --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-current@freebsd.org Thu Feb 28 19:21:27 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA680151495E for ; Thu, 28 Feb 2019 19:21:27 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D3D583891; Thu, 28 Feb 2019 19:21:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1SJLOpl018518 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Feb 2019 11:21:24 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1SJLOnC018517; Thu, 28 Feb 2019 11:21:24 -0800 (PST) (envelope-from sgk) Date: Thu, 28 Feb 2019 11:21:24 -0800 From: Steve Kargl To: Cy Schubert Cc: cem@freebsd.org, John Baldwin , freebsd-current Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190228192124.GB18089@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 5D3D583891 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.04 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.05)[-0.046,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.80)[0.798,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_MEDIUM(0.54)[0.544,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.05)[ip: (0.10), ipnet: 128.95.0.0/16(0.16), asn: 73(0.06), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 19:21:28 -0000 On Thu, Feb 28, 2019 at 11:14:51AM -0800, Cy Schubert wrote: > On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrote: > >On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > > wrote: > >> This is interesting as well. Does this mean that amd64 is now > >> the only tier 1 platform and all other architectures are after > >> thoughts? > > > >This has been the de facto truth for years. i386 is mostly only > >supported by virtue of sharing code with amd64. There are efforts to > >promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > >another good alternative Tier 1 candidate eventually. None have > >anything like the developer popularity that amd64 enjoys. > > > > We deprecated and removed support for 386 and 486 processors. We should consider removing support for low end Pentium as well. I'm specifically thinking of removing the workarounds like F00F. Are there any processors that are still vulnerable to this? > Ahem, sys/i386/conf/GENERIC contains "cpu I486_CPU". Is that a typo? -- Steve From owner-freebsd-current@freebsd.org Thu Feb 28 19:43:18 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D3C215159B1 for ; Thu, 28 Feb 2019 19:43:18 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13C3984A41; Thu, 28 Feb 2019 19:43:18 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 84499127D4; Thu, 28 Feb 2019 19:43:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: sgk@troutmask.apl.washington.edu Cc: Conrad Meyer , freebsd-current References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Thu, 28 Feb 2019 11:43:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190228183214.GA17372@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 13C3984A41 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.95 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.955,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 19:43:18 -0000 On 2/28/19 10:32 AM, Steve Kargl wrote: > On Thu, Feb 28, 2019 at 09:09:38AM -0800, John Baldwin wrote: >> You can do all your tests directly on amd64 by just adding >> "-m32" to compile i386 binaries against the libraries in /usr/lib32 >> and you will generate the same i386 binaries as if you were building >> on an i386 system. If you are a bit more paranoid, you can install >> an i386 world and chroot into it and use that to test i386. I do this >> myself (-m32) for testing i386 things. I also run i386 VMs under >> bhyve on amd64 hosts. I'm not sure your laptop's CPU can run i386 >> VMs though, and you don't need a VM to test userland-only changes >> (I'm usually trying to test kernel changes). > > Interesting. Did not know I could use -m32 with any reliability. > Setting up my testing environment may be a challenge as I use > mpfr/gmp, so would need -m32 aware versions of those libraries. > I normally install whatever the port collection offers for mpfr/gmp. > I suppose I would need to install those independently to get > multilib support. I would also need to compile 2 versions of my > testing framework (ie., additional support library). -m32 didn't used to work in early amd64 (like 6.x or maybe 7.x), but it has worked reliably for several branches now. That said, if you want to use i386 packages, I think a chroot is probably a safer route as in the chroot you can use pkg to install i386 packages just as if it was an i386 machine. > The BIOS does have a enable/disable button for virtualization. > During the great drm-legacy-kmod event of the last month, enabling > virtualization locks up a i386 FreeBSD kernel very quickly. > Perhaps, virtualization works under amd64. Guess I'll burn > an image onto a memstick an d give it a whirl. bhyve is definitely amd64-only. We don't have any support for bhyve on i386 kernels and likely never will. However, if an i386 chroot works, it's probably faster than an i386 VM anyway. >> However, an amd64 kernel is going to be a more stable, better >> supported kernel for running i386 binaries than an i386 kernel >> at this point, and that will become even more true in the future. > > This is interesting as well. Does this mean that amd64 is now > the only tier 1 platform and all other architectures are after > thoughts? i386 is still marked as tier 1. However, it's becoming increasingly harder to maintain that level of support for the kernel. core@ is currently exploring some ideas about how to make our tiering for i386 more closely reflect what we as a project are able to provide. Originally we were considering a proposal to demote all of i386 to tier 2, but after some initial conversations we think a better model is to keep the i386 user ABI as tier 1 and only demote the i386 kernel. However, we still need to think about what that looks like and update our tiering language to reflect what that looks like. I think the short version is that we might no longer guarantee i386-specific fixes for kernel SAs, but there are probably additional wrinkles that will arise as that is fleshed out further. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Feb 28 19:44:52 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2D8C1515AB4 for ; Thu, 28 Feb 2019 19:44:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8229384B8A; Thu, 28 Feb 2019 19:44:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 00F62127D5; Thu, 28 Feb 2019 19:44:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: Cy Schubert , cem@freebsd.org, sgk@troutmask.apl.washington.edu Cc: freebsd-current References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <947175c5-215b-c100-c6e7-c79a2322f98a@FreeBSD.org> Date: Thu, 28 Feb 2019 11:44:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8229384B8A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.95 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.95)[-0.953,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 19:44:52 -0000 On 2/28/19 11:14 AM, Cy Schubert wrote: > On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrote: >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl >> wrote: >>> This is interesting as well. Does this mean that amd64 is now >>> the only tier 1 platform and all other architectures are after >>> thoughts? >> >> This has been the de facto truth for years. i386 is mostly only >> supported by virtue of sharing code with amd64. There are efforts to >> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be >> another good alternative Tier 1 candidate eventually. None have >> anything like the developer popularity that amd64 enjoys. >> >> Conrad >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > We deprecated and removed support for 386 and 486 processors. We should consider removing support for low end Pentium as well. I'm specifically thinking of removing the workarounds like F00F. Are there any processors that are still vulnerable to this? We have only removed support for 386 since it didn't support cmpxchg. We still nominally support 486s. I don't know how well FreeBSD 13 would run on a 486, but in theory the code is still there and the binaries shouldn't die with illegal instruction faults. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Feb 28 22:48:39 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74F93151CC42 for ; Thu, 28 Feb 2019 22:48:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EF378DBD2 for ; Thu, 28 Feb 2019 22:48:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id y140so13164570qkb.9 for ; Thu, 28 Feb 2019 14:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TzO/PHSn23IQ46g+wbxjR7xovoFN2rwxg/6ruGxOnvA=; b=0BNbxHxoAw9V/psJgG/gMCxuGaavqyFe7juFCUHx+Tx7B94IsclI0r6ksURDvlu+Sy ElEZp0Pbzo70Wwy3GWkPGZn4otUj22zfNnxniR+hn6JqIZ/mX3X5yRbB2ygVwYxosoTo Hk+oOJJFvIHM/wyPomtVLtCjCOr92w0wVWn5dphRu/NS7dhxrHAyF01SBYicVaAvz9Xb 15czyGD4CosWe5bPbcN08aCFQd5YDSAUAysR2puvJE5H4b6Lw8E5rimjaDaBfA+b/0O1 srd1Vw44Ex7BdOuJtrEUhKafnyTzuPH0QRf3QXyVgrqBqrT7irW5jL6x5nQKDHnvKnvG q/aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TzO/PHSn23IQ46g+wbxjR7xovoFN2rwxg/6ruGxOnvA=; b=VtvUzd9iKWF1ALNXzV8x3X+Um8Q62MUA+2e35CBUFr2jLHI0h9lBHI8XzTrbpVz91e QLM/pW56aZfGYSi1U70nYrff1D0yveiGZD7cA2wgpF2eQon6/jf4civAHeD+sHxhm2xr c/YMe9sqzW0Auf/lpdn5XdaD+j25Kkrrh+mUd/JVkygCqEvN7AQtoTEAJ+xPONWClAHY P1BKsoSMOFOkIDtXYLTw6vP8pULeU8S2mKtOPh2IhytHPNou/wIZyyIVANE62q9Hi3la tAWyf2Rw971Xz69Mlpw3KHk6tAe7T8+aR7J0DNt7dFpdx7mNMQF111SbjmZ6re1iYYjj nd2Q== X-Gm-Message-State: APjAAAX+vDDTi1dcUDbwFI4Dv+x9DwliQyitbaHTmMk3M6HhFeY1hVfF lesQbBpcvCbx5cszZR9QUa057XAsqNeMcemTR3JMsQ== X-Google-Smtp-Source: APXvYqzqAza+4OV56O0eG513/8QJVSzENsOXlAr0/QTGyT5u2LeqGnfK3sIYagsgvQcclfjBCiqJeErX1RjlhfsehVc= X-Received: by 2002:ae9:e702:: with SMTP id m2mr1580437qka.279.1551394116568; Thu, 28 Feb 2019 14:48:36 -0800 (PST) MIME-Version: 1.0 References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> <947175c5-215b-c100-c6e7-c79a2322f98a@FreeBSD.org> In-Reply-To: <947175c5-215b-c100-c6e7-c79a2322f98a@FreeBSD.org> From: Warner Losh Date: Thu, 28 Feb 2019 15:48:25 -0700 Message-ID: Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: John Baldwin Cc: Cy Schubert , "Conrad E. Meyer" , Steve Kargl , freebsd-current X-Rspamd-Queue-Id: 6EF378DBD2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=0BNbxHxo X-Spamd-Result: default: False [-5.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[ALT1.aspmx.l.google.com,aspmx.l.google.com,ALT2.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[d.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.89)[-0.888,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.71)[ip: (-8.76), ipnet: 2607:f8b0::/32(-2.71), asn: 15169(-2.03), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 22:48:39 -0000 On Thu, Feb 28, 2019 at 12:46 PM John Baldwin wrote: > On 2/28/19 11:14 AM, Cy Schubert wrote: > > On February 28, 2019 11:06:46 AM PST, Conrad Meyer > wrote: > >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > >> wrote: > >>> This is interesting as well. Does this mean that amd64 is now > >>> the only tier 1 platform and all other architectures are after > >>> thoughts? > >> > >> This has been the de facto truth for years. i386 is mostly only > >> supported by virtue of sharing code with amd64. There are efforts to > >> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > >> another good alternative Tier 1 candidate eventually. None have > >> anything like the developer popularity that amd64 enjoys. > >> > >> Conrad > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > > > > We deprecated and removed support for 386 and 486 processors. We should > consider removing support for low end Pentium as well. I'm specifically > thinking of removing the workarounds like F00F. Are there any processors > that are still vulnerable to this? > > We have only removed support for 386 since it didn't support cmpxchg. We > still > nominally support 486s. I don't know how well FreeBSD 13 would run on a > 486, but > in theory the code is still there and the binaries shouldn't die with > illegal > instruction faults. > The biggest barrier to running on a real 486 is that it's hard for FreeBSD to fit into 32MB that was the maximum config you could have. You can barely boot it w/o tuning, though it will still fit a few jobs if you are looking at something super low-end with a lot of effort. There are a few later CPUs built on basically a 486 whose chipsets could support up to 128MB or 256MB which is enough to run FreeBSD still. Warner From owner-freebsd-current@freebsd.org Thu Feb 28 22:55:02 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C0ED151D1C0 for ; Thu, 28 Feb 2019 22:55:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05BEE8E2D1 for ; Thu, 28 Feb 2019 22:55:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id v10so25620725qtp.8 for ; Thu, 28 Feb 2019 14:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DVxF1t91VgUNhq2bPd3LMPoWmodLLWC/5Y7OFS0G7aQ=; b=GGgehzLjLn+auRssq1xQHkt2664hz3vLfl0E6WlCTou/LrUjRzNmsk0OdzOzxD79gC ThLRTqdZ8R/AFZAuxr6P7x5q1RXm60sFBsor/RBiycwsumWQccfth/IBreOcObuOsS4h vOwYSmNdAyLMoX/A7VLl84eZ/O1JLTlotn5OGl5qMPsHvlVRrKIVGWJBKTw4h4YjgJX0 IWTWBsXlDyUoRYBaeQGaDGPl1Lw22w8MJSvvwIdwRMnBXpODjX91NW+KeUzmVp2vlDq1 lVTYcaVbK8NyUYtvHHAohEHwYk9UO4afE4SGZBHUXysdKZLVWj9XgePTxhQXRZWCxXIB o/iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DVxF1t91VgUNhq2bPd3LMPoWmodLLWC/5Y7OFS0G7aQ=; b=MABtCPl4fELqfoI8fgyz1E5kZ7Whf/P9cVkixiQNW6Z8oRgrQ4aQRj5GFxUuhzbpWn rTVRTaES2/r4qVcear2SumbVmPvM9q3gN8WS17bS+1ViQRKydhENDfgs6DNI/hoPeF7T vWcFoX1XOqZg2fhFJ/mNuHIqVnZYa48xiFjchuXqwPeNzSZIaPvuXkksOH5UGHT8Qv5m UhVLv9z8w1AzDU8e0LUu91V2vTPO78JGE2t6+wiLQDr6NcURjeYDOSr6yBUah9MLOAwG sPrv6IxcLXUSlarNt0waa4DNZgJm5E1jNmDtTYnD4H8fWRgnc2ddB1hM+N/smk8jRnKD ek5Q== X-Gm-Message-State: APjAAAXVuEEgz+FkjlqVl8lu+YgnXuzxv2EnYtW4zF/NOwVEskjRMRt/ XZJGNTmavN0B3fZ2eUsCVuCbj+VRHkM4+NUZh8Vrtg== X-Google-Smtp-Source: APXvYqygBQMBB2yLDym78DxRxRzOUX4O24sS1BdTIbHjQ0O2kNVKm1GgufKcpdWJ4pdN0erYuG1lvyaJKyW/sCkaTV4= X-Received: by 2002:a0c:b68a:: with SMTP id u10mr1359573qvd.57.1551394500367; Thu, 28 Feb 2019 14:55:00 -0800 (PST) MIME-Version: 1.0 References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> <55eb26fb977fe90e323a8721e39bfc0185d994ba.camel@freebsd.org> In-Reply-To: <55eb26fb977fe90e323a8721e39bfc0185d994ba.camel@freebsd.org> From: Warner Losh Date: Thu, 28 Feb 2019 15:54:49 -0700 Message-ID: Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: Ian Lepore Cc: "Conrad E. Meyer" , Steve Kargl , John Baldwin , freebsd-current X-Rspamd-Queue-Id: 05BEE8E2D1 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=GGgehzLj X-Spamd-Result: default: False [-5.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.88)[-0.883,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.69)[ip: (-8.63), ipnet: 2607:f8b0::/32(-2.71), asn: 15169(-2.03), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 22:55:02 -0000 On Thu, Feb 28, 2019 at 12:14 PM Ian Lepore wrote: > On Thu, 2019-02-28 at 11:06 -0800, Conrad Meyer wrote: > > On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > > wrote: > > > This is interesting as well. Does this mean that amd64 is now > > > the only tier 1 platform and all other architectures are after > > > thoughts? > > > > This has been the de facto truth for years. i386 is mostly only > > supported by virtue of sharing code with amd64. There are efforts to > > promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > > another good alternative Tier 1 candidate eventually. None have > > anything like the developer popularity that amd64 enjoys. > > > > > > I have been of the opinion that armv[67] has met all the bullet points > to be a tier-1 arch for several years, but nobody seemed interested in > declaring it so. I concur that armv[67] is the closest thing we have to a second tier 1. arm64 is also quite good, but still has a few more rough edges compared to armv[67]. > Now it'll never happen, because there seems to be > growing momentum to throw everything 32-bit under the bus and declare > freebsd to be a 64-bit-only OS. Netflix wins; those of us building > smaller embedded products will eventually be forced to move to linux. > While there's been some talk, there's too many relevant 32-bit arm chips to toss it out in 13 (planned in 2ish years or 2021) and no i386 in 13 likely would be a stretch as well, so 13 almost certainly will have 32-bit kernels and userland support (though that will require the 32-bit processors support 64-bit atomics to reduce friction). Who know if that will be the case in 4 or 5 years when 14 is branched (so ~2025). Current trends suggest that 32-bits might not be relevant then, but we certainly can't say that for sure today. Warner From owner-freebsd-current@freebsd.org Fri Mar 1 00:14:35 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B59FA151F30F for ; Fri, 1 Mar 2019 00:14:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F16269EEA; Fri, 1 Mar 2019 00:14:34 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id zVoqgAM2NuCr7zVosgDfa3; Thu, 28 Feb 2019 17:14:31 -0700 X-Authority-Analysis: v=2.3 cv=U/rs8tju c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=CFTnQlWoA9kA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=yKNiL60UbGpXvGItzWcA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from [IPv6:2605:8d80:402:e6fa:7662:4608:c1c9:df9c] (unknown [72.143.238.164]) by spqr.komquats.com (Postfix) with ESMTPSA id E33242EE3; Thu, 28 Feb 2019 16:14:26 -0800 (PST) Date: Thu, 28 Feb 2019 11:24:53 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <20190228192124.GB18089@troutmask.apl.washington.edu> References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> <20190228192124.GB18089@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: sgk@troutmask.apl.washington.edu, Steve Kargl CC: cem@freebsd.org, John Baldwin , freebsd-current From: Cy Schubert Message-ID: <029F8ACF-C9B3-49AC-80C3-C947EE9801A1@cschubert.com> X-CMAE-Envelope: MS4wfAQWWaT70gVDz1c12/1DOjWLPS2QhHzEHxqzGs05eDHs2xkXGt5ejphrDIGv432GV224/RLORiUooX7fjr3efjDhuEmFQm1R9666S5230KEodM5SCCkb SXt8I34L6ol4zC1WpekA5V/P37+leQbY7ycZzBT1xT9rfsBqmbF7cP/7g+SCpKQMDR8JB7rFJ8F+maWVgVMTyQcC6aNVcTZXKGS7x40szP5L4FvWNavwvJrx 21XkEpxrvRoA8cWVMSdVLCEnztX97DgFBCu7r7eZqec/9i2yE36NFxgp3U2s7vv3 X-Rspamd-Queue-Id: 7F16269EEA X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.31 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[12.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.16)[ip: (-5.90), ipnet: 64.59.128.0/20(-2.69), asn: 6327(-2.11), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 00:14:36 -0000 On February 28, 2019 11:21:24 AM PST, Steve Kargl wrote: >On Thu, Feb 28, 2019 at 11:14:51AM -0800, Cy Schubert wrote: >> On February 28, 2019 11:06:46 AM PST, Conrad Meyer >wrote: >> >On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl >> > wrote: >> >> This is interesting as well=2E Does this mean that amd64 is now >> >> the only tier 1 platform and all other architectures are after >> >> thoughts? >> > >> >This has been the de facto truth for years=2E i386 is mostly only >> >supported by virtue of sharing code with amd64=2E There are efforts >to >> >promote arm64 to Tier 1, but it isn't there yet=2E Power8+ might be >> >another good alternative Tier 1 candidate eventually=2E None have >> >anything like the developer popularity that amd64 enjoys=2E >> > >>=20 >> We deprecated and removed support for 386 and 486 processors=2E We >should consider removing support for low end Pentium as well=2E I'm >specifically thinking of removing the workarounds like F00F=2E Are there >any processors that are still vulnerable to this? >>=20 > >Ahem, sys/i386/conf/GENERIC contains "cpu I486_CPU"=2E >Is that a typo? I stand corrected=2E We should remove that=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-freebsd-current@freebsd.org Fri Mar 1 01:04:35 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5C611520BC5 for ; Fri, 1 Mar 2019 01:04:34 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 733506B935; Fri, 1 Mar 2019 01:04:34 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id C91EB14AD9; Fri, 1 Mar 2019 01:04:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: Cy Schubert , sgk@troutmask.apl.washington.edu Cc: cem@freebsd.org, freebsd-current References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> <20190228192124.GB18089@troutmask.apl.washington.edu> <029F8ACF-C9B3-49AC-80C3-C947EE9801A1@cschubert.com> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Thu, 28 Feb 2019 17:04:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <029F8ACF-C9B3-49AC-80C3-C947EE9801A1@cschubert.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 733506B935 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.77 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.77)[-0.771,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 01:04:35 -0000 On 2/28/19 11:24 AM, Cy Schubert wrote: > On February 28, 2019 11:21:24 AM PST, Steve Kargl wrote: >> On Thu, Feb 28, 2019 at 11:14:51AM -0800, Cy Schubert wrote: >>> On February 28, 2019 11:06:46 AM PST, Conrad Meyer >> wrote: >>>> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl >>>> wrote: >>>>> This is interesting as well. Does this mean that amd64 is now >>>>> the only tier 1 platform and all other architectures are after >>>>> thoughts? >>>> >>>> This has been the de facto truth for years. i386 is mostly only >>>> supported by virtue of sharing code with amd64. There are efforts >> to >>>> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be >>>> another good alternative Tier 1 candidate eventually. None have >>>> anything like the developer popularity that amd64 enjoys. >>>> >>> >>> We deprecated and removed support for 386 and 486 processors. We >> should consider removing support for low end Pentium as well. I'm >> specifically thinking of removing the workarounds like F00F. Are there >> any processors that are still vulnerable to this? >>> >> >> Ahem, sys/i386/conf/GENERIC contains "cpu I486_CPU". >> Is that a typo? > > I stand corrected. We should remove that. No, it doesn't need removing per my other mail. While there is some cruft in a few files for older CPUs (mostly just initcpu.c and identcpu.c) it is quite small and in code that doesn't change. To effect any type of substantial "win" in reducing code complexity for i386, you'd have to do something like require PAE (so that the kernel could assume PAE instead of a bunch of runtime checks as it does now). That would also give you working 64-bit atomics on i386. However, removing I486_CPU alone doesn't buy you anything. -- John Baldwin From owner-freebsd-current@freebsd.org Fri Mar 1 04:48:46 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B2E5150416C for ; Fri, 1 Mar 2019 04:48:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C05207464D for ; Fri, 1 Mar 2019 04:48:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7A6921504169; Fri, 1 Mar 2019 04:48:45 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56AAF1504163 for ; Fri, 1 Mar 2019 04:48:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E011774646 for ; Fri, 1 Mar 2019 04:48:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 01896659 for ; Fri, 1 Mar 2019 04:48:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x214mh0x013025 for ; Fri, 1 Mar 2019 04:48:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x214mhQS013024 for current@FreeBSD.org; Fri, 1 Mar 2019 04:48:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed) Date: Fri, 01 Mar 2019 04:48:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch, regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: slava@planetslav.ca X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: avg@FreeBSD.org X-Bugzilla-Flags: mfc-stable12+ X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 01 Mar 2019 12:12:35 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 04:48:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227191 Slava changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |slava@planetslav.ca --- Comment #22 from Slava --- Hello, I'm having the same issue on Lenovo X1 Carbon gen1, Coreboot 4.7 TianoCore = on Freebsd 12.0-RELEASE-p3. It was working since Freebsd 11.1 when I just set this up over a year ago and in 11.2. Stopped working after update to 12. [moose@beast /usr/home/moose]$ acpiconf -i 0 acpiconf: get battery info (0) failed: Device not configured [moose@beast /usr/home/moose]$ dmesg | grep -i acpi | grep -i bat ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT0._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT1._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT0._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT1._STA, AE_NOT_EXIST (20181003/psparse-677) [moose@beast /usr/home/moose]$ uname -a FreeBSD beast 12.0-RELEASE-p3 FreeBSD 12.0-RELEASE-p3 GENERIC amd64 Please let me know if you need any additional information and/or if I need = to apply any patches manually. Thank you --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Fri Mar 1 13:03:04 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CE571516A5C for ; Fri, 1 Mar 2019 13:03:04 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8961E7770E; Fri, 1 Mar 2019 13:03:03 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x21D31p2061413; Fri, 1 Mar 2019 05:03:01 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x21D31Fl061412; Fri, 1 Mar 2019 05:03:01 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903011303.x21D31Fl061412@pdx.rh.CN85.dnsmgr.net> Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd In-Reply-To: To: John Baldwin Date: Fri, 1 Mar 2019 05:03:01 -0800 (PST) CC: sgk@troutmask.apl.washington.edu, Conrad Meyer , freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 8961E7770E X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.96 / 15.00]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.854,0]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.69)[0.688,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; NEURAL_SPAM_LONG(0.52)[0.519,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.01)[ip: (0.06), ipnet: 69.59.192.0/19(0.03), asn: 13868(0.01), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:03:04 -0000 > On 2/28/19 10:32 AM, Steve Kargl wrote: ( ... trimmed ... ) > > The BIOS does have a enable/disable button for virtualization. > > During the great drm-legacy-kmod event of the last month, enabling > > virtualization locks up a i386 FreeBSD kernel very quickly. > > Perhaps, virtualization works under amd64. Guess I'll burn > > an image onto a memstick an d give it a whirl. > > bhyve is definitely amd64-only. We don't have any support for bhyve on i386 > kernels and likely never will. However, if an i386 chroot works, it's probably > faster than an i386 VM anyway. bhyve/vmm.ko does not come into play here at all, the real question is why does our i386 kernel "lock up" simply because a newer CPU feature appears, it should not do that, as far as I am aware turing VT-x on does not or should not in anyway change the "i386" behavior or a machine. What am I missing? > >> However, an amd64 kernel is going to be a more stable, better > >> supported kernel for running i386 binaries than an i386 kernel > >> at this point, and that will become even more true in the future. > > > > This is interesting as well. Does this mean that amd64 is now > > the only tier 1 platform and all other architectures are after > > thoughts? > > i386 is still marked as tier 1. However, it's becoming increasingly harder to > maintain that level of support for the kernel. core@ is currently exploring > some ideas about how to make our tiering for i386 more closely reflect what we > as a project are able to provide. Originally we were considering a proposal to > demote all of i386 to tier 2, but after some initial conversations we think a > better model is to keep the i386 user ABI as tier 1 and only demote the i386 > kernel. However, we still need to think about what that looks like and update > our tiering language to reflect what that looks like. I think the short version > is that we might no longer guarantee i386-specific fixes for kernel SAs, but > there are probably additional wrinkles that will arise as that is fleshed out > further. Is core talking to the stake holders about this issue? IMHO this topic should be an open discussion some place with all parties involved, not just core deciding what is or is not a tier 1 and/or how to fix our tier 1 situation with i386 (which I do agree needs to change, but to what I have not a solid idea.) -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Mar 1 13:07:40 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D50B1516D13 for ; Fri, 1 Mar 2019 13:07:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9ED8D77CA5; Fri, 1 Mar 2019 13:07:39 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x21D7Xib061433; Fri, 1 Mar 2019 05:07:33 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x21D7XMc061432; Fri, 1 Mar 2019 05:07:33 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903011307.x21D7XMc061432@pdx.rh.CN85.dnsmgr.net> Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd In-Reply-To: <947175c5-215b-c100-c6e7-c79a2322f98a@FreeBSD.org> To: John Baldwin Date: Fri, 1 Mar 2019 05:07:33 -0800 (PST) CC: Cy Schubert , cem@freebsd.org, sgk@troutmask.apl.washington.edu, freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 9ED8D77CA5 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.04 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.51)[0.513,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; NEURAL_SPAM_LONG(0.18)[0.177,0]; NEURAL_SPAM_MEDIUM(0.45)[0.453,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.01)[ip: (0.06), ipnet: 69.59.192.0/19(0.03), asn: 13868(0.01), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:07:40 -0000 > On 2/28/19 11:14 AM, Cy Schubert wrote: > > On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrote: > >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > >> wrote: > >>> This is interesting as well. Does this mean that amd64 is now > >>> the only tier 1 platform and all other architectures are after > >>> thoughts? > >> > >> This has been the de facto truth for years. i386 is mostly only > >> supported by virtue of sharing code with amd64. There are efforts to > >> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > >> another good alternative Tier 1 candidate eventually. None have > >> anything like the developer popularity that amd64 enjoys. > >> > >> Conrad > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > > > > We deprecated and removed support for 386 and 486 processors. We should consider removing support for low end Pentium as well. I'm specifically thinking of removing the workarounds like F00F. Are there any processors that are still vulnerable to this? > > We have only removed support for 386 since it didn't support cmpxchg. We still > nominally support 486s. I don't know how well FreeBSD 13 would run on a 486, but > in theory the code is still there and the binaries shouldn't die with illegal > instruction faults. I know I can still boot FreeBSD 12, diskless no less, on a Transmeta Crusoe TM-5800. I'll go digging for a 486 and confirm or deny if we can boot ^head on it. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Mar 1 13:14:08 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC84A1517145 for ; Fri, 1 Mar 2019 13:14:07 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E88D18022A; Fri, 1 Mar 2019 13:14:06 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x21DE2mL061465; Fri, 1 Mar 2019 05:14:02 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x21DE2OB061464; Fri, 1 Mar 2019 05:14:02 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903011314.x21DE2OB061464@pdx.rh.CN85.dnsmgr.net> Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd In-Reply-To: To: Warner Losh Date: Fri, 1 Mar 2019 05:14:02 -0800 (PST) CC: John Baldwin , Cy Schubert , "Conrad E. Meyer" , Steve Kargl , freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: E88D18022A X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.96 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.50)[0.498,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; NEURAL_SPAM_LONG(0.13)[0.133,0]; NEURAL_SPAM_MEDIUM(0.43)[0.431,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.01)[ip: (0.06), ipnet: 69.59.192.0/19(0.03), asn: 13868(0.01), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:14:08 -0000 > On Thu, Feb 28, 2019 at 12:46 PM John Baldwin wrote: > > > On 2/28/19 11:14 AM, Cy Schubert wrote: > > > On February 28, 2019 11:06:46 AM PST, Conrad Meyer > > wrote: > > >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > > >> wrote: > > >>> This is interesting as well. Does this mean that amd64 is now > > >>> the only tier 1 platform and all other architectures are after > > >>> thoughts? > > >> > > >> This has been the de facto truth for years. i386 is mostly only > > >> supported by virtue of sharing code with amd64. There are efforts to > > >> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > > >> another good alternative Tier 1 candidate eventually. None have > > >> anything like the developer popularity that amd64 enjoys. > > >> > > >> Conrad > > >> _______________________________________________ > > >> freebsd-current@freebsd.org mailing list > > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > > >> To unsubscribe, send any mail to > > >> "freebsd-current-unsubscribe@freebsd.org" > > > > > > We deprecated and removed support for 386 and 486 processors. We should > > consider removing support for low end Pentium as well. I'm specifically > > thinking of removing the workarounds like F00F. Are there any processors > > that are still vulnerable to this? > > > > We have only removed support for 386 since it didn't support cmpxchg. We > > still > > nominally support 486s. I don't know how well FreeBSD 13 would run on a > > 486, but > > in theory the code is still there and the binaries shouldn't die with > > illegal > > instruction faults. > > > > The biggest barrier to running on a real 486 is that it's hard for FreeBSD > to fit into 32MB that was the maximum config you could have. You can barely > boot it w/o tuning, though it will still fit a few jobs if you are looking > at something super low-end with a lot of effort. Effort that has been completed in several places, wifi-build for one, where I did boot a 12.0 image of 8MB in size running in 32MB iirc on a D-Link DIR-855? router. > There are a few later CPUs built on basically a 486 whose chipsets could > support up to 128MB or 256MB which is enough to run FreeBSD still. Amd Geode would be in that group? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Mar 1 14:29:07 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EC45151903A for ; Fri, 1 Mar 2019 14:29:07 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71A2C828DC; Fri, 1 Mar 2019 14:29:06 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f49.google.com with SMTP id p18so19692492ioh.5; Fri, 01 Mar 2019 06:29:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=68IZKtkYY8qFot+fmcTLjMqGlbG8CDZYT0J6qGYgUP8=; b=NXXbXX8g63f3XfR+iiNTR7wJjt+jduTJ7MrxLk4r/PlcjSa4yKbQSnZy58vKXJ9UHc z0qGdYxgQHv3uzGf0HJqzMse5NeMSu0GOfnveGvZDwRDmu1inG0iXDidO9AFryzYAe9C XD0NljEV/q0HydVxZ+ioVLOjptJaZZnZuupBZBuh90Cc2GvdDoX+cDuFcGow1jAK7tvV YE9QCuWUHqvFPTNa5Tayu7xCwkDQcSYBvruH6I/efoEGhMjA3CJYLY9bkNGuVbDdyEsE cWzrllP+5kbBDSX/brwfKXu/cYZGl4JqK1CKu6d/s6RRZKClaOM7exXDoyHOcKGCzeJG v77Q== X-Gm-Message-State: APjAAAVvjrWTd3ORnIepH7jpr8y6lAcwoxOrdDkO+2PLy3qnGL9SQdOb J3/pdOhI3IicCpc42+1czf2P5dhzRsxZU/BfBl5G1g== X-Google-Smtp-Source: APXvYqw2p0NeVwxa9kKpszMZ8wk+R44RoRrPU6IPCsGuJGEJZoKWcGglv07pLMaeBSQBrTT7uNajlUo+faAxsRi9BTI= X-Received: by 2002:a6b:fb02:: with SMTP id h2mr2816416iog.239.1551450538455; Fri, 01 Mar 2019 06:28:58 -0800 (PST) MIME-Version: 1.0 References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> <55eb26fb977fe90e323a8721e39bfc0185d994ba.camel@freebsd.org> In-Reply-To: <55eb26fb977fe90e323a8721e39bfc0185d994ba.camel@freebsd.org> From: Ed Maste Date: Fri, 1 Mar 2019 09:28:44 -0500 Message-ID: Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: Ian Lepore Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 71A2C828DC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.49 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-5.76 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.97)[ip: (-8.93), ipnet: 209.85.128.0/17(-3.82), asn: 15169(-2.03), country: US(-0.07)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[49.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.78)[-0.777,0]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 14:29:07 -0000 On Thu, 28 Feb 2019 at 14:13, Ian Lepore wrote: > > I have been of the opinion that armv[67] has met all the bullet points > to be a tier-1 arch for several years, but nobody seemed interested in > declaring it so. Now it'll never happen, because there seems to be > growing momentum to throw everything 32-bit under the bus and declare > freebsd to be a 64-bit-only OS. Netflix wins; those of us building > smaller embedded products will eventually be forced to move to linux. I don't think this is the case. For one example, see the effort kib@ has been putting in (under Foundation sponsorship) on FreeBSD/i386. One of my co-op students this term is working on building out our hardware continuous integration testbed, including 32-bit Arm targets like the BeagleBone Black. Now, i386 has not been our primary reference platform for some time, and I expect that for 32-bit ports FreeBSD will largely be cross-built from amd64, arm64, or powerpc64 hosts. I think this is absolutely fine, and we can still support 32-bit devices well, but our current tier definitions don't fit this model well. From owner-freebsd-current@freebsd.org Fri Mar 1 17:07:08 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C8DE151E223 for ; Fri, 1 Mar 2019 17:07:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A318188DB4; Fri, 1 Mar 2019 17:07:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2858F1B367; Fri, 1 Mar 2019 17:07:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd To: "Rodney W. Grimes" Cc: sgk@troutmask.apl.washington.edu, Conrad Meyer , freebsd-current References: <201903011303.x21D31Fl061412@pdx.rh.CN85.dnsmgr.net> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <96826e2a-030d-fa09-6739-13897e2834a4@FreeBSD.org> Date: Fri, 1 Mar 2019 09:06:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <201903011303.x21D31Fl061412@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A318188DB4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.94)[-0.938,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 17:07:08 -0000 On 3/1/19 5:03 AM, Rodney W. Grimes wrote: >> On 2/28/19 10:32 AM, Steve Kargl wrote: > ( ... trimmed ... ) > >>> The BIOS does have a enable/disable button for virtualization. >>> During the great drm-legacy-kmod event of the last month, enabling >>> virtualization locks up a i386 FreeBSD kernel very quickly. >>> Perhaps, virtualization works under amd64. Guess I'll burn >>> an image onto a memstick an d give it a whirl. >> >> bhyve is definitely amd64-only. We don't have any support for bhyve on i386 >> kernels and likely never will. However, if an i386 chroot works, it's probably >> faster than an i386 VM anyway. > > bhyve/vmm.ko does not come into play here at all, the real question > is why does our i386 kernel "lock up" simply because a newer CPU > feature appears, it should not do that, as far as I am aware turing > VT-x on does not or should not in anyway change the "i386" behavior > or a machine. What am I missing? I think we don't know enough about this bug report to know what causes the hang. >>>> However, an amd64 kernel is going to be a more stable, better >>>> supported kernel for running i386 binaries than an i386 kernel >>>> at this point, and that will become even more true in the future. >>> >>> This is interesting as well. Does this mean that amd64 is now >>> the only tier 1 platform and all other architectures are after >>> thoughts? >> >> i386 is still marked as tier 1. However, it's becoming increasingly harder to >> maintain that level of support for the kernel. core@ is currently exploring >> some ideas about how to make our tiering for i386 more closely reflect what we >> as a project are able to provide. Originally we were considering a proposal to >> demote all of i386 to tier 2, but after some initial conversations we think a >> better model is to keep the i386 user ABI as tier 1 and only demote the i386 >> kernel. However, we still need to think about what that looks like and update >> our tiering language to reflect what that looks like. I think the short version >> is that we might no longer guarantee i386-specific fixes for kernel SAs, but >> there are probably additional wrinkles that will arise as that is fleshed out >> further. > > Is core talking to the stake holders about this issue? IMHO this topic > should be an open discussion some place with all parties involved, not > just core deciding what is or is not a tier 1 and/or how to fix our > tier 1 situation with i386 (which I do agree needs to change, but > to what I have not a solid idea.) As you are well aware, core@ has talked to some stakeholders already (including you) which has already resulted in some changes to what core@ is considering to propose to developers. However, it is ultimately core@ who makes tiering decisions. -- John Baldwin