Hi, not sure if this is the right place:
On FC5test3 with Xair (all updates as of today) DRM fails strangely:
| [ralph@logout ~]$ glxinfo | name of display: :0.0 | libGL error: open DRM failed (Operation not permitted) | libGL error: reverting to (slow) indirect rendering | display: :0 screen: 0 | direct rendering: No
When "straceing" glxinfo, I see the following:
| stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card0", {st_mode=S_IFCHR|0600, st_rdev=makedev(226, 0), | ...}) = 0 | open("/dev/dri/card0", O_RDWR) = 4 | ioctl(4, DECODER_SET_PICTURE, 0xbf96c3e0) = -1 EACCES (Permission | denied) | ioctl(4, DECODER_GET_CAPABILITIES, 0xbf96c3e4) = 0 | ioctl(4, DECODER_GET_CAPABILITIES, 0xbf96c3e4) = 0 | close(4) = 0 | geteuid32() = 500 | stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card1", 0xbf96c200) = -1 ENOENT (No such file or | directory) | geteuid32() = 500 | stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card2", 0xbf96c200) = -1 ENOENT (No such file or | directory) | geteuid32() = 500 | stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card3", 0xbf96c200) = -1 ENOENT (No such file or | directory)
[...]
| stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card253", 0xbf96c200) = -1 ENOENT (No such file or | directory) | geteuid32() = 500 | stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card254", 0xbf96c200) = -1 ENOENT (No such file or | directory) | write(2, "libGL error: open DRM failed (Op"..., 55) = 55 | write(2, "libGL error: reverting to (slow)"..., 52) = 52 | futex(0x78a5a4, FUTEX_WAKE, 2147483647) = 0
So it seems to open the first card at dri/card0, fails with DECODER_SET_PICTURE and then tries all other possibly available cards until it bails out with open DRM failed.
TIA,
Ralph
On Fri, 2006-02-24 at 01:02 +0100, Ralph Angenendt wrote:
Hi, not sure if this is the right place:
On FC5test3 with Xair (all updates as of today) DRM fails strangely:
| [ralph@logout ~]$ glxinfo | name of display: :0.0 | libGL error: open DRM failed (Operation not permitted) | libGL error: reverting to (slow) indirect rendering | display: :0 screen: 0 | direct rendering: No
When "straceing" glxinfo, I see the following:
| stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card0", {st_mode=S_IFCHR|0600, st_rdev=makedev(226, 0), | ...}) = 0 | open("/dev/dri/card0", O_RDWR) = 4 | ioctl(4, DECODER_SET_PICTURE, 0xbf96c3e0) = -1 EACCES (Permission | denied) | ioctl(4, DECODER_GET_CAPABILITIES, 0xbf96c3e4) = 0 | ioctl(4, DECODER_GET_CAPABILITIES, 0xbf96c3e4) = 0 | close(4) = 0 | geteuid32() = 500 | stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card1", 0xbf96c200) = -1 ENOENT (No such file or | directory) | geteuid32() = 500 | stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card2", 0xbf96c200) = -1 ENOENT (No such file or | directory) | geteuid32() = 500 | stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card3", 0xbf96c200) = -1 ENOENT (No such file or | directory)
[...]
| stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card253", 0xbf96c200) = -1 ENOENT (No such file or | directory) | geteuid32() = 500 | stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 | stat64("/dev/dri/card254", 0xbf96c200) = -1 ENOENT (No such file or | directory) | write(2, "libGL error: open DRM failed (Op"..., 55) = 55 | write(2, "libGL error: reverting to (slow)"..., 52) = 52 | futex(0x78a5a4, FUTEX_WAKE, 2147483647) = 0
So it seems to open the first card at dri/card0, fails with DECODER_SET_PICTURE and then tries all other possibly available cards until it bails out with open DRM failed.
TIA,
Ralph
fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
I have the same problem. My video card is a Via KM400. I am running the openchrome drivers, and dri under the normal X server works fine. I am hoping to test out the eye candy soon. ;-)
Jon
Ralph Angenendt wrote:
Hi, not sure if this is the right place:
On FC5test3 with Xair (all updates as of today) DRM fails strangely:
| [ralph@logout ~]$ glxinfo | name of display: :0.0 | libGL error: open DRM failed (Operation not permitted) | libGL error: reverting to (slow) indirect rendering | display: :0 screen: 0 | direct rendering: No
Errm, yes. Worst possible bug report :)
Xair is at xorg-x11-server-Xair-1.0.0.0.2.20060207-5
The card is detected as
Chipset: "ATI Radeon Mobility 9000 (M9) Lf (AGP)" (ChipID = 0x4c66)
The xorg.log tells me that drm gets installed successfully.
Regards,
Ralph
fre, 24 02 2006 kl. 11:41 +0100, skrev Ralph Angenendt:
Ralph Angenendt wrote:
Errm, yes. Worst possible bug report :)
Talking to myself:
SELinux is turned off.
With SELinux off, I am able to get this Xair stuff running on my Radeon 7000 - it's quite slow but today a new 9250 should be arriving just for this kind of testing.
- David
disabling selinux works for me also. i'm using intel 82865g integrated (i810 driver). effects are cool looking. can someone contact Ray Strode to have the wiki page http://fedoraproject.org/wiki/RenderingProject/AiglxOnFedora include this tip?
David Nielsen wrote:
fre, 24 02 2006 kl. 11:41 +0100, skrev Ralph Angenendt:
Ralph Angenendt wrote:
Errm, yes. Worst possible bug report :)
Talking to myself:
SELinux is turned off.
With SELinux off, I am able to get this Xair stuff running on my Radeon 7000 - it's quite slow but today a new 9250 should be arriving just for this kind of testing.
- David
2006/2/24, Sessoms, Mack zac9@cdc.gov:
disabling selinux works for me also. i'm using intel 82865g integrated (i810 driver). effects are cool looking. can someone contact Ray Strode to have the wiki page http://fedoraproject.org/wiki/RenderingProject/AiglxOnFedora include this tip?
David Nielsen wrote:
fre, 24 02 2006 kl. 11:41 +0100, skrev Ralph Angenendt:
Ralph Angenendt wrote:
Errm, yes. Worst possible bug report :)
Talking to myself:
SELinux is turned off.
With SELinux off, I am able to get this Xair stuff running on my Radeon 7000 - it's quite slow but today a new 9250 should be arriving just for this kind of testing.
Disabling selinux isnt a solution a solution at all... rather report the problem with bugzilla to get a real solution instead of telling people to turn off important security features.
i do not recommend to turn off selinux and turn off important security bits of the system neither for eye candy nor for other tasks/applications.
I doubt any fedora developer does want to recommend that either ;).
regards, Rudolf Kastl
- David
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
agreed!
Rudolf Kastl wrote:
2006/2/24, Sessoms, Mack zac9@cdc.gov:
disabling selinux works for me also. i'm using intel 82865g integrated (i810 driver). effects are cool looking. can someone contact Ray Strode to have the wiki page http://fedoraproject.org/wiki/RenderingProject/AiglxOnFedora include this tip?
David Nielsen wrote:
fre, 24 02 2006 kl. 11:41 +0100, skrev Ralph Angenendt:
Ralph Angenendt wrote:
Errm, yes. Worst possible bug report :)
Talking to myself:
SELinux is turned off.
With SELinux off, I am able to get this Xair stuff running on my Radeon 7000 - it's quite slow but today a new 9250 should be arriving just for this kind of testing.
Disabling selinux isnt a solution a solution at all... rather report the problem with bugzilla to get a real solution instead of telling people to turn off important security features.
i do not recommend to turn off selinux and turn off important security bits of the system neither for eye candy nor for other tasks/applications.
I doubt any fedora developer does want to recommend that either ;).
regards, Rudolf Kastl
- David
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
fre, 24 02 2006 kl. 08:49 -0500, skrev Sessoms, Mack:
agreed!
I suppose this is the proper place to track this issue.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176221
I get a rather nasty hang using my r300 based card, I'll replace it with the r100 based on again later to provide more data. Untill then I encourage others to help out.
And no turning SELinux off isn't a solution however I noticed it while testing another SELinux induced issue.
- David
2006/2/24, David Nielsen gnomeuser@gmail.com:
fre, 24 02 2006 kl. 08:49 -0500, skrev Sessoms, Mack:
agreed!
I suppose this is the proper place to track this issue.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176221
I get a rather nasty hang using my r300 based card, I'll replace it with the r100 based on again later to provide more data. Untill then I encourage others to help out.
And no turning SELinux off isn't a solution however I noticed it while testing another SELinux induced issue.
- David
-- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
hang with r250 here ;) i am going to debug it this evening. need a 2nd box to ssh in and attach gdb.
David Nielsen wrote:
fre, 24 02 2006 kl. 08:49 -0500, skrev Sessoms, Mack:
agreed!
I suppose this is the proper place to track this issue.
Though that isn't the issue I'm seeing. Well, I'm gonna have some time tomorrow for doing some more debugging ...
Ralph
for me, metacity wouldn't start. i was getting "error in loading shared libraries: libGL.so.1: cannot open shared object file: Permission denied"
Ralph Angenendt wrote:
David Nielsen wrote:
fre, 24 02 2006 kl. 08:49 -0500, skrev Sessoms, Mack:
agreed!
I suppose this is the proper place to track this issue.
Though that isn't the issue I'm seeing. Well, I'm gonna have some time tomorrow for doing some more debugging ...
Ralph
Ralph Angenendt wrote:
Ralph Angenendt wrote:
Hi, not sure if this is the right place:
On FC5test3 with Xair (all updates as of today) DRM fails strangely:
| [ralph@logout ~]$ glxinfo | name of display: :0.0 | libGL error: open DRM failed (Operation not permitted) | libGL error: reverting to (slow) indirect rendering | display: :0 screen: 0 | direct rendering: No
Errm, yes. Worst possible bug report :)
Xair is at xorg-x11-server-Xair-1.0.0.0.2.20060207-5
The card is detected as
Chipset: "ATI Radeon Mobility 9000 (M9) Lf (AGP)" (ChipID = 0x4c66)
The xorg.log tells me that drm gets installed successfully.
But this here on the console looks like an error:
*** glibc detected *** /usr/bin/Xair: double free or corruption (!prev): 0x09071e40 *** ======= Backtrace: ========= /lib/libc.so.6[0x164de8] /lib/libc.so.6(__libc_free+0x79)[0x1682ed] /usr/bin/Xair(Xfree+0x23)[0x8205576] /usr/lib/xair/modules/extensions/libdri.so(DRIDestroyInfoRec+0x2a)[0xe269b7] /usr/lib/xair/modules/drivers/radeon_drv.so(RADEONDRICloseScreen+0x1c3)[0x91f063] /usr/lib/xair/modules/drivers/radeon_drv.so[0x90f1b1] /usr/bin/Xair[0x818f072] /usr/bin/Xair[0x80f84b7] /usr/bin/Xair[0x80d79be] /usr/bin/Xair[0x8156e40] /usr/bin/Xair[0x818c0a3] /usr/bin/Xair[0x81f6a92] /usr/bin/Xair(main+0x7b9)[0x806e3ad] /lib/libc.so.6(__libc_start_main+0xdc)[0x1167a4] /usr/bin/Xair(FontFileCompleteXLFD+0xad)[0x806db31]
Ralph
But this here on the console looks like an error:
*** glibc detected *** /usr/bin/Xair: double free or corruption (!prev): 0x09071e40 *** ======= Backtrace: ========= /lib/libc.so.6[0x164de8] /lib/libc.so.6(__libc_free+0x79)[0x1682ed] /usr/bin/Xair(Xfree+0x23)[0x8205576] /usr/lib/xair/modules/extensions/libdri.so(DRIDestroyInfoRec+0x2a)[0xe269b7] /usr/lib/xair/modules/drivers/radeon_drv.so(RADEONDRICloseScreen+0x1c3)[0x91f063] /usr/lib/xair/modules/drivers/radeon_drv.so[0x90f1b1] /usr/bin/Xair[0x818f072] /usr/bin/Xair[0x80f84b7] /usr/bin/Xair[0x80d79be] /usr/bin/Xair[0x8156e40] /usr/bin/Xair[0x818c0a3] /usr/bin/Xair[0x81f6a92] /usr/bin/Xair(main+0x7b9)[0x806e3ad] /lib/libc.so.6(__libc_start_main+0xdc)[0x1167a4] /usr/bin/Xair(FontFileCompleteXLFD+0xad)[0x806db3]
Hi,
yes this is a real bad real bug in Xair...
you can improve the quality of this bugreport by 1) installing the respective -debuginfo rpms (in this case of Xair and the driver) 2) running the app from inside gdb and then when the crash hits, 3) type "bt"
that gives a similar backtrace, but with a LOT more useful information (such as function names and filenames + line numbers) for the developers to figure this one out...
Arjan van de Ven wrote:
you can improve the quality of this bugreport by
- installing the respective -debuginfo rpms (in this case of Xair and
the driver) 2) running the app from inside gdb and then when the crash hits, 3) type "bt"
that gives a similar backtrace, but with a LOT more useful information (such as function names and filenames + line numbers) for the developers to figure this one out...
I don't seem to be able to do that (following "the book" at http://wiki.x.org/wiki/DebuggingTheXserver).
When attaching to a running Xair from a remote machine, I cannot reproduce the bug, as it happens at startup. Running "gdb /usr/bin/Xair" from a remote machine doesn't seem to trigger the bug.
Starting Xair in gdb from the local machine inhibits me from getting back to gdb. And using a script as described in http://wiki.x.org/wiki/DebuggingTheXserver#head-e988cb1d62739154287e8231cb2cdd9732b65428 gives me some output, but none concerning the error.
And as the error doesn't make Xair dump core either, I have no core file which I can run gdb against.
Any hints? I'd really like to help, as I really like to see some eye candy :)
Ralph
On Sun, 2006-02-26 at 14:46 +0100, Ralph Angenendt wrote:
Arjan van de Ven wrote:
you can improve the quality of this bugreport by
- installing the respective -debuginfo rpms (in this case of Xair and
the driver) 2) running the app from inside gdb and then when the crash hits, 3) type "bt"
that gives a similar backtrace, but with a LOT more useful information (such as function names and filenames + line numbers) for the developers to figure this one out...
I don't seem to be able to do that (following "the book" at http://wiki.x.org/wiki/DebuggingTheXserver).
When attaching to a running Xair from a remote machine, I cannot reproduce the bug, as it happens at startup. Running "gdb /usr/bin/Xair" from a remote machine doesn't seem to trigger the bug.
Starting Xair in gdb from the local machine inhibits me from getting back to gdb. And using a script as described in http://wiki.x.org/wiki/DebuggingTheXserver#head-e988cb1d62739154287e8231cb2cdd9732b65428 gives me some output, but none concerning the error.
And as the error doesn't make Xair dump core either, I have no core file which I can run gdb against.
if Xair is setuid, set /proc/sys/fs/suid_dumpable variable to 1 (and make sure the ulimit for core dumping isn't 0)
Arjan van de Ven wrote:
On Sun, 2006-02-26 at 14:46 +0100, Ralph Angenendt wrote:
And as the error doesn't make Xair dump core either, I have no core file which I can run gdb against.
if Xair is setuid, set /proc/sys/fs/suid_dumpable variable to 1 (and make sure the ulimit for core dumping isn't 0)
I still can't get Xair to dump core. I see the error flashing by, but Xair starts up "normally". Yes, 'Option "NoTrapSignals" "1"' is set in the ServerFlags section.
Regards,
Ralph
Ralph Angenendt wrote:
Arjan van de Ven wrote:
On Sun, 2006-02-26 at 14:46 +0100, Ralph Angenendt wrote:
And as the error doesn't make Xair dump core either, I have no core file which I can run gdb against.
if Xair is setuid, set /proc/sys/fs/suid_dumpable variable to 1 (and make sure the ulimit for core dumping isn't 0)
I still can't get Xair to dump core. I see the error flashing by, but Xair starts up "normally". Yes, 'Option "NoTrapSignals" "1"' is set in the ServerFlags section.
Run the X server as root for debugging purposes. That generally saves a lot of headaches. Also, configure the kernel as to where it should dump the core files and how it'll name them. Snoop through /proc/.... to find the proper entries..
HTH
Mike A. Harris wrote:
Ralph Angenendt wrote:
I still can't get Xair to dump core. I see the error flashing by, but Xair starts up "normally". Yes, 'Option "NoTrapSignals" "1"' is set in the ServerFlags section.
Run the X server as root for debugging purposes. That generally saves a lot of headaches. Also, configure the kernel as to where it should dump the core files and how it'll name them. Snoop through /proc/.... to find the proper entries..
Yeah, I tried to do that. It does dump core, when I press <CTRL>-C on the console to stop Xair. But I cannot get it to do that while starting up ...
Dang, that's the *one* time I want to have something dump core on me and it doesn't ...
Ralph
Ralph Angenendt wrote:
Ralph Angenendt wrote:
Ralph Angenendt wrote:
Hi, not sure if this is the right place:
On FC5test3 with Xair (all updates as of today) DRM fails strangely:
| [ralph@logout ~]$ glxinfo | name of display: :0.0 | libGL error: open DRM failed (Operation not permitted) | libGL error: reverting to (slow) indirect rendering | display: :0 screen: 0 | direct rendering: No
Errm, yes. Worst possible bug report :)
Xair is at xorg-x11-server-Xair-1.0.0.0.2.20060207-5
The card is detected as
Chipset: "ATI Radeon Mobility 9000 (M9) Lf (AGP)" (ChipID = 0x4c66)
The xorg.log tells me that drm gets installed successfully.
But this here on the console looks like an error:
*** glibc detected *** /usr/bin/Xair: double free or corruption (!prev): 0x09071e40 *** ======= Backtrace: ========= /lib/libc.so.6[0x164de8] /lib/libc.so.6(__libc_free+0x79)[0x1682ed] /usr/bin/Xair(Xfree+0x23)[0x8205576] /usr/lib/xair/modules/extensions/libdri.so(DRIDestroyInfoRec+0x2a)[0xe269b7] /usr/lib/xair/modules/drivers/radeon_drv.so(RADEONDRICloseScreen+0x1c3)[0x91f063] /usr/lib/xair/modules/drivers/radeon_drv.so[0x90f1b1] /usr/bin/Xair[0x818f072] /usr/bin/Xair[0x80f84b7] /usr/bin/Xair[0x80d79be] /usr/bin/Xair[0x8156e40] /usr/bin/Xair[0x818c0a3] /usr/bin/Xair[0x81f6a92] /usr/bin/Xair(main+0x7b9)[0x806e3ad] /lib/libc.so.6(__libc_start_main+0xdc)[0x1167a4] /usr/bin/Xair(FontFileCompleteXLFD+0xad)[0x806db31]
We were talking internally the other day about what the best way is for the developers, for users to report Xair related bugs is, and the overall concensus, is that in a short period of time, the accel_indirect_glx branch of X.Org CVS will be merged to head, and the primary CVS HEAD Xorg will become the home of future development, at which point bugs should be reported to X.Org bugzilla's CVS HEAD version.
It's not there yet, but it will be soon, so what we decided to do, is to get people who are experiencing bugs with Xair (on any OS, including Fedora), to report their bug in X.Org bugzilla at http://bugs.freedesktop.org against the 'xorg' product, version "CVS HEAD", and make sure to start the summary line with:
"[aiglx] <your summary here>"
Assign the bug to Kristian - krh@bitplanet.net
That should easily distinguish to developers, that it is Xair that is being reported, and it centralizes all bug reports to a common bugzilla.
Thanks in advance.
Ralph Angenendt wrote:
But this here on the console looks like an error:
*** glibc detected *** /usr/bin/Xair: double free or corruption (!prev): 0x09071e40 ***
This already is fixed on the accel_indirect_branch branch and will be merged to HEAD soon. New RPMs should come out some time later.
See https://bugs.freedesktop.org/show_bug.cgi?id=6054 - if somebody else is running into that.
So no bling! for me at the moment :(
Ralph