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