Venki Pallipadi a =E9crit :
quoted text > On Thu, May 08, 2008 at 06:18:48AM -0700, Pallipadi, Venkatesh wrote:
> =20
>> =20
>>
>> =20
>>> -----Original Message-----
>>> From: Rufus & Azrael [mailto:rufus-azrael@numericable.fr]=20
>>> Sent: Thursday, May 08, 2008 12:09 AM
>>> To: Pallipadi, Venkatesh
>>> Cc: Ingo Molnar; Siddha, Suresh B; Linux-kernel Mailing List
>>> Subject: Re: [2.6.25-git18 =3D> 2.6.26-rc1-git1] Xorg crash with=20
>>> xf86MapVidMem error
>>>
>>> Pallipadi, Venkatesh a =E9crit :
>>> =20
>>>> =20
>>>> One more piece of data I need. Can you please send the=20
>>>> =20
>>> output of `cat /proc/mtrr` from this system (after the X=20
>>> failure has happened)
>>> =20
>>>> Thanks,
>>>> Venki
>>>>
>>>> =20
>>>> =20
>>> Hi Venki,
>>>
>>>
>>> See my /proc/mtrr file attached.
>>>
>>> =20
>> OK. Thanks for all the info.
>>
>> I think I figured out what is going wrong here:
>> 1) uvesafb is mapping 0xf0000000-0xf1000000
>> [4294014.924303] reserve_memtype added 0xf0000000-0xf1000000, track
>> uncached-minus, req uncached-minus, ret uncached-minus
>>
>> 2) Set up the framebuffer within that mapped region. Uvesafb is settin=
g
quoted text >> "write-combine" mtrr for framebuffer for this 16M. 0xf0000000-0xf10000=
00
quoted text >> [4294015.649340] uvesafb: framebuffer at 0xf0000000, mapped to
>> 0xffffc20010a80000, using 16384k, total 16384k
>> [4294015.649340] fb0: VESA VGA frame buffer device
>>
>> 3) Later when X starts up, it tries to map bigger PCI range
>> 0xf0000000-0xf8000000 from /dev/mem.
>>
>> 4) PAT check tries to make sure the entire region being mmap'ed is of =
the
quoted text >> same effective memory type. But in this case start of the address
>> (0xf0000000) is write-combine and end of the address is uncached. So,
>> with the new PAT code mmap fails with EINVAL, resulting in X failure.
>> xf86MapVidMem: Could not mmap framebuffer (0xf0000000,0x8000000) (Inva=
lid
quoted text >> argument)
>>
>>
>> Now we need to figure out a clean solution for this problem. I think w=
e
quoted text >> don't have to check the full range of address is of same type as long =
as we
quoted text >> are requesting for PAT type UC_MINUS and MTRR has WC sub ranges. But, =
we
quoted text >> need to think about other such conflict conditiond when having multipl=
e
quoted text >> users of same range (uvesafb and X) also. Will be back with a patch fo=
r
quoted text >> you to try and test.
>>
>> =20
>
> Hi,
>
> Can you please check whether the patch below solves this problem. Also,=
please
quoted text > send in 'dmesg' and /proc/mtrr output after you boot with this patch.
>
> Thanks,
> Venki
>
>
> Use UC_MINUS in reserve_memtype call with -1, when MTRR lookup fails fo=
r any
quoted text > reason.
>
> Change the logic in mtrr_type_lookup to just get the type from the star=
t
quoted text > address. Using start and end adddress is not right/complete as start an=
d
quoted text > end can be covered by different mtrr (where old code will fail) or
> start and end can be in same mtrr, but still have some different
> memory type region in between. Using only start is less restrictive and=
quoted text > deterministic.
>
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
>
> ---
> arch/x86/kernel/cpu/mtrr/generic.c | 7 ++-----
> arch/x86/mm/pat.c | 8 +-------
> 2 files changed, 3 insertions(+), 12 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
quoted text > --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/generic.c 2008-05-02 09:45:=
23.000000000 -0700
quoted text > +++ linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c 2008-05-08 12:22:16.00=
0000000 -0700
quoted text > @@ -48,7 +48,6 @@ module_param_named(show, mtrr_show, bool
> /*
> * Returns the effective MTRR type for the region
> * Error returns:
> - * - 0xFE - when the range is "not entirely covered" by _any_ var rang=
e MTRR
quoted text > * - 0xFF - when MTRR is not enabled
> */
> u8 mtrr_type_lookup(u64 start, u64 end)
> @@ -96,7 +95,7 @@ u8 mtrr_type_lookup(u64 start, u64 end)
> =20
> prev_match =3D 0xFF;
> for (i =3D 0; i < num_var_ranges; ++i) {
> - unsigned short start_state, end_state;
> + unsigned short start_state;
> =20
> if (!(mtrr_state.var_ranges[i].mask_lo & (1 << 11)))
> continue;
> @@ -107,9 +106,7 @@ u8 mtrr_type_lookup(u64 start, u64 end)
> (mtrr_state.var_ranges[i].mask_lo & PAGE_MASK);
> =20
> start_state =3D ((start & mask) =3D=3D (base & mask));
> - end_state =3D ((end & mask) =3D=3D (base & mask));
> - if (start_state !=3D end_state)
> - return 0xFE;
> + /* Just check the type of start address */
> =20
> if ((start & mask) !=3D (base & mask)) {
> continue;
> Index: linux-2.6/arch/x86/mm/pat.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
quoted text > --- linux-2.6.orig/arch/x86/mm/pat.c 2008-05-07 13:35:56.000000000 -070=
0
quoted text > +++ linux-2.6/arch/x86/mm/pat.c 2008-05-08 12:22:35.000000000 -0700
> @@ -162,10 +162,6 @@ static int pat_x_mtrr_type(u64 start, u6
> *ret_prot =3D prot;
> return 0;
> }
> - if (mtrr_type =3D=3D 0xFE) { /* MTRR match error */
> - *ret_prot =3D _PAGE_CACHE_UC;
> - return -1;
> - }
> if (mtrr_type !=3D MTRR_TYPE_UNCACHABLE &&
> mtrr_type !=3D MTRR_TYPE_WRBACK &&
> mtrr_type !=3D MTRR_TYPE_WRCOMB) { /* MTRR type unhandled */
> @@ -244,9 +240,7 @@ int reserve_memtype(u64 start, u64 end,=20
> * no match.
> */
> u8 mtrr_type =3D mtrr_type_lookup(start, end);
> - if (mtrr_type =3D=3D 0xFE) { /* MTRR match error */
> - err =3D -1;
> - }
> + /* MTRR lookup failed - Use UC_MINUS*/
> =20
> if (mtrr_type =3D=3D MTRR_TYPE_WRBACK) {
> req_type =3D _PAGE_CACHE_WB;
>
> =20
Hi Venki,
Patch applied on 2.6.26-rc1-git5 and all works fine in X server with =20
CONFIG_X86_PAT=3Dy.
See dmesg and mtrr files attached.
Thanks for all,
Regards.
