From owner-freebsd-arch@freebsd.org Thu Feb 14 20:20:19 2019 Return-Path: Delivered-To: freebsd-arch@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 3378314DFFD5 for ; Thu, 14 Feb 2019 20:20:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id BCCB1899AF for ; Thu, 14 Feb 2019 20:20:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 2692343D606; Fri, 15 Feb 2019 07:20:13 +1100 (AEDT) Date: Fri, 15 Feb 2019 07:20:13 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh cc: Steve Kargl , "freebsd-arch@freebsd.org" Subject: Re: "DRM removal soon" is premature In-Reply-To: Message-ID: <20190215065959.S4212@besplex.bde.org> References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=WITgNBLsjsO_3sEmIlAA:9 a=9uZw6LUloKBpbY4p:21 a=CfD_xi55dttBI0Az:21 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: BCCB1899AF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-6.16 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: extmail.optusnet.com.au]; NEURAL_HAM_SHORT(-0.86)[-0.862,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.99)[ip: (-7.44), ipnet: 211.28.0.0/14(-4.15), asn: 4804(-3.30), country: AU(-0.04)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:20:19 -0000 On Thu, 14 Feb 2019, Warner Losh wrote: > On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: >> ... >> The in-tree version does not compile because someone disconnected >> drm2 from the build. r342567 would not have happen if drm2 was >> not disconnected. > > Technically, it's just off by default. It's still connected to the build. > We just don't have a good way to lint the code, as drm isn't in i386 NOTES. It is also only built in the modules tree if MK_MODULES_DRM2 is set (with further convolutions for MACHINE_CPU_ARCH). This is apparently not set set by default or forced for universe, so drm2 doesn't get tested by universe either, and even extensively tests for changes like r343567 don't notice when they break it. > You might try this fix instead, though I don't think it will matter. I > think the breakage you're seeing is a result of a subtle dependency in the > drm2/ttm code with FreeBSD's vm system. Even had it been connected to the > build and fixed at the time, I don't think it would have mattered. Another bug in the module is that it has no man pages. I used kldload to find its dependencies. i915kms didn't seem to depend on ttm. > diff --git a/sys/dev/drm2/ttm/ttm_bo.c b/sys/dev/drm2/ttm/ttm_bo.c > index 010afe6d8b3b..20083ff0fb53 100644 > --- a/sys/dev/drm2/ttm/ttm_bo.c > +++ b/sys/dev/drm2/ttm/ttm_bo.c > @@ -1498,11 +1498,11 @@ int ttm_bo_global_init(struct drm_global_reference > *ref) > tries = 0; > retry: > glob->dummy_read_page = vm_page_alloc_contig(NULL, 0, req, > - 1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); > + 1, 0, 0xfffffffful, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); > > if (unlikely(glob->dummy_read_page == NULL)) { > if (tries < 1 && vm_page_reclaim_contig(req, 1, > - 0, VM_MAX_ADDRESS, PAGE_SIZE, 0)) { > + 0, 0xfffffffful, PAGE_SIZE, 0)) { > tries++; > goto retry; > } I used VM_MAX_KERNEL_ADDRESS. kib said that it should be more related to bus spaces. 0xfffffffful seems just wrong on amd64. > Since that will eliminate the possibility that PAE is defined and giving a > bigger max. Though it also likely won't matter if you have < 4GB of RAM in > your machine. Obviously, this patch is not committable, but if it works it > tells us something. r343567 gives most of PAE including its slowness, but doesn't give full PAE due to problems with device addresses. > But as I said, I doubt this will work as there's something subtle (likely > the size of a variable or struct element) in ttm that's now out of sync. I see what look like subtle vm problems (a few frame buffer pages mismapped), but they are the same as a couple of years ago, and I don't have any devices mapped above 4G on i386. Bruce