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 /sys/bus/pci/devices/0000:00:0b.0/resource0 which - unfortunately - does not exist on that systems. Instead, I could offer: resource0_dense resource0_sparse resource1_dense resource1_sparse 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 () Environment: X.Org X Server 1.7.99.2 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
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.
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.