https://bugzilla.novell.com/show_bug.cgi?id=202133
------- Comment #40 from mhopf@novell.com 2006-10-24 06:33 MST -------
PPC64 seems to be a well known issue, so unless this is a *major* use case, I
won't continue to do research here. The 32bit ppc issue is still a regression,
and should be solvable.
Xorg mailing list:
From: Ian Romanick
What is the status of fixing X PCI layer nowadays ? Some folks here got some brand new shinny Power5+ workstations (damn, those things are faaaaast....). We've tried putting Matrox G400 or old Radeon 7000 PCI in there, and while the various fbdev's work fine, X doesn't.
What seems to be happening is that basically, X crops the top 32 bits of all PCI resources :) It then tries to access those bogus addresses via /dev/mem, which is no good, and instead craps over system memory.
That and not having domain support are the core problems on PPC64. The first problem is somewhat specific to IBM hardware. Apple's PPC64 firmware puts domain 0 devices below the 32-bit boundary.
Thus I'm wondering what is the status with reworking X PCI code to, among others, properly mmap /proc or /sys instead of /dev/mem, stop assuming PCI resources are 32 bits on 32 bits machines (which is broken on various other type of chips anyway, for example, some 44x embedded powerpc's have a 36 bits physical address space and typically devices sit above 4G), etc...
libpciaccess currently only supports the sysfs method. We still need to determine which Linux kernels we care about so that other interfaces can be supported. Of course, there's also the need to support non-Linux systems. All PCI address are treated as 64-bits. [...] My intention is to bring them up to date and merge them to HEAD once 7.2 ships. That's when the real fun should begin. :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.