[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7E82351C108FA840AB1866AC776AEC46587A0784@orsmsx505.amr.corp.intel.com>
Date: Thu, 16 Apr 2009 10:38:14 -0700
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To: Yinghai Lu <yhlu.kernel@...il.com>,
"davidjon@...ontk.org" <davidjon@...ontk.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: RE: X freezes intermittently with 2.6.29.1
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:yhlu.kernel@...il.com]
>Sent: Thursday, April 16, 2009 12:18 AM
>To: davidjon@...ontk.org
>Cc: linux-kernel@...r.kernel.org; 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
><davidjon@...ontk.org> 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
>--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists