Date: Sat, 25 Oct 2014 12:00:00 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Rui Paulo <rpaulo@me.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Rui Paulo <rpaulo@FreeBSD.org> Subject: Re: svn commit: r273598 - in head: include sys/dev/acpica Message-ID: <20141025090000.GG1877@kib.kiev.ua> In-Reply-To: <20141024194546.GE1877@kib.kiev.ua> References: <33decfcd-e77c-4e4c-8161-9f4a232213c6@me.com> <20141024194546.GE1877@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 24, 2014 at 10:45:46PM +0300, Konstantin Belousov wrote:
> On Fri, Oct 24, 2014 at 07:33:07PM +0000, Rui Paulo wrote:
> > On Oct 24, 2014, at 12:20 PM, Konstantin Belousov <kostikbel@gmail.com> wrote:
> >
> > > +static int
> > > +hpet_mmap(struct cdev *cdev, vm_ooffset_t offset, vm_paddr_t *paddr,
> > > + int nprot, vm_memattr_t *memattr)
> > > +{
> > > + š šstruct hpet_softc *sc;
> > > +
> > > + š šsc = cdev->si_drv1;
> > > + š š š šif (offset > rman_get_size(sc->mem_res))
> > > + š š š š š š š šreturn (EINVAL);
> > > + š šif (!sc->mmap_allow_write && (nprot & PROT_WRITE))
> > > + š š šreturn (EPERM);
> > > + š š š*paddr = rman_get_start(sc->mem_res) + offset;
> > What is the memattr for the backing page ? Is it set to non-cached
> > mode somehow ? I was not able to find place where would this happen.
> > š
> > I expect it to be set to non-cached since it's a device anyway, but I don't know where it is. šDuring my testing, I did not see any problems with cached values, though.
> >
> I am not claiming that it is wrong, only that I do not see an easy reason
> why it is right. Just printing the *memattr would provide the confidence.
>
Ok, I did looked at the pte of the HPET page. I get the value
0x80000000fed00025
which coincides with the resource address 0xfed00000 reported
by devinfo -vr for hpet (to double-check my findings). The low
bits indicate that PAT0 pat entry is used for the page caching
mode. Corresponding PAT MSR 0x277 has the following value:
sandy% sudo cpucontrol -m 0x277 /dev/cpuctl0
MSR 0x277: 0x00010506 0x00070406
i.e. memory type is 6, which is write-back, according to SDM.
This is wrong, as I feared.
The patch below fixes the issue. The pte for HPET page is equal to
0x80000000fed0003d
after the patch is applied, PAT3 is used, and its value is 0 ==
UNCACHEABLE, as it must be.
Do you agree with the patch ?
diff --git a/sys/dev/acpica/acpi_hpet.c b/sys/dev/acpica/acpi_hpet.c
index 6b35f5c..0da8bae 100644
--- a/sys/dev/acpica/acpi_hpet.c
+++ b/sys/dev/acpica/acpi_hpet.c
@@ -356,6 +356,7 @@ hpet_mmap(struct cdev *cdev, vm_ooffset_t offset, vm_paddr_t *paddr,
if (!sc->mmap_allow_write && (nprot & PROT_WRITE))
return (EPERM);
*paddr = rman_get_start(sc->mem_res) + offset;
+ *memattr = VM_MEMATTR_UNCACHEABLE;
return (0);
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141025090000.GG1877>