Description of problem: DRI/drm doesn't work with mach64 because of some odd version checking in atidrv.c. I get this error in xorg.conf: (EE) ATI(0): [dri] ATIDRIScreenInit failed because of a version mismatch. [dri] mach64.o kernel module version is 2.0.1, but version 1.0 or greater is nee ded. [dri] Disabling DRI. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.6.3-2.fc7 How reproducible: With a Mach64 video card... Steps to Reproduce: 1. Install drm.ko and mach64.ko from http://dri.freedesktop.org/wiki/Download 2. Restart the X Server 3. drm doesn't work because of error above Additional info: I've made a patch that corrects the problem... please check if this is OK and send upstream!
Created attachment 156147 [details] fixes some weird version checking to make drm work with Mach64
Created attachment 156148 [details] SRPM with fix
Created attachment 156150 [details] RPM with fix, for those who want the fix right away..
Oops, the error should be: (EE) ATI(0): [dri] ATIDRIScreenInit failed because of a version mismatch. [dri] mach64.o kernel module version is 2.0.0, but version 1.0 or greater is nee ded. [dri] Disabling DRI. "2.0.1" just got there because of my experiments...
Does that fix actually make DRI work? Usually major number changes require that all drivers be updated to deal with them.
Yes, it works as it should if it goes passed this check... ! I'm not sure what is the purpose of the check, though. It is useful to check for version > 1.0? Or should it check for the correct version of the DRM module it needs, i.e.: 2.0 in this case, and should be bumped to whatever version in the future..??
I have this problem, which may be blocking install of a "mission critical" application that loads a GUI license accpetance screen when you install. The app is written in ITTVIS IDL, and attempting to run IDL in F7 on this machine just results in all memory being allocated. The hardware is Dell PowerEdge 600sc with ATI onboard. The software worked with FC5, and runs on FC7 at other sites. I tried the patch with xorg-x11-drv-ati-6.6.3-4.fc7.src.rpm, but dmesg says: [drm] Initialized drm 1.1.0 20060810 [drm] Initialized mach64 2.0.0 20060718 on minor 0 [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held, held 0 owner 00000000 e7fde600 [drm:drm_unlock] *ERROR* Process 21778 using kernel context 0 [drm] Module unloaded [drm] Initialized mach64 2.0.0 20060718 on minor 0 [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held, held 0 owner 00000000 ea230180 [drm:drm_unlock] *ERROR* Process 14285 using kernel context 0 [drm:mach64_do_dma_init] *ERROR* can not find ring map! This leads me to to conclude that the version check is correct, and more serious changes are needed.
Hum, interesting... I get this on Fedora 7 on my Sony VAIO PCG-FX215: [drm] Initialized drm 1.1.0 20060810 PCI: Unable to reserve mem region #1:1000000@e9000000 for device 0000:01:00.0 ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5 [drm] Initialized mach64 2.0.0 20060718 on minor 0 [drm] Used old pci detect: framebuffer loaded agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode [drm] descriptor ring: cpu addr e1040000, bus addr: 0xf0000000 [drm] DMA test succeeded, using asynchronous DMA mode and everything works fine on kernel 2.6.21-1.3194... this looks like a problem with the kernel module, not the the xorg driver... do you still get the same error message when you disable DRI by adding this to xorg.conf: Section "Extensions" Option "XFree86-DRI" "disable" EndSection and loading mach64.ko manually /sbin/modprobe mach64.ko ?
Loading mach64.ko manually does not give the errors: $ sudo modprobe -v mach64 insmod /lib/modules/2.6.21-1.3228.fc7/kernel/drivers/char/drm/drm.ko insmod /lib/modules/2.6.21-1.3228.fc7/kernel/drivers/char/drm/mach64.ko [note different kernel version, also, I don't think this system does AGP V2] Xorg.log has: (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP) $ dmesg |egrep -i 'drm|mach64|agp' Linux agpgart interface v0.102 (c) Dave Jones [drm] Initialized drm 1.1.0 20060810 [drm] Initialized mach64 2.0.0 20060718 on minor 0 So the module loads fine (with the lax version checking) if you aren't actually trying to use it. Checking around, this graphics hardware is shared with newer Dell servers, e.g., PE750.
Well, I'm not an expert in that thing, but let's see what's different between our system, maybe it can help somebody else figure this one out... the (II) RADEON line is not for us, it only says this driver can do RADEON, but Mach64 is not it. I have this line lower: (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 detected. (II) ATI: Shared PCI/AGP Mach64 in slot 1:0:0 assigned to active "Device" secti on "Videocard0". Also, what does lspci say? I get this: $ /sbin/lspci | grep ATI 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)
lspci -c gives: 00:08.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) (prog-if 00 [VGA]) Subsystem: Dell PowerEdge 600SC Flags: bus master, VGA palette snoop, stepping, medium devsel, latency 32 Memory at fd000000 (32-bit, non-prefetchable) [size=16M] I/O ports at e800 [size=256] Memory at fe120000 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 40000000 [disabled] [size=128K] Capabilities: [5c] Power Management version 2 no mention of AGP.
The symptoms and workaround for my ATI mach64 system are the same as described in <http://ittvis.com/services/techtip.asp?ttid=4228>, which specifically fingers nvidia. The workaround is to a the following four lines to /etc/X11/xorg.conf: Section "ServerFlags" Option "RandR" "false" Option "Xinerama" "false" EndSection
Guys, this is cool conversation, but we can get some information as well, please? Reporter, could you please attach to this bug /etc/X11/xorg.conf and /var/log/Xorg.0.log as two separate uncompressed attachments, please? Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. Also, could you reproduce this bug using only xorg open source packages? We don't support binary only nVidia drivers for obvious reasons.
Created attachment 193991 [details] my xorg.conf file
Created attachment 194001 [details] Xorg.0.log file with xorg.conf file
Created attachment 194071 [details] Xorg.0.log file WITHOUT xorg.conf file
OK I've uploaded the three requested files... I got these results using this driver: xorg-x11-drv-ati-6.6.3-4.fc7 Let me know if you need any other info..
(In reply to comment #13) > Also, could you reproduce this bug using only xorg open source packages? We > don't support binary only nVidia drivers for obvious reasons. Just to be clear, this bug is for the xorg open source mach64 driver. The mention of nVidia was because the workaround was posted when nVidia users encountered problems running IDL on F7.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.