Date: Thu, 16 Apr 2009 12:34:01 -0400 From: John Nielsen <lists@jnielsen.net> To: freebsd-x11@freebsd.org Subject: Re: r128 dual-head error Message-ID: <200904161234.02099.lists@jnielsen.net> In-Reply-To: <200904151529.06871.lists@jnielsen.net> References: <200904131902.22584.lists@jnielsen.net> <1239821670.2194.10.camel@balrog.2hip.net> <200904151529.06871.lists@jnielsen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 15 April 2009 03:29:06 pm John Nielsen wrote: > On Wednesday 15 April 2009, Robert Noland wrote: > > On Tue, 2009-04-14 at 22:12 -0400, John Nielsen wrote: > > > On Monday 13 April 2009, Warren Block wrote: > > > > On Mon, 13 Apr 2009, John Nielsen wrote: > > > > > From what I can tell I have my xorg.conf configured properly > > > > > and it's trying to do the right thing but it's throwing an > > > > > error when initializing the secondary screen: > > > > > > > > > > (EE) R128(1): Unable to map MMIO aperture. Invalid argument > > > > > (22) > > > I did some poor man's debugging of the original issue (by adding > > > some log print statements to the code). The function which is > > > throwing the "invalid argument" error is pci_device_map_range, > > > called from R128MapMMIO. With my > > > > This is in libpciaccess. 22 is EINVAL, the call may be failing on > > mtrr or just the attempt to remap the same register space a second > > time. The problem is either in libpciaccess or the r128 driver. > > Thanks. FWIW I did confirm that the space is un-mapped between the two > calls. I'll see if I can grok libpciaccess. So the above isn't 100% true. The sequence is: r128(0): map r128(0): unmap r128(1): map r128(1): unmap r128(0): map r128(1): map (fails) My previous (and false) assumption was that the two screens were trying to map _different_ regions for the MMIO. Since they share the same one, the sanity check in libpciaccess to make sure the same memory isn't mapped more than once fails and returns EINVAL. It looks like the previous regime (before libpciaccess) didn't have this sanity check. Removing the sanity check from libpciaccess allows the second screen to come up and it works fine, but that's more of a hack than a fix. The correct behavior would be to copy the MMIO pointer from the primary screen into the secondary screen's "info" structure rather than calling pci_device_map_range the final time. I'll see how long my ambition lasts and file a bug report (with Xorg) with whatever I end up with. Thanks, JN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904161234.02099.lists>