Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error

 

 

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


rufus-azrael at numericable

May 4, 2008, 1:24 AM

Post #1 of 32 (2714 views)
Permalink
[2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error

When upgrading to 2.6.25-git18 and above kernel this Xorg error occurs :

xf86MapVidMem: Could not mmap framebuffer (0xf0000000,0x8000000)
(Invalid argument)

The latest working kernel was 25-git17 and perhaps is it related to
http://lkml.org/lkml/2008/4/28/52

My .config and Xorg-log files are attached.

Best regards.
Attachments: .config-2.6.26-rc1-git1 (47.7 KB)
  Xorg.0.log.old (29.6 KB)


mingo at elte

May 4, 2008, 1:52 AM

Post #2 of 32 (2694 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

* Rufus & Azrael <rufus-azrael[at]numericable.fr> wrote:

> When upgrading to 2.6.25-git18 and above kernel this Xorg error occurs :
>
> xf86MapVidMem: Could not mmap framebuffer (0xf0000000,0x8000000) (Invalid
> argument)
>
> The latest working kernel was 25-git17 and perhaps is it related to
> http://lkml.org/lkml/2008/4/28/52

does this X-does-not-start-up problem go away if you disable this
option:

> CONFIG_X86_PAT=y

?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rufus-azrael at numericable

May 4, 2008, 2:03 AM

Post #3 of 32 (2688 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

Ingo Molnar a écrit :
> * Rufus & Azrael <rufus-azrael[at]numericable.fr> wrote:
>
>
>> When upgrading to 2.6.25-git18 and above kernel this Xorg error occurs :
>>
>> xf86MapVidMem: Could not mmap framebuffer (0xf0000000,0x8000000) (Invalid
>> argument)
>>
>> The latest working kernel was 25-git17 and perhaps is it related to
>> http://lkml.org/lkml/2008/4/28/52
>>
>
> does this X-does-not-start-up problem go away if you disable this
> option:
>
>
>> CONFIG_X86_PAT=y
>>
>
> ?
>
> Ingo
>
>
Thanks for your help Ingo, all work fine when CONFIG_PAT=n :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


suresh.b.siddha at intel

May 5, 2008, 10:26 AM

Post #4 of 32 (2676 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

On Sun, May 04, 2008 at 11:03:52AM +0200, Rufus & Azrael wrote:
> Ingo Molnar a écrit :
> >* Rufus & Azrael <rufus-azrael[at]numericable.fr> wrote:
> >>When upgrading to 2.6.25-git18 and above kernel this Xorg error occurs :
> >>
> >>xf86MapVidMem: Could not mmap framebuffer (0xf0000000,0x8000000) (Invalid
> >>argument)
> >>
> >>The latest working kernel was 25-git17 and perhaps is it related to
> >>http://lkml.org/lkml/2008/4/28/52
> >>
> >
> >does this X-does-not-start-up problem go away if you disable this
> >option:
> >
> >>CONFIG_X86_PAT=y
> >>
> >
> >?
> >
> Thanks for your help Ingo, all work fine when CONFIG_PAT=n :-)

hi, Can you please send us the "dmesg" output in the failing scenario
with PAT enabled, after the X crash?

thanks,
suresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rufus-azrael at numericable

May 5, 2008, 3:19 PM

Post #5 of 32 (2674 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

Suresh Siddha a écrit :
> On Sun, May 04, 2008 at 11:03:52AM +0200, Rufus & Azrael wrote:
>
>> Ingo Molnar a écrit :
>>
>>> * Rufus & Azrael <rufus-azrael[at]numericable.fr> wrote:
>>>
>>>> When upgrading to 2.6.25-git18 and above kernel this Xorg error occurs :
>>>>
>>>> xf86MapVidMem: Could not mmap framebuffer (0xf0000000,0x8000000) (Invalid
>>>> argument)
>>>>
>>>> The latest working kernel was 25-git17 and perhaps is it related to
>>>> http://lkml.org/lkml/2008/4/28/52
>>>>
>>>>
>>> does this X-does-not-start-up problem go away if you disable this
>>> option:
>>>
>>>
>>>> CONFIG_X86_PAT=y
>>>>
>>>>
>>> ?
>>>
>>>
>> Thanks for your help Ingo, all work fine when CONFIG_PAT=n :-)
>>
>
> hi, Can you please send us the "dmesg" output in the failing scenario
> with PAT enabled, after the X crash?
>
> thanks,
> suresh
>
>
Hi,

Here is my dmesg with 2.6.26-rc1-git3 and CONFIG_X86_PAT=y

Hope it can help you to fixe the crash.

Regards.
Attachments: dmesg (30.3 KB)


venkatesh.pallipadi at intel

May 5, 2008, 4:25 PM

Post #6 of 32 (2686 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

On Mon, May 05, 2008 at 03:19:30PM -0700, Rufus & Azrael wrote:
> Suresh Siddha a ecrit :
> > On Sun, May 04, 2008 at 11:03:52AM +0200, Rufus & Azrael wrote:
> >
> >> Ingo Molnar a ecrit :
> >>
> >>> * Rufus & Azrael <rufus-azrael[at]numericable.fr> wrote:
> >>>
> >>>> When upgrading to 2.6.25-git18 and above kernel this Xorg error
> occurs :
> >>>>
> >>>> xf86MapVidMem: Could not mmap framebuffer (0xf0000000,0x8000000)
> (Invalid
> >>>> argument)
> >>>>
> >>>> The latest working kernel was 25-git17 and perhaps is it related to
> >>>> [1]http://lkml.org/lkml/2008/4/28/52
> >>>>
> >>>>
> >>> does this X-does-not-start-up problem go away if you disable this
> >>> option:
> >>>
> >>>
> >>>> CONFIG_X86_PAT=y
> >>>>
> >>>>
> >>> ?
> >>>
> >>>
> >> Thanks for your help Ingo, all work fine when CONFIG_PAT=n :-)
> >>
> >
> > hi, Can you please send us the "dmesg" output in the failing scenario
> > with PAT enabled, after the X crash?
> >
> > thanks,
> > suresh
> >
> >
> Hi,
>
> Here is my dmesg with 2.6.26-rc1-git3 and CONFIG_X86_PAT=y
>
> Hope it can help you to fixe the crash.
>

