public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jesse.barnes@intel.com>
To: Frans Pop <elendil@planet.nl>
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
	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: Mon, 5 May 2008 08:57:57 -0700	[thread overview]
Message-ID: <200805050857.57661.jesse.barnes@intel.com> (raw)
In-Reply-To: <200805040910.57088.elendil@planet.nl>

On Sunday, May 04, 2008 12:10 am Frans Pop wrote:
> On Friday 02 May 2008, Jesse Barnes wrote:
> > This is just a transient issue during VT switch or server exit though,
> > right? X functionality isn't affected, and your VTs work fine?
>
> Transient only. I've just tested again and this time the band
> was visible on top of the text on VT1 for about 2 seconds. Then it
> disappeared.
> The artifacts also appear when I log out from KDE (i.e. without exiting the
> server), and I also get the messages when logging out and logging in again.
>
> I do not see any performance issues, but I've only used this kernel for a
> very short time.
>
> > 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).
>
> The artifacts may not be a PAT issue directly, but it is a clear regression
> for me as I currently have a nice clean screen when X shuts down. I'm also
> 100% sure that it is caused by enabling PAT. A kernel with same config and
> only PAT disabled does not show the artifacts.
>
> Would you like me to file a bug against X for these artifacts?
> If so, against what component? The i810 driver or the server?

I suspect an i810 driver bug is being uncovered here, since we do have 
transient VT switch corruption on some other platforms (we're just exposing 
our chip reprogramming on the screen, rather than keeping it off the whole 
time).  But there could also be something PAT specific going on, I'll have to 
walk through those code paths...

> Also attached a dmesg that shows the messages. As you can see there are
> some repeats.
> - first 22 "expected mapping type" when X is started
> - second 22 "expected mapping type" when logging in
> - 9 "freeing invalid memtype" when logging out
> - 22 "expected mapping type" when logging in again
> - 9 "freeing invalid memtype" when logging out again
> - last series "expected mapping type" when restarting X server
>
> I must say that I'm fairly disappointed by your (plural) attitude to these
> regressions, especially given that you both seem to feel it is important
> that people will actually use PAT.

Oh the messages should be removed or somehow minimized, I agree.  I'm just not 
sure if the other bug is serious enough to block PAT by default yet, but 
either way we should fix the bugs!

> That said, I'll be happy to help trace and get these issues fixed.

Thanks for your help so far...

Jesse

  parent reply	other threads:[~2008-05-05 15:58 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
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 [this message]
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=200805050857.57661.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