From owner-svn-src-head@FreeBSD.ORG Tue Jul 15 04:26:56 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE2504BF; Tue, 15 Jul 2014 04:26:56 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 B41D9269F; Tue, 15 Jul 2014 04:26:56 +0000 (UTC) Received: from zeppelin.tachypleus.net (173-161-16-229-Illinois.hfc.comcastbusiness.net [173.161.16.229]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s6F4QljU027751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Jul 2014 21:26:48 -0700 Message-ID: <53C4AD87.402@freebsd.org> Date: Mon, 14 Jul 2014 21:26:47 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: svn commit: r268624 - head/sys/dev/vt/hw/efifb References: <201407141742.s6EHgMNt094168@svn.freebsd.org> <20140714175345.GK93733@kib.kiev.ua> <53C424B7.7070403@freebsd.org> <20140714184725.GL93733@kib.kiev.ua> In-Reply-To: <20140714184725.GL93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;mBYKPNgL5BGEP02zUc16mQ== M;eKOIPNgL5BGEP02zUc16mQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 04:26:56 -0000 On 07/14/14 11:47, Konstantin Belousov wrote: > On Mon, Jul 14, 2014 at 11:43:03AM -0700, Nathan Whitehorn wrote: >> On 07/14/14 10:53, Konstantin Belousov wrote: >>> On Mon, Jul 14, 2014 at 05:42:22PM +0000, Nathan Whitehorn wrote: >>>> + info->fb_vbase = (intptr_t)pmap_mapdev_attr(info->fb_pbase, >>>> + info->fb_size, VM_MEMATTR_WRITE_COMBINING); >>>> +} >>>> + >>> Could you use pmap_change_attr() ? This would save some KVA. >> Does that work with the direct map? I'm pretty hesitant to muck with the >> direct map region this way... > Yes, it works on direct map. > > Note that Intel explicitely states that the behaviour is undefined > if the same physical page is mapped with differrent caching attributes. > At least some revisions of Pentium IV hang in this situation. > > We keep direct map mapping attributes consistent with other mappings. Ah, interesting. I'll try to correct it tomorrow. I'm at a conference in Chicago at the moment, which means it might take a little longer than usual. -Nathan