Did you capture dmesg after X failed to start? Only relevent msg I see is

> [ 0.333352] [drm] Initialized radeon 1.28.0 20060524 on minor 0
> [ 0.334110] uvesafb: (C) 1988-2005, ATI Technologies Inc. RS69001.00, RS69001.00, 01.00, OEM: ATI ATOMBIOS(C) 1988-2005, ATI Technologies Inc. RS69001.00, VBE v3.0
> [ 0.351570] uvesafb: VBIOS/hardware supports DDC2 transfers
> [ 0.410125] uvesafb: monitor limits: vf = 75 Hz, hf = 83 kHz, clk = 140 MHz
> [ 0.410313] uvesafb: scrolling: redraw
> [ 0.412579] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
> [ 0.657370] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
> [ 0.894472] Console: switching to colour frame buffer device 160x64
> [ 0.894532] uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings.
> [ 1.128483] uvesafb: framebuffer at 0xf0000000, mapped to 0xffffc20010a80000, using 16384k, total 16384k
> [ 1.128518] fb0: VESA VGA frame buffer device

Which seems to be mapping framebuffer successfully.

Can you please try the patch below and capture the dmesg after you get the
above xf86MapVidMem error and send it. That should give us more information
on the failure.

Thanks,
Venki

Index: linux-2.6/arch/x86/mm/pat.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/pat.c 2008-05-05 14:13:16.000000000 -0700
+++ linux-2.6/arch/x86/mm/pat.c 2008-05-05 15:54:21.000000000 -0700
@@ -7,6 +7,8 @@
* Loosely based on earlier PAT patchset from Eric Biederman and Andi Kleen.
*/

+#define DEBUG
+
#include <linux/mm.h>
#include <linux/kernel.h>
#include <linux/gfp.h>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

May 5, 2008, 4:49 PM

Post #7 of 32 (2686 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

* Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:

> Which seems to be mapping framebuffer successfully.
>
> Can you please try the patch below and capture the dmesg after you get
> the above xf86MapVidMem error and send it. That should give us more
> information on the failure.

> +#define DEBUG

btw., could we turn this into a /debug or sysctl flag thing, to make it
easier for people to get these debug messages?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


venkatesh.pallipadi at intel

May 5, 2008, 7:09 PM

Post #8 of 32 (2685 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

On Tue, May 06, 2008 at 01:49:39AM +0200, Ingo Molnar wrote:
>
> * Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:
>
> > Which seems to be mapping framebuffer successfully.
> >
> > Can you please try the patch below and capture the dmesg after you get
> > the above xf86MapVidMem error and send it. That should give us more
> > information on the failure.
>
> > +#define DEBUG
>
> btw., could we turn this into a /debug or sysctl flag thing, to make it
> easier for people to get these debug messages?
>

Below is the patch to enable debug messages by a boot option "debugpat".

We are also planning to a /proc or /debug entry to dump the memtype
list at runtime rather than depending on full dmesg. Will send the patch soon.

Thanks,
Venki



Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi[at]intel.com>

---
arch/x86/mm/pat.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)

Index: linux-2.6/arch/x86/mm/pat.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/pat.c 2008-05-05 18:27:30.000000000 -0700
+++ linux-2.6/arch/x86/mm/pat.c 2008-05-05 18:28:38.000000000 -0700
@@ -38,6 +38,19 @@ static int nopat(char *str)
}
early_param("nopat", nopat);

