Hi All,
With 2.6.29.1 (stock kernel), on my Dell Inspiron 1545, X freezes for
15-20 seconds at a time randomly every 10 seconds or so making it
unusable. Currently, I use the 2.6.29.1-54.fc11.x86_64 kernel that comes
with Fedora 11 Beta which has the same problem but only when X is left
idle for a period of time. The kernel log is overrun by messages of the
type:
X:2802 freeing invalid memtype e4b42000-e4b43000
X:2802 freeing invalid memtype e4b43000-e4b44000
X:2802 freeing invalid memtype e4b44000-e4b45000
This I believe is related to this:
mtrr: type mismatch for e0000000,10000000 old: write-back new:
write-combining
[drm] MTRR allocation failed. Graphics performance may suffer.
The MTRR setup is below:
reg00: base=0x000000000 ( 0MB), size=32768MB, count=1: write-back
reg01: base=0x0e0000000 ( 3584MB), size= 512MB, count=1: uncachable
reg02: base=0x07dc00000 ( 2012MB), size= 4MB, count=1: uncachable
reg03: base=0x07e000000 ( 2016MB), size= 32MB, count=1: uncachable
I think the first entry is bogus. Both kernels come with the
MTRR sanitize option enabled but the code is unable to find an
optimal value. Is there any way to correct this? What values for
mtrr_gran_size and mtrr_chunk_size would be appropriate?
While the stock kernel is not usable, the Fedora kernel is okay and X
performance is not slow as well (500fps with glxgears). I've attached
the dmesg log from the Fedora kernel (stock kernel buffer is overrun
in a few seconds) and the configs of both. Let me know if you need
anything else.
Regards,
David.
On Thu, Apr 16, 2009 at 12:06 AM, David John <[email protected]> wrote:
> Hi All,
>
> With 2.6.29.1 (stock kernel), on my Dell Inspiron 1545, X freezes for
> 15-20 seconds at a time randomly every 10 seconds or so making it
> unusable. Currently, I use the 2.6.29.1-54.fc11.x86_64 kernel that comes
> with Fedora 11 Beta which has the same problem but only when X is left
> idle for a period of time. The kernel log is overrun by messages of the
> type:
>
> X:2802 freeing invalid memtype e4b42000-e4b43000
> X:2802 freeing invalid memtype e4b43000-e4b44000
> X:2802 freeing invalid memtype e4b44000-e4b45000
can you try tip?
http://people.redhat.com/mingo/tip.git/readme.txt
it seems include one patch for that.
>
> This I believe is related to this:
>
> mtrr: type mismatch for e0000000,10000000 old: write-back new:
> write-combining
> [drm] MTRR allocation failed. ?Graphics performance may suffer.
>
> The MTRR setup is below:
> reg00: base=0x000000000 ( ? ?0MB), size=32768MB, count=1: write-back
> reg01: base=0x0e0000000 ( 3584MB), size= ?512MB, count=1: uncachable
> reg02: base=0x07dc00000 ( 2012MB), size= ? ?4MB, count=1: uncachable
> reg03: base=0x07e000000 ( 2016MB), size= ? 32MB, count=1: uncachable
>
> I think the first entry is bogus. Both kernels come with the
> MTRR sanitize option enabled but the code is unable to find an
> optimal value. Is there any way to correct this? What values for
> mtrr_gran_size and mtrr_chunk_size would be appropriate?
gran_size: 32M chunk_size: 128M num_reg: 7 lose cover RAM: 28M
YH
Specifically the patch here will help (not sure whether it cleanly applies over 29.1.
http://marc.info/?l=linux-kernel&m=123923026401648&w=2
Thanks,
Venki
>-----Original Message-----
>From: Yinghai Lu [mailto:[email protected]]
>Sent: Thursday, April 16, 2009 12:18 AM
>To: [email protected]
>Cc: [email protected]; Pallipadi, Venkatesh; Ingo
>Molnar; Jesse Barnes
>Subject: Re: X freezes intermittently with 2.6.29.1
>
>On Thu, Apr 16, 2009 at 12:06 AM, David John
><[email protected]> wrote:
>> Hi All,
>>
>> With 2.6.29.1 (stock kernel), on my Dell Inspiron 1545, X freezes for
>> 15-20 seconds at a time randomly every 10 seconds or so making it
>> unusable. Currently, I use the 2.6.29.1-54.fc11.x86_64
>kernel that comes
>> with Fedora 11 Beta which has the same problem but only when
>X is left
>> idle for a period of time. The kernel log is overrun by
>messages of the
>> type:
>>
>> X:2802 freeing invalid memtype e4b42000-e4b43000
>> X:2802 freeing invalid memtype e4b43000-e4b44000
>> X:2802 freeing invalid memtype e4b44000-e4b45000
>
>can you try tip?
>http://people.redhat.com/mingo/tip.git/readme.txt
>
>it seems include one patch for that.
>
>>
>> This I believe is related to this:
>>
>> mtrr: type mismatch for e0000000,10000000 old: write-back new:
>> write-combining
>> [drm] MTRR allocation failed. ?Graphics performance may suffer.
>>
>> The MTRR setup is below:
>> reg00: base=0x000000000 ( ? ?0MB), size=32768MB, count=1: write-back
>> reg01: base=0x0e0000000 ( 3584MB), size= ?512MB, count=1: uncachable
>> reg02: base=0x07dc00000 ( 2012MB), size= ? ?4MB, count=1: uncachable
>> reg03: base=0x07e000000 ( 2016MB), size= ? 32MB, count=1: uncachable
>>
>> I think the first entry is bogus. Both kernels come with the
>> MTRR sanitize option enabled but the code is unable to find an
>> optimal value. Is there any way to correct this? What values for
>> mtrr_gran_size and mtrr_chunk_size would be appropriate?
>
>gran_size: 32M chunk_size: 128M num_reg: 7
>lose cover RAM: 28M
>
>YH
>-
On 04/16/2009 11:08 PM, Pallipadi, Venkatesh wrote:
>
> Specifically the patch here will help (not sure whether it cleanly applies over 29.1.
>
> http://marc.info/?l=linux-kernel&m=123923026401648&w=2
>
> Thanks,
> Venki
>
Thanks Venkatesh, that patch fixes the problem. This should be submitted
to -stable as I know at least one other person who has
this regression and the latest Fedora kernels have the problem as well.
Regards,
David.
* David John <[email protected]> wrote:
> On 04/16/2009 11:08 PM, Pallipadi, Venkatesh wrote:
> >
> > Specifically the patch here will help (not sure whether it cleanly applies over 29.1.
> >
> > http://marc.info/?l=linux-kernel&m=123923026401648&w=2
> >
> > Thanks,
> > Venki
> >
>
> Thanks Venkatesh, that patch fixes the problem. This should be
> submitted to -stable as I know at least one other person who has
> this regression and the latest Fedora kernels have the problem as
> well.
It's now upstream via:
4b06504: x86, PAT: Remove page granularity tracking for vm_insert_pfn maps
also attached below. It cherry-picks fine on top of v2.6.29.
Ingo
----------->
>From 4b065046273afa01ec8e3de7da407e8d3599251d Mon Sep 17 00:00:00 2001
From: Pallipadi, Venkatesh <[email protected]>
Date: Wed, 8 Apr 2009 15:37:16 -0700
Subject: [PATCH] x86, PAT: Remove page granularity tracking for vm_insert_pfn maps
This change resolves the problem of too many single page entries
in pat_memtype_list and "freeing invalid memtype" errors with i915,
reported here:
http://marc.info/?l=linux-kernel&m=123845244713183&w=2
Remove page level granularity track and untrack of vm_insert_pfn.
memtype tracking at page granularity does not scale and cleaner
approach would be for the driver to request a type for a bigger
IO address range or PCI io memory range for that device, either at
mmap time or driver init time and just use that type during
vm_insert_pfn.
This patch just removes the track/untrack of vm_insert_pfn. That
means we will be in same state as 2.6.28, with respect to these APIs.
Newer APIs for the drivers to request a memtype for a bigger region
is coming soon.
[ Impact: fix Xorg startup warnings and hangs ]
Reported-by: Arkadiusz Miskiewicz <[email protected]>
Tested-by: Arkadiusz Miskiewicz <[email protected]>
Signed-off-by: Venkatesh Pallipadi <[email protected]>
Signed-off-by: Suresh Siddha <[email protected]>
Cc: Jesse Barnes <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/mm/pat.c | 98 ++++++++++------------------------------------------
1 files changed, 19 insertions(+), 79 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index cc5e0e2..41c8057 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -669,29 +669,28 @@ static void free_pfn_range(u64 paddr, unsigned long size)
*
* If the vma has a linear pfn mapping for the entire range, we get the prot
* from pte and reserve the entire vma range with single reserve_pfn_range call.
- * Otherwise, we reserve the entire vma range, my ging through the PTEs page
- * by page to get physical address and protection.
*/
int track_pfn_vma_copy(struct vm_area_struct *vma)
{
- int retval = 0;
- unsigned long i, j;
resource_size_t paddr;
unsigned long prot;
- unsigned long vma_start = vma->vm_start;
- unsigned long vma_end = vma->vm_end;
- unsigned long vma_size = vma_end - vma_start;
+ unsigned long vma_size = vma->vm_end - vma->vm_start;
pgprot_t pgprot;
if (!pat_enabled)
return 0;
+ /*
+ * For now, only handle remap_pfn_range() vmas where
+ * is_linear_pfn_mapping() == TRUE. Handling of
+ * vm_insert_pfn() is TBD.
+ */
if (is_linear_pfn_mapping(vma)) {
/*
* reserve the whole chunk covered by vma. We need the
* starting address and protection from pte.
*/
- if (follow_phys(vma, vma_start, 0, &prot, &paddr)) {
+ if (follow_phys(vma, vma->vm_start, 0, &prot, &paddr)) {
WARN_ON_ONCE(1);
return -EINVAL;
}
@@ -699,28 +698,7 @@ int track_pfn_vma_copy(struct vm_area_struct *vma)
return reserve_pfn_range(paddr, vma_size, &pgprot, 1);
}
- /* reserve entire vma page by page, using pfn and prot from pte */
- for (i = 0; i < vma_size; i += PAGE_SIZE) {
- if (follow_phys(vma, vma_start + i, 0, &prot, &paddr))
- continue;
-
- pgprot = __pgprot(prot);
- retval = reserve_pfn_range(paddr, PAGE_SIZE, &pgprot, 1);
- if (retval)
- goto cleanup_ret;
- }
return 0;
-
-cleanup_ret:
- /* Reserve error: Cleanup partial reservation and return error */
- for (j = 0; j < i; j += PAGE_SIZE) {
- if (follow_phys(vma, vma_start + j, 0, &prot, &paddr))
- continue;
-
- free_pfn_range(paddr, PAGE_SIZE);
- }
-
- return retval;
}
/*
@@ -730,50 +708,28 @@ cleanup_ret:
* prot is passed in as a parameter for the new mapping. If the vma has a
* linear pfn mapping for the entire range reserve the entire vma range with
* single reserve_pfn_range call.
- * Otherwise, we look t the pfn and size and reserve only the specified range
- * page by page.
- *
- * Note that this function can be called with caller trying to map only a
- * subrange/page inside the vma.
*/
int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t *prot,
unsigned long pfn, unsigned long size)
{
- int retval = 0;
- unsigned long i, j;
- resource_size_t base_paddr;
resource_size_t paddr;
- unsigned long vma_start = vma->vm_start;
- unsigned long vma_end = vma->vm_end;
- unsigned long vma_size = vma_end - vma_start;
+ unsigned long vma_size = vma->vm_end - vma->vm_start;
if (!pat_enabled)
return 0;
+ /*
+ * For now, only handle remap_pfn_range() vmas where
+ * is_linear_pfn_mapping() == TRUE. Handling of
+ * vm_insert_pfn() is TBD.
+ */
if (is_linear_pfn_mapping(vma)) {
/* reserve the whole chunk starting from vm_pgoff */
paddr = (resource_size_t)vma->vm_pgoff << PAGE_SHIFT;
return reserve_pfn_range(paddr, vma_size, prot, 0);
}
- /* reserve page by page using pfn and size */
- base_paddr = (resource_size_t)pfn << PAGE_SHIFT;
- for (i = 0; i < size; i += PAGE_SIZE) {
- paddr = base_paddr + i;
- retval = reserve_pfn_range(paddr, PAGE_SIZE, prot, 0);
- if (retval)
- goto cleanup_ret;
- }
return 0;
-
-cleanup_ret:
- /* Reserve error: Cleanup partial reservation and return error */
- for (j = 0; j < i; j += PAGE_SIZE) {
- paddr = base_paddr + j;
- free_pfn_range(paddr, PAGE_SIZE);
- }
-
- return retval;
}
/*
@@ -784,39 +740,23 @@ cleanup_ret:
void untrack_pfn_vma(struct vm_area_struct *vma, unsigned long pfn,
unsigned long size)
{
- unsigned long i;
resource_size_t paddr;
- unsigned long prot;
- unsigned long vma_start = vma->vm_start;
- unsigned long vma_end = vma->vm_end;
- unsigned long vma_size = vma_end - vma_start;
+ unsigned long vma_size = vma->vm_end - vma->vm_start;
if (!pat_enabled)
return;
+ /*
+ * For now, only handle remap_pfn_range() vmas where
+ * is_linear_pfn_mapping() == TRUE. Handling of
+ * vm_insert_pfn() is TBD.
+ */
if (is_linear_pfn_mapping(vma)) {
/* free the whole chunk starting from vm_pgoff */
paddr = (resource_size_t)vma->vm_pgoff << PAGE_SHIFT;
free_pfn_range(paddr, vma_size);
return;
}
-
- if (size != 0 && size != vma_size) {
- /* free page by page, using pfn and size */
- paddr = (resource_size_t)pfn << PAGE_SHIFT;
- for (i = 0; i < size; i += PAGE_SIZE) {
- paddr = paddr + i;
- free_pfn_range(paddr, PAGE_SIZE);
- }
- } else {
- /* free entire vma, page by page, using the pfn from pte */
- for (i = 0; i < vma_size; i += PAGE_SIZE) {
- if (follow_phys(vma, vma_start + i, 0, &prot, &paddr))
- continue;
-
- free_pfn_range(paddr, PAGE_SIZE);
- }
- }
}
pgprot_t pgprot_writecombine(pgprot_t prot)