similar to: [PATCH] linux: fix native build after c/s 338

vm_normal_page() @ linux-2.6-xen-sparse/mm/memory.c ... if (!vma->vm_flags & VM_RESERVED) print_bad_pte(vma, pte, addr); note:VM_RESERVED=0x00080000 This if clause is always false. Should it be "if (!(vma->vm_flags & VM_RESERVED))" ? -- yamahata _______________________________________________ Xen-devel mailing list

On 7/29/19 7:28 AM, Christoph Hellwig wrote: > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd, > where it can be replaced with a simple boolean local variable. > > Signed-off-by: Christoph Hellwig <hch at lst.de> Reviewed-by: Ralph Campbell <rcampbell at nvidia.com> > --- > include/linux/migrate.h | 1 - > mm/migrate.c | 9

The code hasn't been used since it was added to the tree, and doesn't appear to actually be usable. Signed-off-by: Christoph Hellwig <hch at lst.de> Reviewed-by: Jason Gunthorpe <jgg at mellanox.com> Acked-by: Michal Hocko <mhocko at suse.com> --- include/linux/hmm.h | 4 ++-- include/linux/ioport.h | 1 - include/linux/memremap.h | 8 --------

Am 22.01.24 um 04:32 schrieb Xianrong Zhou: > The vmf_insert_pfn_prot could cause unnecessary double faults > on a device pfn. Because currently the vmf_insert_pfn_prot does > not make the pfn writable so the pte entry is normally read-only > or dirty catching. What? How do you got to this conclusion? > The first fault only sets up the pte entry which actually is > dirty

direct_remap_pfn_range() does not properly mark vma with VM_PFNMAP. This triggers improper reference counting on what rmap thought was a normal page, and a subsequent BUG() such as: Eeek! page_mapcount(page) went negative! (-1) page->flags = 414 page->count = 1 page->mapping = 00000000 ------------[ cut here ]------------ kernel BUG at

Am 23.01.24 um 09:33 schrieb Zhou, Xianrong: > [AMD Official Use Only - General] > >>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >>> device pfn. Because currently the vmf_insert_pfn_prot does not make >>> the pfn writable so the pte entry is normally read-only or dirty >>> catching. >> What? How do you got to this conclusion?

Am 24.01.24 um 03:43 schrieb Zhou, Xianrong: > [AMD Official Use Only - General] > >>>>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >>>>> device pfn. Because currently the vmf_insert_pfn_prot does not make >>>>> the pfn writable so the pte entry is normally read-only or dirty >>>>> catching. >>>>

On Tue, Oct 25, 2016 at 10:26 AM, Leon Fauster <leonfauster at googlemail.com> wrote: > Am 25.10.2016 um 15:39 schrieb Peter Kjellstr?m <cap at nsc.liu.se>: >> On Tue, 25 Oct 2016 10:06:12 +0200 >> Christian Anthon <anthon at rth.dk> wrote: >> >>> What is the best approach on centos 6 to mitigate the problem is >>> officially patched? As far

"Zhou, Xianrong" <Xianrong.Zhou at amd.com> writes: > [AMD Official Use Only - General] > >> >>>>> The vmf_insert_pfn_prot could cause unnecessary double faults on a >> >>>>> device pfn. Because currently the vmf_insert_pfn_prot does not >> >>>>> make the pfn writable so the pte entry is normally read-only or

> I am using a random intercept model with SITEID as random and NAUSEA as > outcome. > > I tried using a dataset without missing values and changed my model > statement accordingly but still get the same error. Follwoing in an excerpt. > > anal.data <- read.table("nausea.txt", header=T, sep="\t") > > list(names(anal.data)) > [[1]] > [1]

I am using a random intercept model with SITEID as random and NAUSEA as outcome. Thanks. Anamika I tried using a dataset without missing values and changed my model statement accordingly but still get the same error. Follwoing in an excerpt. > anal.data <- read.table("nausea.txt", header=T, sep="\t") > list(names(anal.data)) [[1]] [1] "SITEID"

Hi:   I am using the following code to read a data set in txt in R and using the follwoing model. But it seems to give me an error ' expected variable name error pos 134022'. Any help is greatly appreciated.   Code: anal.data <- read.table("nausea.txt", header=T, sep="\t") list(names(anal.data)) attach(anal.data) n.samples <- dim(anal.data) [1] # number of data

Hi, All! I met a bug when destroyed the VMX. page_remove_rmap() BUG on page->_mapcount when QEMU exited. I try to solve this problem but I''m not familiar with MM code. So I wanna ask you guys several questions and hope you can give some clues: 1)If we map a foreign page(DomainU or VMX) to Domain0 through xc_map_foreign_range, the pfn(in Domain0''s memory space)which points to

This is my first excursion into using reshape2 and I want to ensure that the melt() function call is syntactically correct. The unmodifed data frame is organized this way: head(tds.anal) site sampdate param quant 1 UDS-O 2006-12-06 TDS 10800 4 STC-FS 1996-06-14 Cond 280 7 UDS-O 2007-10-04 Mg 1620 9 UDS-O 2007-10-04 SO4 7580 19 JCM-10B 2007-06-21 Ca 79 20

Hello All I made the mistake of assuming all Intel motherboards would be Linux compatible out of the box and bought one without checking support information. And now on initial install the Network is not working....the Network port is not detected at all. I have bought an Intel board DG41RQI (http://www.intel.com/support/motherboards/desktop/DG41RQ/index.htm) which does not support Linux Out of

Thanks to David's help I subset my large data set and produced a smaller one for a single stream and 7 factors of interest. The structure of this data frame is: str(burns.tds.anal) 'data.frame': 718 obs. of 4 variables: $ site : Factor w/ 143 levels "BC-0.5","BC-1",..: 1 1 4 6 4 4 4 5 5 5 $ sampdate: Date, format: "1996-06-02"

On Thu 04-04-19 05:09:10, Pankaj Gupta wrote: > > > > On Thu, Apr 04, 2019 at 09:09:12AM +1100, Dave Chinner wrote: > > > > On Wed, Apr 03, 2019 at 04:10:18PM +0530, Pankaj Gupta wrote: > > > > > Virtio pmem provides asynchronous host page cache flush > > > > > mechanism. we don't support 'MAP_SYNC' with virtio pmem > > >

On Thu, Apr 04, 2019 at 06:08:44AM -0400, Pankaj Gupta wrote: > > > On Thu 04-04-19 05:09:10, Pankaj Gupta wrote: > > > > > > > > On Thu, Apr 04, 2019 at 09:09:12AM +1100, Dave Chinner wrote: > > > > > > On Wed, Apr 03, 2019 at 04:10:18PM +0530, Pankaj Gupta wrote: > > > > > > > Virtio pmem provides asynchronous host page

> On Thu 04-04-19 05:09:10, Pankaj Gupta wrote: > > > > > > On Thu, Apr 04, 2019 at 09:09:12AM +1100, Dave Chinner wrote: > > > > > On Wed, Apr 03, 2019 at 04:10:18PM +0530, Pankaj Gupta wrote: > > > > > > Virtio pmem provides asynchronous host page cache flush > > > > > > mechanism. we don't support 'MAP_SYNC'

> On Thu 04-04-19 05:09:10, Pankaj Gupta wrote: > > > > > > On Thu, Apr 04, 2019 at 09:09:12AM +1100, Dave Chinner wrote: > > > > > On Wed, Apr 03, 2019 at 04:10:18PM +0530, Pankaj Gupta wrote: > > > > > > Virtio pmem provides asynchronous host page cache flush > > > > > > mechanism. we don't support 'MAP_SYNC'