lkml.org 
[lkml]   [2006]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [BUG sparc64] 2.6.16-git6 broke X11 on Ultra5 with ATI Mach64
From
From: Mikael Pettersson <mikpe@it.uu.se>
Date: Thu, 6 Jul 2006 11:37:35 +0200 (MEST)

> On Wed, 05 Jul 2006 20:40:36 -0700 (PDT), David Miller wrote:
> >> I.e., X did a simple PROT_READ|PROT_WRITE MAP_SHARED mmap() of
> >> something PCI-related, presumably the ATI card. The protection
> >> bits passed into io_remap_pfn_range() are 0x80...0788, while
> >> pg_iobits are 0x80...0f8a. Current kernels obey the prot bits,
> >> which, if I read things correctly, means that _PAGE_W_4U and
> >> _PAGE_MODIFIED_4U don't get set any more.
> >>
> >> I guess something else in the kernel should have set those
> >> bits before they got to io_remap_pfn_range()?
> >
> >The problem is with X, it should not be doing a MAP_SHARED
> >mmap() of the framebuffer device. It should be using
> >MAP_PRIVATE instead.
> >
> >The kernel is trying to provide copy-on-write semantics for
> >the mapping, which doesn't make any sense for device registers.
> >That's why the kernel isn't setting the writable or modified
> >bits in the protection bitmask.
>
> Now I'm confused. That COW behaviour would be consistent with
> MAP_PRIVATE, not MAP_SHARED which is what X did use.

Yes, I'm totally wrong here, MAP_SHARED is correct.

I'll have to figure out how the writeable bits get lost
in the call chain.

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

\
 
 \ /
  Last update: 2006-07-07 09:07    [W:0.510 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site