Message-Id: <200805040910.57088.elendil@planet.nl>
Date:	Sun, 4 May 2008 09:10:56 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Jesse Barnes <jesse.barnes@...el.com>
Cc:	"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 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.

Cheers,
FJP


Download attachment "PAT.dmesg.gz" of type "application/x-gzip" (8931 bytes)

Download attachment "Xorg.0.log.gz" of type "application/x-gzip" (7345 bytes)

View attachment "config-2.6.26-rc0-pat" of type "text/plain" (59828 bytes)

Powered by blists - more mailing lists