Bug 25678

Created attachment 32127 [details]
dmesg output

Created attachment 32128 [details]
X core file (after changing to resource?_sparse)

Created attachment 32129 [details]
Output of X -verbose 255

Notice that lines starting with "XX" are debug messages introduced by myself.

Created attachment 32130 [details]
active X config file.

I have a similar config with the same problem.

radeon driver on an Alpha EV5

strace shows that it is trying to access /sys/bus/pci/devices/0000:00:0c.0/resource2

The following exist in /sys/bus/pci/devices/0000:00:0c.0
resource0_dense
resource0_sparse
resource1_sparse
resource2_dense
resource2_sparse

X startup fails with "Unable to map MMIO aperture. No such file or directory (2)".
The radeon source points to pci_device_map_range as what sources this driver error.

I suspect that this is because sparse PCI access has not been implemented in libpciaccess.  It is needed for non-BWX Alphas.

I quote from the commit message (10a0ef39fbd1d484c2bbc1ffd83d57ecef209140) that added resource files to the Alpha port of the Linux kernel:

    With the "standard" resourceN files on ev56/ev6 libpciaccess
    works "out of the box". Handling of resourceN_sparse/resourceN_dense
    files on older machines obviously requires some userland work.

Bertram:  Your attempt to change libpciaccess to use the *_sparse resource files won't work.  I think each sequential byte on the PCI bus is mapped something like 64 bytes (I forget the exact figure) apart in the sparse files.

I only have BWX enable Alphas so can't test this and also have low motivation to implement it since there are other things on Alpha that need attention and those take up my precious spare time.

Ok, well. Is there any documentation available on this? So I could possibly try myself...

The discussion about implementing resource files under sysfs for the Alpha port is helpful. See:

http://bugzilla.kernel.org/show_bug.cgi?id=10893

There was quite a bit of code in the Xserver to support Alpha sparse PCI memory mapping but it wasn't shifted to libpciaccess and largely has been removed.  That code should be studied.  Best thing is to clone the Xserver git repository and check out the 1.4 version of the Xserver.  The old code can be studied there.

What needs to be done is that the resourceX_dense files should be memory mapped and the resourceX_sparse file should also be memory mapped if it is an I/O bar.  The dense resource files are a 1:1 mapping of memory but only long and quadword accesses are permitted.  This is okay for memory mapping - the compiler can take care of byte and word accesses.  But for an I/O map any byte or word accesses _must_ use the sparse mapping.  The video drivers use the MMIO_INx and the MMIO_OUTx routines defined in the Xserver's compiler.h. Somehow we need to get some communication between pci_device_map_range() in libpciaccess with the MMIO_INx and MMIO_OUTx routines in compiler.h so that sparse access routines are used on non-BWX Alphas.  I'm not sure the best way to achieve that.

I think we should take the discussion to the xorg-devel list so that we can get input from those who might not be reading this bug message.

Cheers
Michael.

Created attachment 33098 [details] [review]
Patch: modify libpciaccess to work on non-BWX alphas

Bertram: Try the attached for patching libpciaccess.  It appears the sparse IO mapping access is still in the Xserver and looking at your Xorg log I see that the sparse MMIO read/write routines have been switched in (the mapVidMemSparse line is the evidence).  I have modified libpciaccess to map resourceX_dense if resourceX is not available and to also map resourceX_sparse if it is an IO mapping.  That I don't return the address of the sparse mapping doesn't matter - it is calculated from the dense mapping address in the sparse MMIO routines in the X server.  This is only compile tested - I don't have non BWX Alpha.

Bother - spotted a typo in patch.  One should replace  map->size**(1<<5) with  map->size*(1<<5) in pci_device_generic_unmap_range(), but it won't matter too much for testing purposes; it just means the memory map won't be freed when it should be.

Created attachment 33100 [details]
strace after patch

Patch gets further into init process, but no avail.

Attached is an strace using a Radeon 9200 card on an EV5 with libpciaccess-0.11.0 + above patch.

Created attachment 33101 [details]
Log that goes trace attempt above

Brian: It crashed in RADEONINPLL() which does a byte access via the MMIO routines; for this a sparse mapping is required.  But your strace log reveals that the sparse map was never made.  It would appear my logic for determining when the sparse mapping is required is not up to the game.  Could I get you to post the output of running lspci -vv for the Radeon PCI card?  Thanks!

Created attachment 33124 [details]
lspci -vv

Here is the lspci -vv as requested.

This machines does not have too many PCI devices, so it is unedited

Thanks, Brian.  It is as I thought.  Resource 2 is marked by the PCI subsystem as memory but the way the Radeon video driver uses it shows that it contains IO ports of byte width.  A sparse memory map is therefore needed.  I will shortly attach a new patch that allocates the sparse memory map also for memory resources of size 128kbytes or less.  I don't know if that is a good choice but resource 2 on your Radeon card is 64kbyte so it should get the required sparse map and we can see if that gets the Xserver up and going.

Created attachment 33133 [details] [review]
Patch: second take at allocating sparse memory maps

New patch for allocating dense/sparse memory maps. Give this one a twirl.

Created attachment 33140 [details]
strace after patch #2

No real change in my eyes between patch1 and patch2

strace attached log to follow

Created attachment 33141 [details]
Log that goes trace attempt above

OK, the relevant info from the strace log is:

open("/sys/bus/pci/devices/0000:00:0c.0/resource2", O_RDWR) = -1 ENOENT (No such file or directory)
open("/sys/bus/pci/devices/0000:00:0c.0/resource2_dense", O_RDWR) = 8
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0) = 0x20000034000
close(8)                                = 0
open("/sys/bus/pci/devices/0000:00:0c.0/resource2_sparse", O_RDWR) = 8
mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0) = 0x20000c5a000

That tells us that the sparse map is happening now, but it is at a location different to what the old Xserver MMIO code expects.  When the RADEONINPLL subroutine attempts to do a byte IO access it is expecting the memory map to be somewhere else and so fails.

Bother!!!  This is bad news - the quick fix I have provided is not going to work.  I am not sure, at the moment, how this can be fixed without a change to the libpciaccess API or making quite serious changes to the Xserver MMIO access routines and every video card driver.  I am told that there is a plan afoot to do some serious work in this regard but it is scheduled for Xserver version 1.9, thus you could have a six month wait before anything that is near working.

Sorry, but it seems getting a working X server for non-BWX Alphas is not going to be trivial -- I am going to have to put some thought into this.  This might make take a bit of time.

Brian, can you try your Radeon with kernel mode setting?

Ping.  Any update here?

If I got all of this right, then implementing this for my gfx card should be possible with reasonable effort. The card (Matrox MGA) only declares memory regions. I should be able to map the dense resources and the compiler should do the rest.

Maybe I can try this as soon as the box has compiled these tons of code.

Cards that also use io regions will be somewhat more problematic.

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.