Re: [git head] Should X86_PAT really default to yes?

On Sun, May 4, 2008 at 12:10 AM, Frans Pop <elendil@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Upgrading to SBS2003 - realistic to do ourselves?
    ... Hi Pat... ... the same LAN as your exisitng server though, server name and domain needs to ... Personally I would quote the other way round...clean install takes longer ... >I guess I don't know how geeky I am (I'm an engineer - does that count as ...
    (microsoft.public.backoffice.smallbiz2000)
  • Re: [git head] Should X86_PAT really default to yes?
    ... and I also get the messages when logging out and logging in again. ... The artifacts may not be a PAT issue directly, but it is a clear regression ... Would you like me to file a bug against X for these artifacts? ... first 22 "expected mapping type" when X is started ...
    (Linux-Kernel)
  • Re: Running DCPROMO issues
    ... is the a Global Catalog Server in this Domain? ... sure that all five of the FSMO Roles are held by an existing DC. ... pointing to itself in DNS - in other words, that it points only to DC3). ... "Pat" wrote in message ...
    (microsoft.public.windows.server.active_directory)
  • RE: [git head] Should X86_PAT really default to yes?
    ... Would you like me to file a bug against X for these artifacts? ... When I boot without 'vga=791', I hit another, unrelated ... that is the only other open issue related to PAT at this time. ...
    (Linux-Kernel)
  • Re: WIN 2000 domain trust
    ... Hi Pat, ... only can furnish you with below info as initial troubleshooting. ... Troubleshoot RPC Endpoint Mapper errors in Windows Server ... I try to use NET passport to post an email to> Microsodt tech support, but they want a product ID # of> the form xxxx-xxx... ...
    (microsoft.public.windows.server.active_directory)