All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jesse.barnes@intel.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: "Frans Pop" <elendil@planet.nl>,
	linux-kernel@vger.kernel.org, "Ingo Molnar" <mingo@elte.hu>,
	"Packard, Keith" <keith.packard@intel.com>
Subject: Re: [git head] Should X86_PAT really default to yes?
Date: Fri, 2 May 2008 13:40:24 -0700	[thread overview]
Message-ID: <200805021340.24987.jesse.barnes@intel.com> (raw)
In-Reply-To: <924EFEDD5F540B4284297C4DC59F3DEEFB8D3D@orsmsx423.amr.corp.intel.com>

On Friday, May 02, 2008 12:37 pm Pallipadi, Venkatesh wrote:
> >-----Original Message-----
> >From: Frans Pop [mailto:elendil@planet.nl]
> >Sent: Friday, May 02, 2008 12:22 PM
> >To: linux-kernel@vger.kernel.org
> >Cc: Pallipadi, Venkatesh; Ingo Molnar
> >Subject: [git head] Should X86_PAT really default to yes?
> >
> >With X86_PAT enabled, when X is started I get about 40 lines
> >(with varying
> >addresses) like:
> >kernel: Xorg:3358 /dev/mem expected mapping type write-back for
> >807bf000-81000000, got uncached-minus

These messages?  They're coming from the kernel it looks like, from the 
map_devmem routine in pat.c.  I'm not sure they're accurate though; for PCI 
regions /dev/mem is *supposed* to map with UC- and not WB, so maybe this 
function needs to be updated?

> >And when X exits I get a bunch of lines like:
> >kernel: Xorg:3349 freeing invalid memtype 80020000-8002a000
> >
> >I also noticed artifacts (a band of about 2 cm high across the
> >screen) after
> >X goes to black but before the switch to VT1.

This is just a transient issue during VT switch or server exit though, right?  
X functionality isn't affected, and your VTs work fine?  If so, it might not 
be a PAT issue but just a different memory layout or something (and therefore 
it would really just be a cosmetic bug in the X driver).

I really think PAT should be on by default; if you're running into real 
functional or performance problems we'd better get them fixed rather than 
disabling PAT...

Thanks,
Jesse


  reply	other threads:[~2008-05-02 20:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 19:22 [git head] Should X86_PAT really default to yes? Frans Pop
2008-05-02 19:37 ` Pallipadi, Venkatesh
2008-05-02 20:40   ` Jesse Barnes [this message]
2008-05-02 21:55     ` Pallipadi, Venkatesh
2008-05-02 22:07       ` Jesse Barnes
2008-05-04  7:10     ` Frans Pop
2008-05-04  9:04       ` Ingo Molnar
2008-05-04 20:23       ` Yinghai Lu
2008-05-05 16:55         ` Frans Pop
2008-05-05 17:00           ` Pallipadi, Venkatesh
2008-05-05 17:42             ` Yinghai Lu
2008-05-05 18:56             ` Frans Pop
2008-05-05 15:57       ` Jesse Barnes
2008-05-05 17:32         ` Frans Pop
2008-05-05 17:45           ` Jesse Barnes
2008-05-05 17:59             ` Pallipadi, Venkatesh
2008-05-05 18:59             ` Frans Pop
2008-05-05 19:04               ` fb layer & ioremap_wc Jesse Barnes
2008-05-05 19:30                 ` Frans Pop
2008-06-13 16:42                 ` Frans Pop
2008-06-13 16:42                   ` Frans Pop
2008-05-06 22:42           ` [git head] Should X86_PAT really default to yes? Venki Pallipadi
2008-05-07  7:02             ` [git head] X86_PAT & mprotect Ingo Molnar
2008-05-07 19:18               ` Hugh Dickins
2008-05-07 23:23                 ` Venki Pallipadi
2008-05-09 10:08                   ` Ingo Molnar
2008-05-09 20:05                     ` Venki Pallipadi
2008-05-09 20:09                       ` Venki Pallipadi
2008-05-09 20:48                         ` Hugh Dickins
2008-05-09 22:11                       ` Dave Airlie
2008-05-09 22:20                         ` Pallipadi, Venkatesh
2008-05-10  6:19                           ` Dave Airlie
2008-05-10  6:29                             ` Keith Packard
2008-05-10  5:45                         ` Keith Packard
2008-05-07 22:36               ` Venki Pallipadi
2008-05-25 15:08             ` [git head] Should X86_PAT really default to yes? Frans Pop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200805021340.24987.jesse.barnes@intel.com \
    --to=jesse.barnes@intel.com \
    --cc=elendil@planet.nl \
    --cc=keith.packard@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.