Bugzilla – Bug 229278
radeon/IA64: No 3D although DRM is working fine
Last modified: 2008-10-23 04:13:45 UTC
drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 11, (OK) drmOpenByBusid: Searching for BusID pci:0001:00:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 11, (OK) drmOpenByBusid: drmOpenMinor returns 11 drmOpenByBusid: drmGetBusid reports pci:0000:00:00.0 [...] (EE) AIGLX error: drmOpen failed (Operation not permitted)
Created attachment 110064 [details] Xorg.0.log
Created attachment 110065 [details] xorg.conf
> (EE) AIGLX error: drmOpen failed (Operation not permitted) AIGLX does not work on openSUSE 10.2 at all. Even not on i386. DRI seems to work. (II) RADEON(0): Direct rendering enabled Could you verify this with glxinfo? Check for the "direct rendering line".
OpenGL renderer string: Mesa GLX Indirect
Please attach output of "LIBGL_DEBUG=1 glxinfo" including (stdout + stderr).
Created attachment 110071 [details] LIBGL_DEBUG=1 glxinfo That looks suspicious: libGL error: dlopen /usr/lib/dri/updates/radeon_dri.so failed (/usr/lib/dri/updates/radeon_dri.so: cannot open shared object file: No such file or directory)
Btw., /usr/lib/dri/updates/README.updates still talks about /usr/X11R6/.
(In reply to comment #6) > That looks suspicious: > libGL error: dlopen /usr/lib/dri/updates/radeon_dri.so failed > (/usr/lib/dri/updates/radeon_dri.so: cannot open shared object file: No such > file or directory) Should be ok. /usr/lib/dri/updates/radeon_dri.so is prefered over /usr/lib/dri/radeon_dri.so. Could you verify with strace that usr/lib/dri/radeon_dri.so is loaded? (In reply to comment #7) > Btw., /usr/lib/dri/updates/README.updates still talks about /usr/X11R6/. Ouch. Need to fix this.
stat("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 stat("/dev/dri/card0", {st_mode=S_IFCHR|0666, st_rdev=makedev(226, 0), ...}) = 0 open("/dev/dri/card0", O_RDWR) = 4 ioctl(4, DECODER_SET_PICTURE, 0x607ffffffff35840) = -1 EACCES (Permission denied ) ioctl(4, DECODER_GET_CAPABILITIES, 0x607ffffffff35840) = 0 ioctl(4, DECODER_GET_CAPABILITIES, 0x607ffffffff35840) = 0 close(4) = 0
The ioctl also fails on a system where 3D works, so this is not the problem. Most likely the real problem is a PCI domain mismatch in the X server. readv(3, [{"pci:0001:00:00.0", 16}, {"", 0}], 2) = 16 ^^^^ should be 0000
*** This bug has been marked as a duplicate of bug 197190 ***
I would not consider this a duplicate...
Ok.
Created attachment 110292 [details] bug-197190_p_pci-off-by-one.diff Rejected patch by schwab. See also Bug ##197190, comment #67.
Reassigning to Matthias. He knows more about this PCI domain stuff.
Let's see whether our friends at SGI may have some input on this. Greg?
Let's see...
JFYI.
Greg?
Looks like you could use this patch: Ensure domain is stripped from the bus ID. http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=c366b82bd50066019cf82b3464445d5bc27d6f9f
Aside from the PCI domain mismatch problem, we know the radeon kernel module won't ever work on SN-IA (not sure about other IA64). On Prism type machines, AGP fails to initialize, so DRI is disabled. On Altix machines with PCIe, I'd like to have DRI disabled also, even if it's specified in xorg.conf. What's the easiest way to do this; in Xorg, radeon driver, or kernel module?
The patch is correct, but wouldn't help here, as the domain is already wrong. Given Jonathan's report, the question is whether we should still bother here? The best way to disalbe DRI is probably in the drm module, because that would stop *any* possibility of using DRI, not only through the Xserver, but also mesa-solo and whatever else is on the market right now. My 2 cents only, though.
I did some testing today on an Altix (SN-IA) with a FireMV 2200 installed in the PCI-X slot. The system is running SLES10 SP1 (2.6.16.46-0.12 kernel). I put an entry in the xorg.conf "Module" section to load "dri". Upon running Xorg, I get: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM [dri] Disabling DRI. which is the result I want; Xorg runs fine thereafter. I will attach the log. I wanted to test with openSUSE 11.0, but couldn't get past some installation problems.
Created attachment 188306 [details] Xorg log for SLES10 SP1
Well, the reason is that "chip 1002,5965" (FireMV 2200) is still missing in drivers/char/drm/drm_pciids.h of SLES10 kernel. This is different for a current openSUSE kernel.
Setting priority & severity according to new guidelines.
Not sure if Xorg currently works on IA64 at all. If it does, please verify if this issue is already resolved with Alpha1(internal)/Beta1.
drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0005:00:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:00:00.0
Created attachment 232093 [details] Full log
This looks like the remaining issue: (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI. (II) RADEON(0): [agp] You may want to make sure the agpgart kernel module is loaded before the radeon kernel module. (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 65536 bytes of SAREA 0x23fec000 at 0x200000000d300000 (II) RADEON(0): [drm] Closed DRM master. [...] (WW) RADEON(0): Direct rendering disabled AFAICS there is AGP suport available for IA64. # rpm -qpl /work/CDs/all/full-ia64/suse/ia64/kernel-default.rpm |grep -i agp /lib/modules/2.6.26-7-default/kernel/drivers/char/agp /lib/modules/2.6.26-7-default/kernel/drivers/char/agp/agpgart.ko /lib/modules/2.6.26-7-default/kernel/drivers/char/agp/hp-agp.ko /lib/modules/2.6.26-7-default/kernel/drivers/char/agp/i460-agp.ko /lib/modules/2.6.26-7-default/kernel/drivers/char/agp/sgi-agp.ko
BTW, > (!!) More than one possible primary device found > (--) PCI: (5@0:0:0) unknown vendor (0x1002) unknown chipset (0x4a4d) rev 128, > Mem @ 0x4148000000/134217728, 0x4140100000/65536, I/O @ 0x00001000/256, BIOS > @0x????????/56832 >(--) PCI: (5@0:0:1) unknown vendor (0x1002) unknown chipset (0x4a6d) rev 128, > Mem @ 0x4150000000/134217728, 0x4140110000/65536 >(--) PCI: (6@0:0:0) unknown vendor (0x1002) unknown chipset (0x4a4d) rev 128, > Mem @ 0xc148000000/134217728, 0xc140100000/65536, I/O @ 0x02001000/256, BIOS > @0x????????/56832 >(--) PCI: (6@0:0:1) unknown vendor (0x1002) unknown chipset (0x4a6d) rev 128, > Mem @ 0xc150000000/134217728, 0xc140110000/65536 Multicard setup (SaX2 no longer creates a configuration for this by default). BusID needs to be specified here. BusID <bus>@<domain>:<slot>:<function>
(In reply to comment #28 from Andreas Schwab) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 9, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 9, (OK) > drmOpenByBusid: Searching for BusID pci:0005:00:00.0 Shouldn't this be pci:0000:05:00:00, i.e bus 5 on domain 0? > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 9, (OK) > drmOpenByBusid: drmOpenMinor returns 9 > drmOpenByBusid: drmGetBusid reports pci:0000:00:00.0 And now it detects it on bus 0000 on domain 00? So domain support is still/again utterly broken (as expected)? Oh well ...
The graphics cards are in different domains.
(In reply to comment #33 from Andreas Schwab) > The graphics cards are in different domains. So (5@0:0:0) means (domain@bus:slot:function)? Still this looks like broken domain support to me. I'm no longer sure about the xorg.conf syntax. It's not really documented at all. :-(
It's indeed domain@bus:device:function. This notation makes me crazy.
(In reply to comment #31 from Stefan Dirsch) > Multicard setup (SaX2 no longer creates a configuration for this by default). > BusID needs to be specified here. > > BusID <bus>@<domain>:<slot>:<function> Wrong. Needs to be BusID <domain>@<bus>:<slot>:<function>
Is IA64 the only multi domain hw we have? What about PPC64 servers?
The PowerMacs also have multiple domains, but the AGP slot is in domain 0.
The old log file does not contain any domain information. The new one (in comment #29) does. Does the information in this log coincide with the lspci output? The PCI slot info is passed to the dri client. So it could be that this information is wrong as the server seems to be working. Andreas: could you attach an lspci log?
Andreas?
I don't think anybody can continue working on this without the requested information. Therefore closing as NORESPONSE ... to trigger this feedback. ;-)