Message-ID: <86802c440805041323s1484a8ecx5dbe639d658d015b@mail.gmail.com>
Date:	Sun, 4 May 2008 13:23:17 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Frans Pop" <elendil@...net.nl>
Cc:	"Jesse Barnes" <jesse.barnes@...el.com>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>,
	"Packard, Keith" <keith.packard@...el.com>
Subject: Re: [git head] Should X86_PAT really default to yes?

On Sun, May 4, 2008 at 12:10 AM, Frans Pop <elendil@...net.nl> 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?
>
>
>  On Saturday 03 May 2008, Jesse Barnes wrote:
>  > > I don't see these error messages on my 965 here. May be I have different
>  > > x version.
>
>  > Hm, yeah that could be.  strace would tell us.
>
>  Would you like me to do an strace?
>
>  Attached my Xorg log for basic info (versions are current Debian unstable)
>  and the config I used.
>
>  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
>
>
>
>  On Saturday 03 May 2008, Jesse Barnes wrote:
>  > More recent versions of X will use sysfs rather than /dev/mem (though
>  > we're still using the mprotect hack there to give us UC-), so yeah this
>  > warning should already be gone in more recent builds.
>
>  On Friday 02 May 2008, Pallipadi, Venkatesh wrote:
>  > ... and should not cause any side-effects other than little annoyance.
>
>
>  On Friday 02 May 2008, Jesse Barnes wrote:
>  > 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...
>
>  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.
>
>  I would say that 40+ messages each time I start X is more than "a little
>  annoyance", especially if you run logcheck (as I do).
>
>  I also think you both seriously underestimate how it will impact enabling
>  PAT, especially by distributions. Although the errors and the artifacts may
>  be minor from a technical point of view, they are the sort of issues that
>  users file bug reports about. Loads of them!
>  So I expect distros will be extremely reluctant to enable PAT when they know
>  they can expect this. The fact that the messages will go away at some point
>  in the future is absolutely not relevant.
>
>  Add to that the current warning in the Kconfig help:
>    Say N here if you see bootup problems (boot crash, boot hang,
>    spontaneous reboots) or a non-working video driver.
>
>  Do you really think that distros can afford the risk of such issues in their
>  generic kernel images even if it would only affect a small minority of
>  their user base? If this warning is realistic then IMHO X86_PAT should
>  default to N and be marked "experimental".
>
>  You can be sure that I at least will not be enabling X86_PAT in the near
>  future because of these two issues. And given the nature of this option I'm
>  quite likely to completely forget about it afterwards...
>
>
>  That said, I'll be happy to help trace and get these issues fixed.

can you boot with pat=off and send out /proc/mtrr?

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

Powered by blists - more mailing lists