public inbox for linux-kernel@vger.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: 34+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox