6:02 p.m.
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
8:35 p.m.
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(a)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
4:40 a.m.
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
4:53 a.m.
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
--
Obligatory shameless blog plug - the GNOME commentary located at:
www.lovesunix.net/blog
7:22 a.m.
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
7:44 a.m.
2006/2/24, Sessoms, Mack <zac9(a)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(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
7:49 a.m.
agreed!
Rudolf Kastl wrote:
2006/2/24, Sessoms, Mack <zac9(a)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(a)redhat.com
> To unsubscribe:
> https://www.redhat.com/mailman/listinfo/fedora-test-list
>
>
>
8:19 a.m.
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
8:30 a.m.
2006/2/24, David Nielsen <gnomeuser(a)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(a)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.
9:28 a.m.
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.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176221
Though that isn't the issue I'm seeing. Well, I'm gonna
have some time tomorrow for doing some more debugging ...
Ralph
9:43 a.m.
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.
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176221
Though that isn't the issue I'm seeing. Well, I'm gonna
have some time tomorrow for doing some more debugging ...
Ralph
3:36 a.m.
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
4:45 a.m.
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...
7:46 a.m.
Arjan van de Ven wrote:
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...
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-e988cb1d62739154287e8231c...
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
9:49 a.m.
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
> 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...
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-e988cb1d62739154287e8231c...
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)
11:18 a.m.
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
12:34 p.m.
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 * Open Source Advocate * http://mharris.ca
Proud Canadian.
1:08 p.m.
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
12:07 p.m.
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(a)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.
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
3:20 p.m.
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
6695
days inactive
6697
days old
20 comments
7 participants
participants (7)
-
Arjan van de Ven -
David Nielsen -
Jon Nettleton -
Mike A. Harris -
Ralph angenendt -
Rudolf Kastl -
Sessoms, Mack