Date: Mon, 14 Jul 2014 21:26:47 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r268624 - head/sys/dev/vt/hw/efifb Message-ID: <53C4AD87.402@freebsd.org> In-Reply-To: <20140714184725.GL93733@kib.kiev.ua> References: <201407141742.s6EHgMNt094168@svn.freebsd.org> <20140714175345.GK93733@kib.kiev.ua> <53C424B7.7070403@freebsd.org> <20140714184725.GL93733@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53C4AD87.402>