From owner-freebsd-hackers@freebsd.org Wed Feb 22 06:29:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA978CE8BE0; Wed, 22 Feb 2017 06:29:44 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B70D5B7B; Wed, 22 Feb 2017 06:29:44 +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 v1M6Thos004619 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Feb 2017 22:29:43 -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 v1M6Th6F004618; Tue, 21 Feb 2017 22:29:43 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Feb 2017 22:29:43 -0800 From: Steve Kargl To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: drm2, i915kms cause instant lock-up Message-ID: <20170222062943.GA4611@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170220235224.GA91194@troutmask.apl.washington.edu> <20170222053242.GA4204@troutmask.apl.washington.edu> <20170222060802.GM2092@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170222060802.GM2092@kib.kiev.ua> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 06:29:45 -0000 On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote: > On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote: > > Well, I found the guilty commit. r313934 breaks loading > > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop. > > details below. > > > > I'll also note that starting at r313902 or so, after > > loading i915kms.ko console output on vt is slooooooow. > > A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user, > > and 1.08 sys, but the drawing on screen takes more than > > 30 seconds. One can painfully watch each line of output > > be rastered across the screen. > > > > Kib you can read the details below. If you need more info, > > ping me. I did notice that i686_mem.c used constants of the > > form 0xffffULL prior to the merge into x86_mem.c. You now > > use 0xfffUL. I have no idea whether this is related to > > cause. > > Well, yes, I found two instances more of such bugs, one seems to be innocent, > and another might be the issue. Please try this on top of r313934 or > the latest HEAD. > > diff --git a/sys/x86/x86/x86_mem.c b/sys/x86/x86/x86_mem.c > index 8e93883863a..d639224f840 100644 > --- a/sys/x86/x86/x86_mem.c > +++ b/sys/x86/x86/x86_mem.c > @@ -260,7 +260,7 @@ x86_mrfetch(struct mem_range_softc *sc) > > /* Compute the range from the mask. Ick. */ > mrd->mr_len = (~(msrv & mtrr_physmask) & > - (mtrr_physmask | 0xfffL)) + 1; > + (mtrr_physmask | 0xfffLL)) + 1; > if (!mrvalid(mrd->mr_base, mrd->mr_len)) > mrd->mr_flags |= MDF_BOGUS; > > @@ -638,7 +638,7 @@ x86_mrinit(struct mem_range_softc *sc) > * Determine the size of the PhysMask and PhysBase fields in > * the variable range MTRRs. > */ > - mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffUL; > + mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffULL; > > /* If fixed MTRRs supported and enabled. */ > if ((mtrrcap & MTRR_CAP_FIXED) && (mtrrdef & MTRR_DEF_FIXED_ENABLE)) { At -r313934 + patch seems to fix the hang on loading i915kms.ko and also the sloooow output to vt. Thanks for the quick response. I'll update to top of tree to check that there isn't any other problems. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow