Re: [git head] Should X86_PAT really default to yes?
- From: Jesse Barnes <jesse.barnes@xxxxxxxxx>
- Date: Mon, 5 May 2008 08:57:57 -0700
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
--
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/
- Follow-Ups:
- Re: [git head] Should X86_PAT really default to yes?
- From: Frans Pop
- Re: [git head] Should X86_PAT really default to yes?
- References:
- [git head] Should X86_PAT really default to yes?
- From: Frans Pop
- Re: [git head] Should X86_PAT really default to yes?
- From: Jesse Barnes
- Re: [git head] Should X86_PAT really default to yes?
- From: Frans Pop
- [git head] Should X86_PAT really default to yes?
- Prev by Date: Re: Patches for piping to core pattern ?
- Next by Date: Re: Preempt-RT patch for 2.6.25
- Previous by thread: Re: [git head] Should X86_PAT really default to yes?
- Next by thread: Re: [git head] Should X86_PAT really default to yes?
- Index(es):
Relevant Pages
|