Bug 25678 - Mapping video mem on Alpha ev45 (non-BWX) fails
Summary: Mapping video mem on Alpha ev45 (non-BWX) fails
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/pciaccess (show other bugs)
Version: git
Hardware: Alpha Linux (All)
: medium normal
Assignee: Michael Cree
QA Contact: Xorg Project Team
Whiteboard: 2011BRB_Reviewed
Depends on:
Reported: 2009-12-16 11:47 UTC by Bertram Fey
Modified: 2018-06-12 19:08 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Kernel .config (27.22 KB, application/octet-stream)
2009-12-16 11:47 UTC, Bertram Fey
no flags Details
dmesg output (11.17 KB, application/octet-stream)
2009-12-16 11:47 UTC, Bertram Fey
no flags Details
X core file (after changing to resource?_sparse) (180.04 KB, application/x-gzip)
2009-12-16 11:48 UTC, Bertram Fey
no flags Details
Output of X -verbose 255 (9.53 KB, application/octet-stream)
2009-12-16 11:49 UTC, Bertram Fey
no flags Details
active X config file. (3.64 KB, application/octet-stream)
2009-12-16 11:49 UTC, Bertram Fey
no flags Details
Patch: modify libpciaccess to work on non-BWX alphas (2.81 KB, patch)
2010-02-05 17:18 UTC, Michael Cree
no flags Details | Splinter Review
strace after patch (120.45 KB, application/x-bzip2)
2010-02-05 18:48 UTC, Brian E
no flags Details
Log that goes trace attempt above (10.24 KB, application/octet-stream)
2010-02-05 18:51 UTC, Brian E
no flags Details
lspci -vv (4.91 KB, text/plain)
2010-02-05 20:25 UTC, Brian E
no flags Details
Patch: second take at allocating sparse memory maps (3.59 KB, patch)
2010-02-06 15:56 UTC, Michael Cree
no flags Details | Splinter Review
strace after patch #2 (121.70 KB, application/x-bzip2)
2010-02-07 12:37 UTC, Brian E
no flags Details
Log that goes trace attempt above (18.74 KB, text/plain)
2010-02-07 12:38 UTC, Brian E
no flags Details

Description Bertram Fey 2009-12-16 11:47:24 UTC
Created attachment 32126 [details]
Kernel .config

The system is an AlphaStation 255/300 (ev45, non-bwx), Linux 2.6.30 (Gentoo), 768MB RAM, Matrox Millenium.

X startup fails with "Unable to map BAR 0. No such file or directory (2)".

Tracing it down a bit it shows that libpciaccess tries to access 


which - unfortunately - does not exist on that systems. Instead, I could offer:


If I change the code in such a way that the libpciaccess uses the *_sparse files instead, then I get a seg fault with the following stack trace:

#0  0x000002000043b108 in raise () from /lib/libc.so.6.1
#1  0x000002000043ca00 in abort () from /lib/libc.so.6.1
#2  0x000000012008905c in ddxGiveUp ()
#3  0x0000000120089140 in AbortDDX ()
#4  0x0000000120080c7c in ?? ()
#5  0x000000012008139c in FatalError ()
#6  0x00000001200797ec in ?? ()
#7  0x000002000013b170 in __syscall_rt_sigreturn () from /lib/libpthread.so.0
#8  0x000000012016cd20 in ?? ()
#9  0x0000020000627c6c in MGA3026Save (pScrn=0x1202837e0, vgaReg=0x120285bd8, mgaReg=0x120283fe8, saveFonts=1) at mga_dac3026.c:823
#10 0x0000020000639024 in MGASave (pScrn=0x1202837e0) at mga_driver.c:2951
#11 0x00000200006351ec in MGAdoDDC (pScrn=0x1202837e0) at mga_driver.c:1261
#12 0x00000200006377e8 in MGAPreInit (pScrn=0x1202837e0, flags=0) at mga_driver.c:2255
#13 0x000000012008a26c in InitOutput ()
#14 0x00000001200247f0 in ?? ()
#15 0x0000020000422130 in __libc_start_main () from /lib/libc.so.6.1
#16 0x00000001200243f8 in _start ()


X.Org X Server
Release Date: (unreleased)
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.30-gentoo-r8noy alpha 
Current Operating System: Linux alphabox 2.6.30-gentoo-r8noy #4 Tue Dec 15 19:41:37 CET 2009 alpha
Kernel command line: ro root=/dev/sda1
Build Date: 13 December 2009  08:52:33PM

xf86-video-mga is 1.4.11
Comment 1 Bertram Fey 2009-12-16 11:47:52 UTC
Created attachment 32127 [details]
dmesg output
Comment 2 Bertram Fey 2009-12-16 11:48:25 UTC
Created attachment 32128 [details]
X core file (after changing to resource?_sparse)
Comment 3 Bertram Fey 2009-12-16 11:49:10 UTC
Created attachment 32129 [details]
Output of X -verbose 255

Notice that lines starting with "XX" are debug messages introduced by myself.
Comment 4 Bertram Fey 2009-12-16 11:49:31 UTC
Created attachment 32130 [details]
active X config file.
Comment 5 Brian E 2010-01-13 18:41:29 UTC
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

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.
Comment 6 Michael Cree 2010-02-02 11:57:31 UTC
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.
Comment 7 Bertram Fey 2010-02-04 09:55:11 UTC
Ok, well. Is there any documentation available on this? So I could possibly try myself...
Comment 8 Michael Cree 2010-02-04 15:22:39 UTC
The discussion about implementing resource files under sysfs for the Alpha port is helpful. See:


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.

Comment 9 Michael Cree 2010-02-05 17:18:05 UTC
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.
Comment 10 Michael Cree 2010-02-05 17:28:40 UTC
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.
Comment 11 Brian E 2010-02-05 18:48:43 UTC
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.
Comment 12 Brian E 2010-02-05 18:51:17 UTC
Created attachment 33101 [details]
Log that goes trace attempt above
Comment 13 Michael Cree 2010-02-05 19:44:54 UTC
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!
Comment 14 Brian E 2010-02-05 20:25:55 UTC
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
Comment 15 Michael Cree 2010-02-06 15:46:50 UTC
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.
Comment 16 Michael Cree 2010-02-06 15:56:02 UTC
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.
Comment 17 Brian E 2010-02-07 12:37:32 UTC
Created attachment 33140 [details]
strace after patch #2

No real change in my eyes between patch1 and patch2

strace attached log to follow
Comment 18 Brian E 2010-02-07 12:38:05 UTC
Created attachment 33141 [details]
Log that goes trace attempt above
Comment 19 Michael Cree 2010-02-07 14:37:38 UTC
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.
Comment 20 Matt Turner 2010-02-09 15:08:44 UTC
Brian, can you try your Radeon with kernel mode setting?
Comment 21 Jeremy Huddleston Sequoia 2011-10-16 16:37:54 UTC
Ping.  Any update here?
Comment 22 Bertram Fey 2012-01-09 23:23:30 UTC
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.
Comment 23 Adam Jackson 2018-06-12 19:08:18 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.