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

From: Pallipadi, Venkatesh
Date: Fri May 02 2008 - 17:53:38 EST




>-----Original Message-----
>From: Barnes, Jesse
>Sent: Friday, May 02, 2008 1:40 PM
>To: Pallipadi, Venkatesh
>Cc: Frans Pop; linux-kernel@xxxxxxxxxxxxxxx; Ingo Molnar;
>Packard, Keith
>Subject: Re: [git head] Should X86_PAT really default to yes?
>
>On Friday, May 02, 2008 12:37 pm Pallipadi, Venkatesh wrote:
>> >-----Original Message-----
>> >From: Frans Pop [mailto:elendil@xxxxxxxxx]
>> >Sent: Friday, May 02, 2008 12:22 PM
>> >To: linux-kernel@xxxxxxxxxxxxxxx
>> >Cc: Pallipadi, Venkatesh; Ingo Molnar
>> >Subject: [git head] Should X86_PAT really default to yes?
>> >
>> >With X86_PAT enabled, when X is started I get about 40 lines
>> >(with varying
>> >addresses) like:
>> >kernel: Xorg:3358 /dev/mem expected mapping type write-back for
>> >807bf000-81000000, got uncached-minus
>
>These messages? They're coming from the kernel it looks like,
>from the
>map_devmem routine in pat.c. I'm not sure they're accurate
>though; for PCI
>regions /dev/mem is *supposed* to map with UC- and not WB, so
>maybe this
>function needs to be updated?
>

Indeed.
I think these messages are due to X using the mprotect workaround to
change UC_MINUS to WB.
I don't see these error messages on my 965 here. May be I have different
x version.

What may be happening:
1) process A mmaps /dev/mem and gets UC_MINUS
2) Changes the page table to make pg_prot WB
3) Does a fork to create process B
4) While copying the vma, we go through map_devmem request WB, but get
UC_MINUS back
5) We are not changing vma pg_prot to new value at this point (we should
change this), so one more round of errors will be there when forked
process exits.

Again, this should not have any side-effect like the band etc. It just a
"friendly warning". It should go away when X moves to using WC or does
not use the mprotect workaround to make pg_prot WB.

Thanks,
Venki
--
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/