On 08/09/2016 01:44 AM, Michael Ellerman wrote:
"Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes:
On 08/08/2016 09:32 PM, Michael Ellerman wrote:
"Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes:
(i) What is the specific issue? Do you have some logs or at least a
"high-level" description of the problem in Xorg? I took a look in its
code and PCI domain is coded as u16, which is correct/expected. So it
seems a subtle bug we should investigate and hopefully fix.
It was reported here:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-August/147062.html
It seems xorg just has a hard coded limit of 256 domains.
Thanks for the link Michael. I guess Xorg _had_ this limit in the
"past", since the function that was logged on error - xf86MapLegacyIO()
- was removed by a commit of 2014:
https://lists.x.org/archives/xorg-devel/2014-July/043224.html
Aha, nice work.
In fact it seems to be better than that, the array of domains was
removed in 2011 in:
https://cgit.freedesktop.org/xorg/xserver/commit/?id=858fbbb40d7c69540cd1fb5315cebf811c6e7b3f
Which is officially ancient history as far as I'm concerned.
Heheh great, good finding Michael!
(ii) Why is it related to the absence of pseries check?! You said this
was your bad, but as far as I understand, Xorg runs in pSeries too so
the issue should also be there heheh
Well yes I guess it would, if anyone had tested Xorg on pseries :)
We use to test Xorg on pSeries regularly; in fact, I made a quick test
today:
http://imgur.com/a/l1lP8
I forced the domain to be 0xffff as in the above image, and everything
worked fine.
Awesome.
I think for now I'm going to apply this, and we'll work out something
else later.
OK, I guess your solution is fine and solves the pasemi issue quickly,
No given the above info on xorg I'll drop this, and merge just the
endian fix.
Perfect, thanks!
cheers