+
+static int debug_enable;
+static int __init pat_debug_setup(char *str)
+{
+ debug_enable = 1;
+ return 0;
+}
+__setup("debugpat", pat_debug_setup);
+
+#define PAT_PRINTK(fmt, arg...) \
+ do { if (debug_enable) printk(KERN_INFO fmt, ##arg); } while (0)
+
+
static int pat_known_cpu(void)
{
if (!pat_wc_enabled)
@@ -285,7 +298,7 @@ int reserve_memtype(u64 start, u64 end,
struct memtype *saved_ptr;

if (parse->start >= end) {
- pr_debug("New Entry\n");
+ PAT_PRINTK("New Entry\n");
list_add(&new_entry->nd, parse->nd.prev);
new_entry = NULL;
break;
@@ -335,7 +348,7 @@ int reserve_memtype(u64 start, u64 end,
break;
}

- pr_debug("Overlap at 0x%Lx-0x%Lx\n",
+ PAT_PRINTK("Overlap at 0x%Lx-0x%Lx\n",
saved_ptr->start, saved_ptr->end);
/* No conflict. Go ahead and add this new entry */
list_add(&new_entry->nd, saved_ptr->nd.prev);
@@ -387,7 +400,7 @@ int reserve_memtype(u64 start, u64 end,
break;
}

- pr_debug(KERN_INFO "Overlap at 0x%Lx-0x%Lx\n",
+ PAT_PRINTK("Overlap at 0x%Lx-0x%Lx\n",
saved_ptr->start, saved_ptr->end);
/* No conflict. Go ahead and add this new entry */
list_add(&new_entry->nd, &saved_ptr->nd);
@@ -409,16 +422,16 @@ int reserve_memtype(u64 start, u64 end,
if (new_entry) {
/* No conflict. Not yet added to the list. Add to the tail */
list_add_tail(&new_entry->nd, &memtype_list);
- pr_debug("New Entry\n");
+ PAT_PRINTK("New Entry\n");
}

if (ret_type) {
- pr_debug(
+ PAT_PRINTK(
"reserve_memtype added 0x%Lx-0x%Lx, track %s, req %s, ret %s\n",
start, end, cattr_name(actual_type),
cattr_name(req_type), cattr_name(*ret_type));
} else {
- pr_debug(
+ PAT_PRINTK(
"reserve_memtype added 0x%Lx-0x%Lx, track %s, req %s\n",
start, end, cattr_name(actual_type),
cattr_name(req_type));
@@ -459,7 +472,7 @@ int free_memtype(u64 start, u64 end)
current->comm, current->pid, start, end);
}

- pr_debug("free_memtype request 0x%Lx-0x%Lx\n", start, end);
+ PAT_PRINTK("free_memtype request 0x%Lx-0x%Lx\n", start, end);
return err;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

May 6, 2008, 4:55 AM

Post #9 of 32 (2676 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

* Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:

> Below is the patch to enable debug messages by a boot option
> "debugpat".

ok, i have applied the patch with some modifications - see below.

Since we build in this code unconditionally also make the flag
switchable from a sysctl, so that users do not have to reboot to see PAT
debug messages ...

i have renamed PAT_PRINTK to dprintk.

Ingo

------------>
Subject: x86: add "debugpat" boot option
From: Venki Pallipadi <venkatesh.pallipadi[at]intel.com>
Date: Mon, 5 May 2008 19:09:10 -0700

enable debug messages by a boot option "debugpat".

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi[at]intel.com>
Signed-off-by: Ingo Molnar <mingo[at]elte.hu>
---
arch/x86/mm/pat.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)

Index: linux-x86.q/arch/x86/mm/pat.c
===================================================================
--- linux-x86.q.orig/arch/x86/mm/pat.c
+++ linux-x86.q/arch/x86/mm/pat.c
@@ -38,6 +38,19 @@ static int nopat(char *str)
}
early_param("nopat", nopat);

+
+static int debug_enable;
+static int __init pat_debug_setup(char *str)
+{
+ debug_enable = 1;
+ return 0;
+}
+__setup("debugpat", pat_debug_setup);
+
+#define dprintk(fmt, arg...) \
+ do { if (debug_enable) printk(KERN_INFO fmt, ##arg); } while (0)
+
+
static int pat_known_cpu(void)
{
if (!pat_wc_enabled)
@@ -285,7 +298,7 @@ int reserve_memtype(u64 start, u64 end,
struct memtype *saved_ptr;

if (parse->start >= end) {
- pr_debug("New Entry\n");
+ dprintk("New Entry\n");
list_add(&new_entry->nd, parse->nd.prev);
new_entry = NULL;
break;
@@ -335,7 +348,7 @@ int reserve_memtype(u64 start, u64 end,
break;
}

- pr_debug("Overlap at 0x%Lx-0x%Lx\n",
+ dprintk("Overlap at 0x%Lx-0x%Lx\n",
saved_ptr->start, saved_ptr->end);
/* No conflict. Go ahead and add this new entry */
list_add(&new_entry->nd, saved_ptr->nd.prev);
@@ -387,7 +400,7 @@ int reserve_memtype(u64 start, u64 end,
break;
}

- pr_debug(KERN_INFO "Overlap at 0x%Lx-0x%Lx\n",
+ dprintk("Overlap at 0x%Lx-0x%Lx\n",
saved_ptr->start, saved_ptr->end);
/* No conflict. Go ahead and add this new entry */
list_add(&new_entry->nd, &saved_ptr->nd);
@@ -409,16 +422,16 @@ int reserve_memtype(u64 start, u64 end,
if (new_entry) {
/* No conflict. Not yet added to the list. Add to the tail */
list_add_tail(&new_entry->nd, &memtype_list);
- pr_debug("New Entry\n");
+ dprintk("New Entry\n");
}

if (ret_type) {
- pr_debug(
+ dprintk(
"reserve_memtype added 0x%Lx-0x%Lx, track %s, req %s, ret %s\n",
start, end, cattr_name(actual_type),
cattr_name(req_type), cattr_name(*ret_type));
} else {
- pr_debug(
+ dprintk(
"reserve_memtype added 0x%Lx-0x%Lx, track %s, req %s\n",
start, end, cattr_name(actual_type),
cattr_name(req_type));
@@ -459,7 +472,7 @@ int free_memtype(u64 start, u64 end)
current->comm, current->pid, start, end);
}

- pr_debug("free_memtype request 0x%Lx-0x%Lx\n", start, end);
+ dprintk("free_memtype request 0x%Lx-0x%Lx\n", start, end);
return err;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


venkatesh.pallipadi at intel

May 6, 2008, 1:34 PM

Post #10 of 32 (2681 views)
Permalink
RE: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

>-----Original Message-----
>From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>Sent: Tuesday, May 06, 2008 10:32 AM
>To: Ingo Molnar
>Cc: Pallipadi, Venkatesh; Siddha, Suresh B; Linux-kernel Mailing List
>Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>xf86MapVidMem error
>
>Ingo Molnar a écrit :
>> * Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:
>>
>>
>>> Below is the patch to enable debug messages by a boot option
>>> "debugpat".
>>>
>Hi all,
>
>I have applied the patch from Ingo and I put my
>dmesg/syslog/messages/Xorg.log files in attached to help you
>to identify
>the problem (two mails).
>
>Hope it can help you.
>

Did you use "debugpat" kernel boot option after applying Ingo's patch?
With Ingo's patch, that option is needed to print more info (Not needed with one line change I sent you yday).

Also, 'dmesg -s 256000' will not truncate the msg at 32K and will give bigger dmesg output.

Thanks,
Venki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rufus-azrael at numericable

May 6, 2008, 2:56 PM

Post #11 of 32 (2669 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

Pallipadi, Venkatesh a écrit :
>
>
>
>> -----Original Message-----
>> From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>> Sent: Tuesday, May 06, 2008 10:32 AM
>> To: Ingo Molnar
>> Cc: Pallipadi, Venkatesh; Siddha, Suresh B; Linux-kernel Mailing List
>> Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>> xf86MapVidMem error
>>
>> Ingo Molnar a écrit :
>>
>>> * Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:
>>>
>>>
>>>
>>>> Below is the patch to enable debug messages by a boot option
>>>> "debugpat".
>>>>
>>>>
>> Hi all,
>>
>> I have applied the patch from Ingo and I put my
>> dmesg/syslog/messages/Xorg.log files in attached to help you
>> to identify
>> the problem (two mails).
>>
>> Hope it can help you.
>>
>>
>
> Did you use "debugpat" kernel boot option after applying Ingo's patch?
> With Ingo's patch, that option is needed to print more info (Not needed with one line change I sent you yday).
>
> Also, 'dmesg -s 256000' will not truncate the msg at 32K and will give bigger dmesg output.
>
> Thanks,
> Venki
>
>
Hi,

Here is my dmesg.log file with CONFIG_X86_PAT=y and debugpat kernel boot
option.

Is it helpfull ? :-).

Regards.
Attachments: dmesg.log (30.7 KB)


venkatesh.pallipadi at intel

May 6, 2008, 3:05 PM

Post #12 of 32 (2654 views)
Permalink
RE: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

>-----Original Message-----
>From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>Sent: Tuesday, May 06, 2008 2:57 PM
>To: Pallipadi, Venkatesh
>Cc: Ingo Molnar; Siddha, Suresh B; Linux-kernel Mailing List
>Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>xf86MapVidMem error
>
>Pallipadi, Venkatesh a écrit :
>>
>>
>>
>>> -----Original Message-----
>>> From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>>> Sent: Tuesday, May 06, 2008 10:32 AM
>>> To: Ingo Molnar
>>> Cc: Pallipadi, Venkatesh; Siddha, Suresh B; Linux-kernel
>Mailing List
>>> Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>>> xf86MapVidMem error
>>>
>>> Ingo Molnar a écrit :
>>>
>>>> * Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:
>>>>
>>>>
>>>>
>>>>> Below is the patch to enable debug messages by a boot option
>>>>> "debugpat".
>>>>>
>>>>>
>>> Hi all,
>>>
>>> I have applied the patch from Ingo and I put my
>>> dmesg/syslog/messages/Xorg.log files in attached to help you
>>> to identify
>>> the problem (two mails).
>>>
>>> Hope it can help you.
>>>
>>>
>>
>> Did you use "debugpat" kernel boot option after applying
>Ingo's patch?
>> With Ingo's patch, that option is needed to print more info
>(Not needed with one line change I sent you yday).
>>
>> Also, 'dmesg -s 256000' will not truncate the msg at 32K and
>will give bigger dmesg output.
>>
>> Thanks,
>> Venki
>>
>>
>Hi,
>
>Here is my dmesg.log file with CONFIG_X86_PAT=y and debugpat
>kernel boot
>option.
>
>Is it helpfull ? :-).
>

Yes. This has some debug information in there. Did you see xf86MapVidMem error (I mean did you try to start X) before you captured this dmesg?

Thanks,
Venki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


venkatesh.pallipadi at intel

May 6, 2008, 3:51 PM

Post #13 of 32 (2680 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

On Tue, May 06, 2008 at 01:55:24PM +0200, Ingo Molnar wrote:
>
> * Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:
>
> > Below is the patch to enable debug messages by a boot option
> > "debugpat".
>
> ok, i have applied the patch with some modifications - see below.
>
> Since we build in this code unconditionally also make the flag
> switchable from a sysctl, so that users do not have to reboot to see PAT
> debug messages ...
>

Below patch adds the sysctl interface.

Thanks,
Venki


Add sysctl interface to runtime change debugpat setting.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi[at]intel.com>

---
arch/x86/mm/pat.c | 6 +++---
include/linux/kernel.h | 1 +
kernel/sysctl.c | 8 ++++++++
3 files changed, 12 insertions(+), 3 deletions(-)

Index: linux-2.6/arch/x86/mm/pat.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/pat.c 2008-05-06 10:52:51.000000000 -0700
+++ linux-2.6/arch/x86/mm/pat.c 2008-05-06 15:27:59.000000000 -0700
@@ -39,16 +39,16 @@ static int nopat(char *str)
early_param("nopat", nopat);


-static int debug_enable;
+int pat_debug_enable = 0;
static int __init pat_debug_setup(char *str)
{
- debug_enable = 1;
+ pat_debug_enable = 1;
return 0;
}
__setup("debugpat", pat_debug_setup);

#define dprintk(fmt, arg...) \
- do { if (debug_enable) printk(KERN_INFO fmt, ##arg); } while (0)
+ do { if (pat_debug_enable) printk(KERN_INFO fmt, ##arg); } while (0)


static int pat_known_cpu(void)
Index: linux-2.6/include/linux/kernel.h
===================================================================
--- linux-2.6.orig/include/linux/kernel.h 2008-05-02 09:45:26.000000000 -0700
+++ linux-2.6/include/linux/kernel.h 2008-05-06 10:54:06.000000000 -0700
@@ -239,6 +239,7 @@ extern int tainted;
extern const char *print_tainted(void);
extern void add_taint(unsigned);
extern int root_mountflags;
+extern int pat_debug_enable;

/* Values used for system_state */
extern enum system_states {
Index: linux-2.6/kernel/sysctl.c
===================================================================
--- linux-2.6.orig/kernel/sysctl.c 2008-05-02 09:45:26.000000000 -0700
+++ linux-2.6/kernel/sysctl.c 2008-05-06 10:55:08.000000000 -0700
@@ -685,6 +685,14 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "debugpat",
+ .data = &pat_debug_enable,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
#endif
#if defined(CONFIG_MMU)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


mingo at elte

May 7, 2008, 12:06 AM

Post #14 of 32 (2688 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

* Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:

> ---
> arch/x86/mm/pat.c | 6 +++---
> include/linux/kernel.h | 1 +
> kernel/sysctl.c | 8 ++++++++
> 3 files changed, 12 insertions(+), 3 deletions(-)

applied, thanks. Please also send the Documentation/kernel-parameters.txt
bits.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rufus-azrael at numericable

May 7, 2008, 1:58 PM

Post #15 of 32 (2661 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

Pallipadi, Venkatesh a écrit :
>
>
>
>> -----Original Message-----
>> From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>> Sent: Tuesday, May 06, 2008 2:57 PM
>> To: Pallipadi, Venkatesh
>> Cc: Ingo Molnar; Siddha, Suresh B; Linux-kernel Mailing List
>> Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>> xf86MapVidMem error
>>
>> Pallipadi, Venkatesh a écrit :
>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>>>> Sent: Tuesday, May 06, 2008 10:32 AM
>>>> To: Ingo Molnar
>>>> Cc: Pallipadi, Venkatesh; Siddha, Suresh B; Linux-kernel
>>>>
>> Mailing List
>>
>>>> Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>>>> xf86MapVidMem error
>>>>
>>>> Ingo Molnar a écrit :
>>>>
>>>>
>>>>> * Venki Pallipadi <venkatesh.pallipadi[at]intel.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Below is the patch to enable debug messages by a boot option
>>>>>> "debugpat".
>>>>>>
>>>>>>
>>>>>>
>>>> Hi all,
>>>>
>>>> I have applied the patch from Ingo and I put my
>>>> dmesg/syslog/messages/Xorg.log files in attached to help you
>>>> to identify
>>>> the problem (two mails).
>>>>
>>>> Hope it can help you.
>>>>
>>>>
>>>>
>>> Did you use "debugpat" kernel boot option after applying
>>>
>> Ingo's patch?
>>
>>> With Ingo's patch, that option is needed to print more info
>>>
>> (Not needed with one line change I sent you yday).
>>
>>> Also, 'dmesg -s 256000' will not truncate the msg at 32K and
>>>
>> will give bigger dmesg output.
>>
>>> Thanks,
>>> Venki
>>>
>>>
>>>
>> Hi,
>>
>> Here is my dmesg.log file with CONFIG_X86_PAT=y and debugpat
>> kernel boot
>> option.
>>
>> Is it helpfull ? :-).
>>
>>
>
> Yes. This has some debug information in there. Did you see xf86MapVidMem error (I mean did you try to start X) before you captured this dmesg?
>
> Thanks,
> Venki
>
>
Hi all,

Yes, the error's message is in my Xorg.log file :-)

Regards.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


yhlu.kernel at gmail

May 7, 2008, 2:42 PM

Post #16 of 32 (2673 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

On Sun, May 4, 2008 at 1:24 AM, Rufus & Azrael
<rufus-azrael[at]numericable.fr> wrote:
> When upgrading to 2.6.25-git18 and above kernel this Xorg error occurs :
>
> xf86MapVidMem: Could not mmap framebuffer (0xf0000000,0x8000000) (Invalid
> argument)
>
> The latest working kernel was 25-git17 and perhaps is it related to
> http://lkml.org/lkml/2008/4/28/52
>
> My .config and Xorg-log files are attached.
>
> Best regards.
>
...
> (II) Bus 1 non-prefetchable memory range:
> [0] -1 0 0xfe900000 - 0xfeafffff (0x200000) MX[B]
> (II) Bus 1 prefetchable memory range:
> [0] -1 0 0xf0000000 - 0xf7ffffff (0x8000000) MX[B]
..
> (II) Active PCI resource ranges:
> [0] -1 0 0xfebff000 - 0xfebfffff (0x1000) MX[B]
> [1] -1 0 0xfe8f4000 - 0xfe8f7fff (0x4000) MX[B]
> [2] -1 0 0xfe8ff000 - 0xfe8ff0ff (0x100) MX[B]
> [3] -1 0 0xfe8fa000 - 0xfe8fafff (0x1000) MX[B]
> [4] -1 0 0xfe8fb000 - 0xfe8fbfff (0x1000) MX[B]
> [5] -1 0 0xfe8fc000 - 0xfe8fcfff (0x1000) MX[B]
> [6] -1 0 0xfe8fd000 - 0xfe8fdfff (0x1000) MX[B]
> [7] -1 0 0xfe8fe000 - 0xfe8fefff (0x1000) MX[B]
> [8] -1 0 0xfe8ff800 - 0xfe8ffbff (0x400) MX[B]
> [9] -1 0 0xfe900000 - 0xfe9fffff (0x100000) MX[B](B)
> [10] -1 0 0xfeaf0000 - 0xfeafffff (0x10000) MX[B](B)
> [11] -1 0 0xf0000000 - 0xf7ffffff (0x8000000) MX[B](B)
> [12] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
> [13] -1 0 0x0000ff00 - 0x0000ff0f (0x10) IX[B]
> [14] -1 0 0x000001f0 - 0x000001f0 (0x1) IX[B]
> [15] -1 0 0x000001f0 - 0x000001f7 (0x8) IX[B]
> [16] -1 0 0x000001f0 - 0x000001f0 (0x1) IX[B]
> [17] -1 0 0x000001f0 - 0x000001f7 (0x8) IX[B]
> [18] -1 0 0x00000b00 - 0x00000b0f (0x10) IX[B]
> [19] -1 0 0x00008000 - 0x0000800f (0x10) IX[B]
> [20] -1 0 0x00009000 - 0x00009003 (0x4) IX[B]
> [21] -1 0 0x0000a000 - 0x0000a007 (0x8) IX[B]
> [22] -1 0 0x0000b000 - 0x0000b003 (0x4) IX[B]
> [23] -1 0 0x0000c000 - 0x0000c007 (0x8) IX[B]
> [24] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B](B)

what is your /proc/mtrr?

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


venkatesh.pallipadi at intel

May 7, 2008, 3:12 PM

Post #17 of 32 (2671 views)
Permalink
RE: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

>-----Original Message-----
>From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>Sent: Wednesday, May 07, 2008 1:58 PM
>To: Pallipadi, Venkatesh
>Cc: Ingo Molnar; Siddha, Suresh B; Linux-kernel Mailing List
>Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>xf86MapVidMem error
>
>Pallipadi, Venkatesh a écrit :
>>
>>
>> Yes. This has some debug information in there. Did you see
>xf86MapVidMem error (I mean did you try to start X) before you
>captured this dmesg?
>>
>> Thanks,
>> Venki
>>
>>
>Hi all,
>
>Yes, the error's message is in my Xorg.log file :-)
>

One more piece of data I need. Can you please send the output of `cat /proc/mtrr` from this system (after the X failure has happened)

Thanks,
Venki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rufus-azrael at numericable

May 8, 2008, 12:08 AM

Post #18 of 32 (2665 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

Pallipadi, Venkatesh a écrit :
>
>
>
>> -----Original Message-----
>> From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>> Sent: Wednesday, May 07, 2008 1:58 PM
>> To: Pallipadi, Venkatesh
>> Cc: Ingo Molnar; Siddha, Suresh B; Linux-kernel Mailing List
>> Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>> xf86MapVidMem error
>>
>> Pallipadi, Venkatesh a écrit :
>>
>>>
>>>
>>> Yes. This has some debug information in there. Did you see
>>>
>> xf86MapVidMem error (I mean did you try to start X) before you
>> captured this dmesg?
>>
>>> Thanks,
>>> Venki
>>>
>>>
>>>
>> Hi all,
>>
>> Yes, the error's message is in my Xorg.log file :-)
>>
>>
>
> One more piece of data I need. Can you please send the output of `cat /proc/mtrr` from this system (after the X failure has happened)
>
> Thanks,
> Venki
>
>
Hi Venki,


See my /proc/mtrr file attached.

Regards.
Attachments: mtrr (0.13 KB)


venkatesh.pallipadi at intel

May 8, 2008, 6:18 AM

Post #19 of 32 (2669 views)
Permalink
RE: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

>-----Original Message-----
>From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>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 => 2.6.26-rc1-git1] Xorg crash with
>xf86MapVidMem error
>
>Pallipadi, Venkatesh a écrit :
>>
>>
>>
>>> -----Original Message-----
>>> From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>>> Sent: Wednesday, May 07, 2008 1:58 PM
>>> To: Pallipadi, Venkatesh
>>> Cc: Ingo Molnar; Siddha, Suresh B; Linux-kernel Mailing List
>>> Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with
>>> xf86MapVidMem error
>>>
>>> Pallipadi, Venkatesh a écrit :
>>>
>>>>
>>>>
>>>> Yes. This has some debug information in there. Did you see
>>>>
>>> xf86MapVidMem error (I mean did you try to start X) before you
>>> captured this dmesg?
>>>
>>>> Thanks,
>>>> Venki
>>>>
>>>>
>>>>
>>> Hi all,
>>>
>>> Yes, the error's message is in my Xorg.log file :-)
>>>
>>>
>>
>> One more piece of data I need. Can you please send the
>output of `cat /proc/mtrr` from this system (after the X
>failure has happened)
>>
>> Thanks,
>> Venki
>>
>>
>Hi Venki,
>
>
>See my /proc/mtrr file attached.
>

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 setting "write-combine" mtrr for framebuffer for this 16M. 0xf0000000-0xf1000000
[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 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) (Invalid argument)


Now we need to figure out a clean solution for this problem. I think we don't have to check the full range of address is of same type as long as we are requesting for PAT type UC_MINUS and MTRR has WC sub ranges. But, we need to think about other such conflict conditiond when having multiple users of same range (uvesafb and X) also. Will be back with a patch for you to try and test.

Thanks,
Venki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


venkatesh.pallipadi at intel

May 8, 2008, 12:25 PM

Post #20 of 32 (2665 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

On Thu, May 08, 2008 at 06:18:48AM -0700, Pallipadi, Venkatesh wrote:
>
>
> >-----Original Message-----
> >From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
> >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 => 2.6.26-rc1-git1] Xorg crash with
> >xf86MapVidMem error
> >
> >Pallipadi, Venkatesh a écrit :
> >>
> >> One more piece of data I need. Can you please send the
> >output of `cat /proc/mtrr` from this system (after the X
> >failure has happened)
> >>
> >> Thanks,
> >> Venki
> >>
> >>
> >Hi Venki,
> >
> >
> >See my /proc/mtrr file attached.
> >
>
> 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 setting
> "write-combine" mtrr for framebuffer for this 16M. 0xf0000000-0xf1000000
> [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
> 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) (Invalid
> argument)
>
>
> Now we need to figure out a clean solution for this problem. I think we
> don't have to check the full range of address is of same type as long as we
> are requesting for PAT type UC_MINUS and MTRR has WC sub ranges. But, we
> need to think about other such conflict conditiond when having multiple
> users of same range (uvesafb and X) also. Will be back with a patch for
> you to try and test.
>

Hi,

Can you please check whether the patch below solves this problem. Also, please
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 for any
reason.

Change the logic in mtrr_type_lookup to just get the type from the start
address. Using start and end adddress is not right/complete as start and
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
deterministic.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi[at]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
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/generic.c 2008-05-02 09:45:23.000000000 -0700
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c 2008-05-08 12:22:16.000000000 -0700
@@ -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 range MTRR
* - 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)

prev_match = 0xFF;
for (i = 0; i < num_var_ranges; ++i) {
- unsigned short start_state, end_state;
+ unsigned short start_state;

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);

start_state = ((start & mask) == (base & mask));
- end_state = ((end & mask) == (base & mask));
- if (start_state != end_state)
- return 0xFE;
+ /* Just check the type of start address */

if ((start & mask) != (base & mask)) {
continue;
Index: linux-2.6/arch/x86/mm/pat.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/pat.c 2008-05-07 13:35:56.000000000 -0700
+++ 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 = prot;
return 0;
}
- if (mtrr_type == 0xFE) { /* MTRR match error */
- *ret_prot = _PAGE_CACHE_UC;
- return -1;
- }
if (mtrr_type != MTRR_TYPE_UNCACHABLE &&
mtrr_type != MTRR_TYPE_WRBACK &&
mtrr_type != MTRR_TYPE_WRCOMB) { /* MTRR type unhandled */
@@ -244,9 +240,7 @@ int reserve_memtype(u64 start, u64 end,
* no match.
*/
u8 mtrr_type = mtrr_type_lookup(start, end);
- if (mtrr_type == 0xFE) { /* MTRR match error */
- err = -1;
- }
+ /* MTRR lookup failed - Use UC_MINUS*/

if (mtrr_type == MTRR_TYPE_WRBACK) {
req_type = _PAGE_CACHE_WB;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rufus-azrael at numericable

May 8, 2008, 1:08 PM

Post #21 of 32 (2664 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

Venki Pallipadi a écrit :
> On Thu, May 08, 2008 at 06:18:48AM -0700, Pallipadi, Venkatesh wrote:
>
>>
>>
>>
>>> -----Original Message-----
>>> From: Rufus & Azrael [mailto:rufus-azrael[at]numericable.fr]
>>> 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 => 2.6.26-rc1-git1] Xorg crash with
>>> xf86MapVidMem error
>>>
>>> Pallipadi, Venkatesh a écrit :
>>>
>>>>
>>>> One more piece of data I need. Can you please send the
>>>>
>>> output of `cat /proc/mtrr` from this system (after the X
>>> failure has happened)
>>>
>>>> Thanks,
>>>> Venki
>>>>
>>>>
>>>>
>>> Hi Venki,
>>>
>>>
>>> See my /proc/mtrr file attached.
>>>
>>>
>> 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 setting
>> "write-combine" mtrr for framebuffer for this 16M. 0xf0000000-0xf1000000
>> [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
>> 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) (Invalid
>> argument)
>>
>>
>> Now we need to figure out a clean solution for this problem. I think we
>> don't have to check the full range of address is of same type as long as we
>> are requesting for PAT type UC_MINUS and MTRR has WC sub ranges. But, we
>> need to think about other such conflict conditiond when having multiple
>> users of same range (uvesafb and X) also. Will be back with a patch for
>> you to try and test.
>>
>>
>
> Hi,
>
> Can you please check whether the patch below solves this problem. Also, please
> 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 for any
> reason.
>
> Change the logic in mtrr_type_lookup to just get the type from the start
> address. Using start and end adddress is not right/complete as start and
> 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
> deterministic.
>
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi[at]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
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/generic.c 2008-05-02 09:45:23.000000000 -0700
> +++ linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c 2008-05-08 12:22:16.000000000 -0700
> @@ -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 range MTRR
> * - 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)
>
> prev_match = 0xFF;
> for (i = 0; i < num_var_ranges; ++i) {
> - unsigned short start_state, end_state;
> + unsigned short start_state;
>
> 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);
>
> start_state = ((start & mask) == (base & mask));
> - end_state = ((end & mask) == (base & mask));
> - if (start_state != end_state)
> - return 0xFE;
> + /* Just check the type of start address */
>
> if ((start & mask) != (base & mask)) {
> continue;
> Index: linux-2.6/arch/x86/mm/pat.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/mm/pat.c 2008-05-07 13:35:56.000000000 -0700
> +++ 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 = prot;
> return 0;
> }
> - if (mtrr_type == 0xFE) { /* MTRR match error */
> - *ret_prot = _PAGE_CACHE_UC;
> - return -1;
> - }
> if (mtrr_type != MTRR_TYPE_UNCACHABLE &&
> mtrr_type != MTRR_TYPE_WRBACK &&
> mtrr_type != MTRR_TYPE_WRCOMB) { /* MTRR type unhandled */
> @@ -244,9 +240,7 @@ int reserve_memtype(u64 start, u64 end,
> * no match.
> */
> u8 mtrr_type = mtrr_type_lookup(start, end);
> - if (mtrr_type == 0xFE) { /* MTRR match error */
> - err = -1;
> - }
> + /* MTRR lookup failed - Use UC_MINUS*/
>
> if (mtrr_type == MTRR_TYPE_WRBACK) {
> req_type = _PAGE_CACHE_WB;
>
>
Hi Venki,


Patch applied on 2.6.26-rc1-git5 and all works fine in X server with
CONFIG_X86_PAT=y.

See dmesg and mtrr files attached.

Thanks for all,

Regards.
Attachments: dmesg.log (30.7 KB)
  mtrr (0.13 KB)


venkatesh.pallipadi at intel

May 8, 2008, 2:37 PM

Post #22 of 32 (2669 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

On Thu, May 08, 2008 at 01:08:01PM -0700, Rufus & Azrael wrote:
> Venki Pallipadi a ecrit :
> >
> > Use UC_MINUS in reserve_memtype call with -1, when MTRR lookup fails for
> any
> > reason.
> >
> > Change the logic in mtrr_type_lookup to just get the type from the start
> > address. Using start and end adddress is not right/complete as start and
> > 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
> > deterministic.
> >
> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi[at]intel.com>
> >
> > ---
> > arch/x86/kernel/cpu/mtrr/generic.c | 7 ++-----
> > arch/x86/mm/pat.c | 8 +-------
> > 2 files changed, 3 insertions(+), 12 deletions(-)
> >
>
> Hi Venki,
>
> Patch applied on 2.6.26-rc1-git5 and all works fine in X server with
> CONFIG_X86_PAT=y.
>
> See dmesg and mtrr files attached.
>

Thanks for reporting the problem and testing the fix.
ingo/thomas/hpa: Can you please pick up this patch. Fixes the PAT regression
reported on this thread.

Thanks,
Venki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

May 8, 2008, 2:42 PM

Post #23 of 32 (2678 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

Venki Pallipadi wrote:
> On Thu, May 08, 2008 at 01:08:01PM -0700, Rufus & Azrael wrote:
>> Venki Pallipadi a ecrit :
>> >
>> > Use UC_MINUS in reserve_memtype call with -1, when MTRR lookup fails for
>> any
>> > reason.
>> >
>> > Change the logic in mtrr_type_lookup to just get the type from the start
>> > address. Using start and end adddress is not right/complete as start and
>> > 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
>> > deterministic.
>> >
>> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi[at]intel.com>
>> >
>> > ---
>> > arch/x86/kernel/cpu/mtrr/generic.c | 7 ++-----
>> > arch/x86/mm/pat.c | 8 +-------
>> > 2 files changed, 3 insertions(+), 12 deletions(-)
>> >
>>
>> Hi Venki,
>>
>> Patch applied on 2.6.26-rc1-git5 and all works fine in X server with
>> CONFIG_X86_PAT=y.
>>
>> See dmesg and mtrr files attached.
>>
>
> Thanks for reporting the problem and testing the fix.
> ingo/thomas/hpa: Can you please pick up this patch. Fixes the PAT regression
> reported on this thread.

Hm...

I have *serious* concerns about this; this might paper over this
particular problem, but it just isn't *correct*.

The fact that the range check is implemented incorrectly is not an
excuse to just dump it and ignore the problem; it should be fixed instead.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


venkatesh.pallipadi at intel

May 8, 2008, 4:40 PM

Post #24 of 32 (2661 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

On Thu, May 08, 2008 at 02:59:31PM -0700, Venkatesh Pallipadi wrote:
> On Thu, May 08, 2008 at 02:42:29PM -0700, H. Peter Anvin wrote:
> > Venki Pallipadi wrote:
> > >On Thu, May 08, 2008 at 01:08:01PM -0700, Rufus & Azrael wrote:
> > >> Venki Pallipadi a ecrit :
> > >> >
> > >> > Use UC_MINUS in reserve_memtype call with -1, when MTRR lookup fails
> > >> for
> > >> any
> > >> > reason.
> > >> >
> > >> > Change the logic in mtrr_type_lookup to just get the type from the
> > >> start
> > >> > address. Using start and end adddress is not right/complete as start
> > >> and
> > >> > 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
> > >> > deterministic.
> > >> >
> > >> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi[at]intel.com>
> > >> >
> > >> > ---
> > >> > arch/x86/kernel/cpu/mtrr/generic.c | 7 ++-----
> > >> > arch/x86/mm/pat.c | 8 +-------
> > >> > 2 files changed, 3 insertions(+), 12 deletions(-)
> > >> >
> > >>
> >
> > Hm...
> >
> > I have *serious* concerns about this; this might paper over this
> > particular problem, but it just isn't *correct*.
> >
> > The fact that the range check is implemented incorrectly is not an
> > excuse to just dump it and ignore the problem; it should be fixed instead.
> >
>
> I agree we need a better range check in place. But, the current one was not
> really doing anything useful and actually causing the side-effect
> regression. So, I felt not having it is better solution for now.
>
> Other solution is to stay with start and end range check and just ignore the
> range check error with WC overlap in case where UC_MINUS is requested.
>
> Given the way MTRRs are defined, the only way to do the full range check
> seems to be to go over page by page (from start to end), and check which
> variable range MTTR it matches with, which is obviously very excessive. As,
> this is not a problem in typical usage scenario.
>

Also, note that we only look for start while looking at fixed range MTRRs.
This is not as scary as it seems. We are finding the effective memory type
by just looking at the start of the address range. We still go through
the PAT reserve free mechanism, once we find the effective memory type
and that list will catch any other users with conflicting type anywhere
in the start to end range. And we will still keep effective type consistent
across all mappings.

For example:
0xf0000000-0xf1000000 is mapped WC by one user with appropriate MTRR setting
0xf2000000-0xf3000000 is mapped UC by another user with appropriate MTRR setting

Now if there is a request to map
0xf0000000-0xf4000000, we do mtrr_lookup and assume effective type for the
whole range is WC. Then we go through PAT list to see any conflicts. And
while parsing the list, we will find there is an overlap with conflicting
attributes and we fail the reserve.

In case the second UC mapping above is not present, we use effective memory
type for the whole range 0xf0000000-0xf4000000 as WC and track it in our list
that way.

Thanks,
Venki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


hpa at zytor

May 8, 2008, 4:54 PM

Post #25 of 32 (2676 views)
Permalink
Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error [In reply to]

Venki Pallipadi wrote:
> On Thu, May 08, 2008 at 02:59:31PM -0700, Venkatesh Pallipadi wrote:
>>>
>> I agree we need a better range check in place. But, the current one was not
>> really doing anything useful and actually causing the side-effect
>> regression. So, I felt not having it is better solution for now.
>>
>> Other solution is to stay with start and end range check and just ignore the
>> range check error with WC overlap in case where UC_MINUS is requested.
>>
>> Given the way MTRRs are defined, the only way to do the full range check
>> seems to be to go over page by page (from start to end), and check which
>> variable range MTTR it matches with, which is obviously very excessive. As,
>> this is not a problem in typical usage scenario.
>>

I don't believe that is true in the slightest. You can iterate over the
variable MTRRs and see if any part of them overlaps the target range;
doing exhaustive enumeration is clearly bogus, especially on 64-bit
platforms.

>
> Also, note that we only look for start while looking at fixed range MTRRs.
> This is not as scary as it seems. We are finding the effective memory type
> by just looking at the start of the address range. We still go through
> the PAT reserve free mechanism, once we find the effective memory type
> and that list will catch any other users with conflicting type anywhere
> in the start to end range. And we will still keep effective type consistent
> across all mappings.
>

So what you're saying here is "it's bogus, but it doesn't really matter
anyway?" Why bother having it at all, then?

Seriously, if it's not unconditionally correct, then:

a. it should be *clearly* labelled a heuristic.
b. it should be *clearly* explained why having the heuristic is much
better than not having anything.

In this case, neither of those conditions appear to be addressed.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.